From msk@cloudmark.com Mon Apr 2 13: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 BA06921F8723 for ; Mon, 2 Apr 2012 13:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IMffl77P-Rg for ; Mon, 2 Apr 2012 13:34:36 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id ADF1921F86FA for ; Mon, 2 Apr 2012 13:34:36 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 2 Apr 2012 13:34:36 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: SPF survey data Thread-Index: Ac0REAQH1YRvhKczQwizGYXe19gqBQ== Date: Mon, 2 Apr 2012 20:34:35 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C677E@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C677Eexchmbx901corpclo_" MIME-Version: 1.0 Subject: [spfbis] SPF survey data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Apr 2012 20:34:37 -0000 --_000_9452079D1A51524AA5749AD23E0039280C677Eexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have posted the mysqldump output of my SPF record survey at http://www.bl= ackops.org/~msk/spf.mysql for anyone that wants to import the data and run = your own analyses. It's 42Mb in size. Hoping to have a revision to the experiment document by the end of this wee= k. As nobody has put forth any suggested conclusions, I'll come up with so= me of my own and we can debate or agree on those. -MSK --_000_9452079D1A51524AA5749AD23E0039280C677Eexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have posted the mysqldump output of my SPF record = survey at http://www.blackops.org/= ~msk/spf.mysql for anyone that wants to import the data and run your ow= n analyses.  It’s 42Mb in size.

 

Hoping to have a revision to the experiment document= by the end of this week.  As nobody has put forth any suggested concl= usions, I’ll come up with some of my own and we can debate or agree o= n those.

 

-MSK

--_000_9452079D1A51524AA5749AD23E0039280C677Eexchmbx901corpclo_-- From msk@cloudmark.com Mon Apr 2 21: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 C5A0021F8562 for ; Mon, 2 Apr 2012 21:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.138 X-Spam-Level: X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf-2yXEn1DwC for ; Mon, 2 Apr 2012 21:16:37 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id BD1B321F8549 for ; Mon, 2 Apr 2012 21:16:37 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 2 Apr 2012 21:16:36 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Experiment document Thread-Index: Ac0OX1JElkOuVjEpSX+EejibzakHPAAl/sEAAJYa8LA= Date: Tue, 3 Apr 2012 04:16:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C6F68@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C2AF5@exch-mbx901.corp.cloudmark.com> <4F762676.7030906@sonnection.nl> In-Reply-To: <4F762676.7030906@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C6F68exchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [spfbis] Experiment document X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 04:16:39 -0000 --_000_9452079D1A51524AA5749AD23E0039280C6F68exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rolf, The data I've been collecting over time records, in addition to lots of DKI= M details, the SPF and Sender-ID results on each message if they're availab= le. The answer to the question, then, is to count the number of records fo= r each pass/fail combination of SPF and Sender-ID, and report that. There = are only four possible combinations to that truth table. The numbers in my= data show that over 95% of the time, SPF and Sender-ID come to the same co= nclusion about a message (that's the ratio of the pass/pass plus fail/fail = rows to the total). I wasn't able to characterize the messages in the rema= ining less-than-5% (e.g., they weren't all mailing list traffic). The distribution question might be interesting, especially if we find that = SPF records average a lot more (or less) in terms of resolution records com= pared to Sender-ID. I believe Scott plans to run this survey based on my d= ata. I posted a link to my database dump earlier today. Feel free to experiment= with the data if you like, and let us know if you find anything interestin= g. -MSK From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Rolf E. Sonneveld Sent: Friday, March 30, 2012 2:33 PM To: Murray S. Kucherawy Cc: spfbis@ietf.org Subject: Re: [spfbis] Experiment document - What is the relative deployment of SPF vs TXT records? - How many clients appear to be querying each record type? - What are counts on records that are specific to Sender-ID (i.e.,= spf2.0/pra) versus others? How much do the Sender-ID results deviate from the SPF results in terms of = pass/fail? Not sure I understand this correctly: the output of questions 1 and 3 can b= e derived easily by some database queries, but am I correct that question 4= requires processing of IP addresses/ranges to see what the results are? If= so, what is the test set to test with? How do you create test sets when in= clude:, redirect: or macro's are used? - How often do the validated identifiers differ between SPF and Se= nder-ID? How many implementations of each of the four RFCs are known to exist? (Thi= s is anecdotal, not survey-based.) Add this one: - distribution of number of DNS queries required to parse the SPF record. And the following appendix topics: - What operational considerations were observed (e.g., firewalls, = dropped packets for unknown types)? - The whole SPF vs. TXT evolution discussion - How often were non-SPF records found in TXT queries? Please bash the list now. I also need to add a paragraph that describes the surveys we've done. I'll= add that for mine; Philip, please send me a description of yours, on-list = or off. /rolf --_000_9452079D1A51524AA5749AD23E0039280C6F68exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rolf,

 

The data I’ve be= en collecting over time records, in addition to lots of DKIM details, the S= PF and Sender-ID results on each message if they’re available.  = The answer to the question, then, is to count the number of records for each pass/fail combination of SPF and Sender-ID, and report= that.  There are only four possible combinations to that truth table.=   The numbers in my data show that over 95% of the time, SPF and Sende= r-ID come to the same conclusion about a message (that’s the ratio of the pass/pass plus fail/fail rows to the total)= .  I wasn’t able to characterize the messages in the remaining l= ess-than-5% (e.g., they weren’t all mailing list traffic).=

 

The distribution quest= ion might be interesting, especially if we find that SPF records average a = lot more (or less) in terms of resolution records compared to Sender-ID.&nb= sp; I believe Scott plans to run this survey based on my data.


I posted a link to my database dump earlier today.  Feel free to exper= iment with the data if you like, and let us know if you find anything inter= esting.

 

-MSK=

 

From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ie= tf.org] On Behalf Of Rolf E. Sonneveld
Sent: Friday, March 30, 2012 2:33 PM
To: Murray S. Kucherawy
Cc: spfbis@ietf.org
Subject: Re: [spfbis] Experiment document

 

-     &= nbsp;    What is the relative deployment of SPF vs TXT recor= ds?

-     &= nbsp;    How many clients appear to be querying each record = type?

-     &= nbsp;    What are counts on records that are specific to Sen= der-ID (i.e., spf2.0/pra) versus others?

How much do the = Sender-ID results deviate from the SPF results in terms of pass/fail?<= /o:p>


Not sure I understand this correctly: the output of questions 1 and 3 can b= e derived easily by some database queries, but am I correct that question 4= requires processing of IP addresses/ranges to see what the results are? If= so, what is the test set to test with? How do you create test sets when include:, redirect: or macro's are = used?
 

-     &= nbsp;    How often do the validated identifiers differ betwe= en SPF and Sender-ID?

How many impleme= ntations of each of the four RFCs are known to exist?  (This is anecdo= tal, not survey-based.)


Add this one:

- distribution of number of DNS queries required to parse the SPF record.

 

And the following appendix topics:

 

-     &= nbsp;    What operational considerations were observed (e.g.= , firewalls, dropped packets for unknown types)?

-     &= nbsp;    The whole SPF vs. TXT evolution discussion

-     &= nbsp;    How often were non-SPF records found in TXT queries= ?

 

Please bash the list now.

 

I also need to add a paragraph that describes the su= rveys we’ve done.  I’ll add that for mine; Philip, please = send me a description of yours, on-list or off.


/rolf

--_000_9452079D1A51524AA5749AD23E0039280C6F68exchmbx901corpclo_-- From vesely@tana.it Tue Apr 3 08:20: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 68BAD11E80B8 for ; Tue, 3 Apr 2012 08:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVpbJwTSEkYa for ; Tue, 3 Apr 2012 08:20:09 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 990B211E80A2 for ; Tue, 3 Apr 2012 08:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333466408; bh=eceEpS9t8AoXhwiGqv9XgLpgaoU9jeMHwwmAbcV5OkU=; l=1132; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=LKhdFw+Ve63Urm7YhQ4AyCGlHqZny/u8zZWMwi8VHBTjrL5k02IX3NZWAKndcH2r2 85YEKFoBFuEr3+h97otQDwpqtkf5LMSR+0HcojFhKxKerUFNAnzLvN13bnH2gBhv+s O1LD1MQwu6tHgdaatszjLkizn3Ayv06fFO7KkAng= 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, 03 Apr 2012 17:20:08 +0200 id 00000000005DC039.000000004F7B1528.00000755 Message-ID: <4F7B1528.5090104@tana.it> Date: Tue, 03 Apr 2012 17:20:08 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <6.2.5.6.2.20120314113845.09b3b920@resistor.net> <7F7F36E50398F84DBAF25C9D51732F1E20F65CEA@TK5EX14MBXC292.redmond.corp.microsoft.com> <1788008.TexYV2zLNy@scott-latitude-e6320> <4F6C2F2C.8020405@tana.it> <9452079D1A51524AA5749AD23E003928098ED8@exch-mbx901.corp.cloudmark.com> <4F6DED16.4060705@tana.it> In-Reply-To: <4F6DED16.4060705@tana.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:20:10 -0000 On 24/Mar/12 16:49, Alessandro Vesely wrote: > On 23.03.2012 18:33, Murray S. Kucherawy wrote: >>> From: ietf.org On Behalf Of Alessandro Vesely >> >>> Hm... some implementations rename that to Original-Received-SPF. >> >> Why would they do that? > > To ease checking, IIRC. I'm unable to find that discussion right now, I'll > confirm (or retract) this point next week. I remembered wrong, it is Old-Received-SPF, not Original. I found this one-year-old post by the developer of Courier: The goal here is to certify that any "Received-SPF:" headers in the mail were inserted by this host, and not somewhere else. Multiple Received-SPF: headers are allowed. If any existing headers do not get renamed, it would not be possible to reliably determine which ones are authentic. http://sourceforge.net/mailarchive/message.php?msg_id=27291203 That solution is more effective than looking for the "receiver" tag --the equivalent of authserv-id-- since it is not mandatory for Received-SPF to have one. That renaming only occurs if SPF checking is locally enabled. Still, problems exist with backup MXes. From spf2@kitterman.com Tue Apr 3 09:51: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 188EC21F85C6 for ; Tue, 3 Apr 2012 09:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y17WAnylUqVh for ; Tue, 3 Apr 2012 09:51:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91921F84D3 for ; Tue, 3 Apr 2012 09:51:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BAFB520E410E; Tue, 3 Apr 2012 12:51:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1333471904; bh=EUEdOeyBt1bMxnaZiiYyqponvQ/SPnG/SYP/qEXBcRE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=qJOVAFNM7hW9kmnF6npoAKmUgqx8kX9WCf0tzexNeNdkV1bdzwYuqUedrIW6k+kWN o1mE5XKzBpt/L7dnjMSOhzIRrFTVAiIiXIpJfBKWynVBzvn2y/FEV/s5YJQLrL/ArU V+h6I7ec3iLOp8LMG/rCVyI96cIKctHDnppw5YdM= Received: from scott-latitude-e6320.localnet (75.sub-97-187-217.myvzw.com [97.187.217.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 76FF620E4064; Tue, 3 Apr 2012 12:51:44 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Apr 2012 12:51:41 -0400 Message-ID: <11504137.h5tzZM0OXg@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-17-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F7B1528.5090104@tana.it> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <4F6DED16.4060705@tana.it> <4F7B1528.5090104@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] #10: RFC 4408 replace Received-SPF with RFC5451 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:51:47 -0000 On Tuesday, April 03, 2012 05:20:08 PM Alessandro Vesely wrote: > On 24/Mar/12 16:49, Alessandro Vesely wrote: > > On 23.03.2012 18:33, Murray S. Kucherawy wrote: > >>> From: ietf.org On Behalf Of Alessandro Vesely > >>> > >>> Hm... some implementations rename that to Original-Received-SPF. > >> > >> Why would they do that? > > > > To ease checking, IIRC. I'm unable to find that discussion right now, > > I'll confirm (or retract) this point next week. > > I remembered wrong, it is Old-Received-SPF, not Original. I found > this one-year-old post by the developer of Courier: > > The goal here is to certify that any "Received-SPF:" headers in the > mail were inserted by this host, and not somewhere else. Multiple > Received-SPF: headers are allowed. If any existing headers do not > get renamed, it would not be possible to reliably determine which > ones are authentic. > http://sourceforge.net/mailarchive/message.php?msg_id=27291203 > > That solution is more effective than looking for the "receiver" tag > --the equivalent of authserv-id-- since it is not mandatory for > Received-SPF to have one. That renaming only occurs if SPF checking > is locally enabled. Still, problems exist with backup MXes. As far as I know, this approach is unique to Courier. Spamassassin, for example, looks at the interleaved Received: headers and it's list of trusted hosts to determine which Received-SPF headers can be used. Adding Old-Received-SPF would be a new requirement and I don't think it has wide spread adoption. Scott K From vesely@tana.it Tue Apr 3 10:27: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 A6F7921F8644 for ; Tue, 3 Apr 2012 10:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.394 X-Spam-Level: X-Spam-Status: No, score=-4.394 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lorlmnzc1rWJ for ; Tue, 3 Apr 2012 10:27:53 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C161C21F8631 for ; Tue, 3 Apr 2012 10:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333474071; bh=ax2xm5JcJYPikrlHmoQdEAIq+sOyjDnRvH9JAs1Wbu4=; l=2182; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hzNrLLvNlwQ31jh4ojDLQayKP6ztpbJeQ6MEYt1eXMLE7RK93VgrIYYSNHib3O7SY fcLKuASwJ8NA5Gtrom57TpdcheZkHZwkYlEPiaZBPkKLvpD0QazPiboaY9HSQX/Gi6 efU0s+TmMQw9kMcG4K+3LRmqW4qIlVD5pCG5RFic= 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, 03 Apr 2012 19:27:51 +0200 id 00000000005DC039.000000004F7B3317.0000283C Message-ID: <4F7B3317.2060507@tana.it> Date: Tue, 03 Apr 2012 19:27:51 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <4F6DED16.4060705@tana.it> <4F7B1528.5090104@tana.it> <11504137.h5tzZM0OXg@scott-latitude-e6320> In-Reply-To: <11504137.h5tzZM0OXg@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:27:53 -0000 On 03/Apr/12 18:51, Scott Kitterman wrote: > On Tuesday, April 03, 2012 05:20:08 PM Alessandro Vesely wrote: >> On 24/Mar/12 16:49, Alessandro Vesely wrote: >> > On 23.03.2012 18:33, Murray S. Kucherawy wrote: >> >>> From: ietf.org On Behalf Of Alessandro Vesely >> >>> >> >>> Hm... some implementations rename that to Original-Received-SPF. >> >> >> >> Why would they do that? >> > >> > To ease checking, IIRC. I'm unable to find that discussion right now, >> > I'll confirm (or retract) this point next week. >> >> I remembered wrong, it is Old-Received-SPF, not Original. I found >> this one-year-old post by the developer of Courier: >> >> The goal here is to certify that any "Received-SPF:" headers in the >> mail were inserted by this host, and not somewhere else. Multiple >> Received-SPF: headers are allowed. If any existing headers do not >> get renamed, it would not be possible to reliably determine which >> ones are authentic. >> http://sourceforge.net/mailarchive/message.php?msg_id=27291203 >> >> That solution is more effective than looking for the "receiver" tag >> --the equivalent of authserv-id-- since it is not mandatory for >> Received-SPF to have one. That renaming only occurs if SPF checking >> is locally enabled. Still, problems exist with backup MXes. > > As far as I know, this approach is unique to Courier. Spamassassin, for > example, looks at the interleaved Received: headers and it's list of trusted > hosts to determine which Received-SPF headers can be used. > > Adding Old-Received-SPF would be a new requirement and I don't think it has > wide spread adoption. I would leave this field's spec as it is, except mentioning RFC 5451 and thus recommending that at least one of those fields be used, and possibly that in case both are used they should/must agree at least on the result and on the mandated key-value pairs. However, if Murray finds out where in the experiment doc it is worth to mention this renaming approach, I'd agree. Received-SPF can be considered a precursor of Authentication-Results, although I don't know if any of its traits did actually influence any of RFC 5451's ideas. From msk@cloudmark.com Tue Apr 3 12:30: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 D940621F86BD for ; Tue, 3 Apr 2012 12:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojHTeQi2mItm for ; Tue, 3 Apr 2012 12:30:37 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EB50621F86B1 for ; Tue, 3 Apr 2012 12:30:37 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 12:30:37 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: SPF survey data Thread-Index: Ac0REAQH1YRvhKczQwizGYXe19gqBQAwB2PQ Date: Tue, 3 Apr 2012 19:30:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C7BD1@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C677E@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C677E@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C7BD1exchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [spfbis] SPF survey data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:30:39 -0000 --_000_9452079D1A51524AA5749AD23E0039280C7BD1exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Revised URI: http://www.blackops.org/~msk/spfbis ...now contains my survey's SQL dump (spf.mysql) as well as Philip's (spf.d= b.gz). -MSK From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Monday, April 02, 2012 1:35 PM To: spfbis@ietf.org Subject: [spfbis] SPF survey data I have posted the mysqldump output of my SPF record survey at http://www.bl= ackops.org/~msk/spf.mysql for anyone that wants to import the data and run = your own analyses. It's 42Mb in size. Hoping to have a revision to the experiment document by the end of this wee= k. As nobody has put forth any suggested conclusions, I'll come up with so= me of my own and we can debate or agree on those. -MSK --_000_9452079D1A51524AA5749AD23E0039280C7BD1exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Revised URI:

 

http://www.blackops.org/~msk/spfbis

 

…now contains my= survey’s SQL dump (spf.mysql) as well as Philip’s (spf.db.gz).=

 

-MSK=

 

From: spfbis-b= ounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Monday, April 02, 2012 1:35 PM
To: spfbis@ietf.org
Subject: [spfbis] SPF survey data

 

I have posted the mysqldump output of my SPF record = survey at http://www.blackops.org/= ~msk/spf.mysql for anyone that wants to import the data and run your ow= n analyses.  It’s 42Mb in size.

 

Hoping to have a revision to the experiment document= by the end of this week.  As nobody has put forth any suggested concl= usions, I’ll come up with some of my own and we can debate or agree o= n those.

 

-MSK

--_000_9452079D1A51524AA5749AD23E0039280C7BD1exchmbx901corpclo_-- From R.E.Sonneveld@sonnection.nl Tue Apr 3 12:52: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 5195011E8111 for ; Tue, 3 Apr 2012 12:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVqY+Sz7XuZX for ; Tue, 3 Apr 2012 12:52:39 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id C428911E8108 for ; Tue, 3 Apr 2012 12:52:38 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M1X00L005VO4O00@helium.mailtransaction.com>; Tue, 03 Apr 2012 21:52:36 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M1X00H0D5VCPD00@helium.mailtransaction.com>; Tue, 03 Apr 2012 21:52:36 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2EoZuCL44xmFt+cKEMWpag)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M1X003025V6I500@lion.sonnection.nl> for spfbis@ietf.org; Tue, 03 Apr 2012 21:52:18 +0200 (CEST) Message-id: <4F7B5693.1050501@sonnection.nl> Date: Tue, 03 Apr 2012 21:59:15 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E0039280C2AF5@exch-mbx901.corp.cloudmark.com> <4F762676.7030906@sonnection.nl> <9452079D1A51524AA5749AD23E0039280C6F68@exch-mbx901.corp.cloudmark.com> In-reply-to: <9452079D1A51524AA5749AD23E0039280C6F68@exch-mbx901.corp.cloudmark.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1333482756; bh=XxNfVFyM+yz2LrDlo+2VoCQLl8vdQXZTvqk4aOaiu6I=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=XvWDXE1QvosgFC9MCAaN2U+Au42o/8C8ErEjrHSBfAOfmuJtpTlSOo8yzZ5fsCr1y Ld2yJjrO7XqDD9U6uynukgol55iQYZw4bFDUO+b76Va0XoWTNOXSYr9ehr8hpIIEd/ KEtbwghs6SdX+dYk16RsMOXVxkAOH1Cgw/Wwgv+g= X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0M1X00L005VO4O00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Experiment document X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:52:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_2EoZuCL44xmFt+cKEMWpag) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hi, Murray, On 4/3/12 6:16 AM, Murray S. Kucherawy wrote: > > Hi Rolf, > > The data I've been collecting over time records, in addition to lots > of DKIM details, the SPF and Sender-ID results on each message if > they're available. The answer to the question, then, is to count the > number of records for each pass/fail combination of SPF and Sender-ID, > and report that. There are only four possible combinations to that > truth table. The numbers in my data show that over 95% of the time, > SPF and Sender-ID come to the same conclusion about a message (that's > the ratio of the pass/pass plus fail/fail rows to the total). I > wasn't able to characterize the messages in the remaining less-than-5% > (e.g., they weren't all mailing list traffic). > Aah, I thought you had gathered data by querying 'n' domains for SPF and Sender-ID DNS records, but now I understand you have been collecting data by looking at real messages, sorry for any confusion I might have caused. /rolf --Boundary_(ID_2EoZuCL44xmFt+cKEMWpag) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, Murray,

On 4/3/12 6:16 AM, Murray S. Kucherawy wrote:

Hi Rolf,

 

The data I’ve been collecting over time records, in addition to lots of DKIM details, the SPF and Sender-ID results on each message if they’re available.  The answer to the question, then, is to count the number of records for each pass/fail combination of SPF and Sender-ID, and report that.  There are only four possible combinations to that truth table.  The numbers in my data show that over 95% of the time, SPF and Sender-ID come to the same conclusion about a message (that’s the ratio of the pass/pass plus fail/fail rows to the total).  I wasn’t able to characterize the messages in the remaining less-than-5% (e.g., they weren’t all mailing list traffic).


Aah, I thought you had gathered data by querying 'n' domains for SPF and Sender-ID DNS records, but now I understand you have been collecting data by looking at real messages, sorry for any confusion I might have caused.

/rolf
--Boundary_(ID_2EoZuCL44xmFt+cKEMWpag)-- From hsantos@isdg.net Tue Apr 3 14: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 3531B11E8106 for ; Tue, 3 Apr 2012 14:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MA3QxAL1s4U for ; Tue, 3 Apr 2012 14:15:56 -0700 (PDT) Received: from pop3.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 52BA111E809D for ; Tue, 3 Apr 2012 14:15:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1531; t=1333487741; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=uT16GtEA0ee1B4TCKQypCt1PzCo=; b=pT8828Usnz8yPL9O0dUf QuL1qC7bmh6563GYtj2nnngq6ccfdxEs+ipkX6nSimGqFFd6LrL0yfej8rAh0Gao hElfN5kvTvHxu7r55E4XM7RcoiA0jnrU34wOmeVSrEZ4n1yDngQluYWpXVCvVIFa LF1PECauU3xT979NJ5j7rAc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 17:15: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2394578722.15526.5576; Tue, 03 Apr 2012 17:15:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1531; t=1333487435; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=2goO5IV haiU/nThkfG4nzcd+4JogM9k2fQcJGkiWr0w=; b=OsurNipvIg/GhUgaUio0/tZ /tCQlpRiGm1aQOCharXz4Ox0nGtMdK5jeeTCXAcnfjc+93+Az2n1sCBEUBhfoRdw MGGBka+QCczZ+HBtR1KlKRpgZ6dr/jzAif9FBDMgzpeajjiOj9mAJm/Ttz0ga0Da gjvpT5Pj88BkMB3Dic1c= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 17:10:35 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2993490877.37728.2112; Tue, 03 Apr 2012 17:10:34 -0400 Message-ID: <4F7B686F.3060000@isdg.net> Date: Tue, 03 Apr 2012 17:15: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: <9452079D1A51524AA5749AD23E0039280C677E@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C7BD1@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C7BD1@exch-mbx901.corp.cloudmark.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] SPF survey data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 21:15:57 -0000 Hi Murray, Please allow some time to analyze the collection. Not sure if 1 week is good, but isn't for me. I will try to prioritize it. I did have some post IETF meeting comments, including input to the request made at the meeting (i.e. pro/cons for received-spd/auth res), but didn't have the time to complete the note. However, I do think it will help to have some starter text to work with. Thanks. Murray S. Kucherawy wrote: > Revised URI: > > http://www.blackops.org/~msk/spfbis > > ...now contains my survey's SQL dump (spf.mysql) as well as Philip's (spf.db.gz). > > -MSK > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy > Sent: Monday, April 02, 2012 1:35 PM > To: spfbis@ietf.org > Subject: [spfbis] SPF survey data > > I have posted the mysqldump output of my SPF record survey at http://www.blackops.org/~msk/spf.mysql for anyone that wants to import the data and run your own analyses. It's 42Mb in size. > > Hoping to have a revision to the experiment document by the end of this week. As nobody has put forth any suggested conclusions, I'll come up with some of my own and we can debate or agree on those. > > -MSK > > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Tue Apr 3 15:05: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 77F6B11E809A for ; Tue, 3 Apr 2012 15:05:45 -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_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioEq93Skxaz6 for ; Tue, 3 Apr 2012 15:05:44 -0700 (PDT) Received: from winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 28B3F11E8074 for ; Tue, 3 Apr 2012 15:05:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3419; t=1333490737; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=3OW82Z5K18hPlsMgaFLgJ3MiLNQ=; b=UtcnF/zagEMTU4FlhY07 M9R/RXk0/jMkiQEPQeuI6zN7xPxdMpg4gurMoRDWntQRetAXQ6sS3HnyqpmXWouC Thg9YySr3kTs5xJpRMjm4J5hOfwpk3S0zgd/gFHRU12MINEaiqZhlH8jMkwIdWWR O/F2Cb6ACaBaSCy5ft7zho4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 18:05: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2397573895.15526.3980; Tue, 03 Apr 2012 18:05:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3419; t=1333490430; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=1pcDT9X 05cNkUemd870Chjt+cXvO/44H96ylBtuFS0w=; b=PdaFMnTWPNTjaQTb6KXt8ct bsP4jJJ9++Gco/lCI5wDrC1QJhJX7iiy6vYobMfdQg+InuxsZrdsWHd36Bi/w1/C PyM/qZry2SNIW9cA6GOAR+G1Ad1C4454E6/Q5CPSB93NUCVr2sqn7pxNEFztRSUE OsDvBizSdrDj0Wiq67EM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 18:00:30 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2996485424.37747.3260; Tue, 03 Apr 2012 18:00:29 -0400 Message-ID: <4F7B7423.8040400@isdg.net> Date: Tue, 03 Apr 2012 18:05:23 -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: <9452079D1A51524AA5749AD23E0039280C677E@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C7BD1@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C7BD1@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF survey data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 22:05:45 -0000 Hi, I did a quick import of the spf.mysql. Regarding type 99: From the simple SQL queries made, -- count = 2,701 select count(*) from spf where (type=99 and data <> '') ; it is my opinion it continues with the idea that there is significant deployment of type 99 usage to warrant client query and further, if SPFBIS does end up with recommending continuing supporting, I believe that will see the increase migration and publishing to type 99. So to me, it can go either way. The question for me has always been whether it benefits the DNS network to continue down this path. I guess I am optimistic that one day we will have optimal DNS client/server query methods to address the dual record support needs. I believe there are strong desirable interest in this area and there is evidence the "Microsoft Contingent Staff" (whatever that is) is looking into its current lack of support for unnamed types in its DNS servers. See this thread in MSDN: http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/5841e884-db22-42a1-8530-615a375662cc#1431a54d-2735-4c5d-ad3b-6b8a7e0ba6d4 The fact this was not a resolved issue, MS DNS MVPs (if ACE is not aware of it, wow!) or there was no feed back with his Microsoft DNS MVP peers, does not give me confident the unnamed types issue is a big concern with Microsoft for its DNS servers. On the other hand, it may depend on the IETF DNS doing a better job in technical sales and pushing the issue. Overall, I have been a bit vex at seeing what appears to be lack of technical leadership on this matter. It seems that we just don't care anymore, DNS, Hardware, "Interpretative Script Languages" are fast today and that TXT is, well, "just good enough" and there will is no longer an expectation of see any brush back from the DNS people come LC and standardization of SPF. So if TXT is the new "normal" for fast entry and declaring domain attribute or policy record information and its ok by the IETF/IESF/DNS community, then lets just look for the lesser overhead changes to SPFBIS in this regard - drop type 99. Or do we still want to see what Microsoft has to say here? To me, this is very important as Microsoft DNS servers, *nix wienies like it or not, is a still big part of the network. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: > Revised URI: > > http://www.blackops.org/~msk/spfbis > > ...now contains my survey's SQL dump (spf.mysql) as well as Philip's (spf.db.gz). > > -MSK > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy > Sent: Monday, April 02, 2012 1:35 PM > To: spfbis@ietf.org > Subject: [spfbis] SPF survey data > > I have posted the mysqldump output of my SPF record survey at http://www.blackops.org/~msk/spf.mysql for anyone that wants to import the data and run your own analyses. It's 42Mb in size. > > Hoping to have a revision to the experiment document by the end of this week. As nobody has put forth any suggested conclusions, I'll come up with some of my own and we can debate or agree on those. > > -MSK > > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From pgladstone@cisco.com Tue Apr 3 17:40: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 D6B6211E80A0 for ; Tue, 3 Apr 2012 17:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7ADienlCQd7 for ; Tue, 3 Apr 2012 17:40:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0AA11E8075 for ; Tue, 3 Apr 2012 17:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=2483; q=dns/txt; s=iport; t=1333500039; x=1334709639; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=aDogWqbapSYpHLwDV8K0E/yGjz3coXRCoMAMLV+TbcI=; b=PxpyLioT+R8aj29Wy3sgq7fujUxGA2ffqcd+84+9fh8ogNscuHT1RRfg rcso32GMWnZumUcGP+trhKgGKzj+mtLez40ABZnZ39bn+/DFure7hpQXp YKL/YvpU28e4Cmjh3753ZNs/8sjFoLmx7Jsd6K5GGHWUDM+BeeD+sQZ5f k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GAI6Xe0+tJXG8/2dsb2JhbABAAxaDCII9skWBB4IJAQEBBBIBEFUPAgsEARMJFgsCAgkDAgECAQk8EwYCAQEFGYdnC59gjQiKBgSNHAWCDIEYBJVjhXCIV4FpgwM X-IronPort-AV: E=Sophos;i="4.75,365,1330905600"; d="scan'208,217";a="71877890" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 04 Apr 2012 00:40:38 +0000 Received: from [10.117.107.21] (rtp-pgladsto-8914.cisco.com [10.117.107.21]) by rcdn-core2-1.cisco.com (8.14.5/8.14.3) with ESMTP id q340ecfT028553 for ; Wed, 4 Apr 2012 00:40:38 GMT Message-ID: <4F7B9885.3010003@cisco.com> Date: Tue, 03 Apr 2012 20:40:37 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039280C2AF5@exch-mbx901.corp.cloudmark.com> <4F762676.7030906@sonnection.nl> <9452079D1A51524AA5749AD23E0039280C6F68@exch-mbx901.corp.cloudmark.com> <4F7B5693.1050501@sonnection.nl> In-Reply-To: <4F7B5693.1050501@sonnection.nl> Content-Type: multipart/alternative; boundary="------------030405070809010401000804" Subject: Re: [spfbis] Experiment document X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 00:40:39 -0000 This is a multi-part message in MIME format. --------------030405070809010401000804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/3/2012 3:59 PM, Rolf E. Sonneveld wrote: > > Aah, I thought you had gathered data by querying 'n' domains for SPF > and Sender-ID DNS records, but now I understand you have been > collecting data by looking at real messages, sorry for any confusion I > might have caused. > > /rolf > You may have been confusing Murray's data with my data. My data was gathered by querying 1 million domains as you describe. The repository at http://www.blackops.org/~msk/spfbis contains both data sets. Philip > -- > Philip Gladstone > Distinguished Engineer > Product Development > pgladstone@cisco.com > Phone: +1 978-ZEN-TOAD (+1 978 936 8623) > Google: +1 978 800 1010 > Ham radio: N1DQ --------------030405070809010401000804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

On 4/3/2012 3:59 PM, Rolf E. Sonneveld wrote:

Aah, I thought you had gathered data by querying 'n' domains for SPF and Sender-ID DNS records, but now I understand you have been collecting data by looking at real messages, sorry for any confusion I might have caused.

/rolf

You may have been confusing Murray's data with my data. My data was gathered by querying 1 million domains as you describe. The repository at http://www.blackops.org/~msk/spfbis contains both data sets.

Philip
-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
--------------030405070809010401000804-- From hsantos@isdg.net Tue Apr 3 17:50: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 3089E11E80E3 for ; Tue, 3 Apr 2012 17:50:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeF9f+iQe7xN for ; Tue, 3 Apr 2012 17:50:00 -0700 (PDT) Received: from news.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F266611E8075 for ; Tue, 3 Apr 2012 17:49:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2821; t=1333500592; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=znXrQUtHyRTanLdc0aPov8YENgs=; b=HWF/rh0MrWVus2M1fB2h A0N7iXzC3ULsHyjizXIF2NiAhFtN0C6KXeSVIfGM8w5E6mw3ZiUraloztkcBeNrQ ubpPJ4hQTbLLKXP9RV3X1YzTpemYsbcD0OuruOlSUYyaW6+7rBGDyX+Q4m+y7drk 20yrs/BPa9y9dtGo353EVFI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 20:49: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2407429086.15526.1968; Tue, 03 Apr 2012 20:49:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2821; t=1333500286; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ugg7+D5 VRZvZUhBcDB585pQC88s5DErNvJ0r3Tzz5mU=; b=oUsrSgBsOGhDdXfQW1wW2LT y3zHv4tQgHqbqzdE3qUZS1bZ4BXtw72SHxOhKgnqp6LI1T1ioSxbgYSlw9D0coRV E+C6V3p/nHkgbRbtC8qVGUtnhSjTyKC+wW49CpG144g5c7iSclKqA8QImdUdJxC1 iCA6e1V1W/Px1P/J0qrA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 20:44:46 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3006341033.37762.3220; Tue, 03 Apr 2012 20:44:44 -0400 Message-ID: <4F7B9AA2.1040309@isdg.net> Date: Tue, 03 Apr 2012 20:49:38 -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: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <4F6DED16.4060705@tana.it> <4F7B1528.5090104@tana.it> <11504137.h5tzZM0OXg@scott-latitude-e6320> <4F7B3317.2060507@tana.it> In-Reply-To: <4F7B3317.2060507@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 00:50:01 -0000 Alessandro Vesely wrote: >> Adding Old-Received-SPF would be a new requirement and I don't think it has >> wide spread adoption. > > I would leave this field's spec as it is, except mentioning RFC 5451 > and thus recommending that at least one of those fields be used, and > possibly that in case both are used they should/must agree at least on > the result and on the mandated key-value pairs. > > However, if Murray finds out where in the experiment doc it is worth > to mention this renaming approach, I'd agree. Received-SPF can be > considered a precursor of Authentication-Results, although I don't > know if any of its traits did actually influence any of RFC 5451's ideas. There has been this "elephant in the room" regarding DKIM. I would like to set the record straight my position on the matter, if not already stated before. I believe in Murray's effort to integrate, consolidate the various related email augmented protocols and specifically, SPF and DKIM. My only concerns is any mindset or efforts to replace SPF and/or SIDF by watering it down with DKIM. IMV, there causes conflicts, but I think there is a compromising solution when it is accepted and recognize SPF has a very fundamental strong deterministic hardfail policy for rejection that MUST NOT confused with domain intentions and doubt. DKIM had a strong deterministic framework with SSP (nor ADSP) but it was watered down when the unfortunately injection provision was written in section 10 in RFC5016: 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. This is my main concern with the SPFBIS efforts - strong local receiver policy honoring of SPF hardfail domain policies can be at risk with the introduction of AUTH-RES and new similar relaxing semantics are rejected suggesting local SPF receivers should not "impugn" on the existence of DKIM information in the message. IMV, Auth-Res is important because it provides a means to couple SPF and DKIM results for mail filtering "evaluators" however, SPFBIS MUST also recognize that a SPF domain hardfail violation may not be regarded using a Received-SPF or a AUTH-RES. So IMO, Auth-Res should/could be introduced as a way to regard indeterminate SPF results to assist evaluators of the aggregated AUTH-RES results. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Tue Apr 3 17:54: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 8FBC321F8546 for ; Tue, 3 Apr 2012 17:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmljJrLkSaSN for ; Tue, 3 Apr 2012 17:54:00 -0700 (PDT) Received: from news.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D968E21F8523 for ; Tue, 3 Apr 2012 17:53:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=875; t=1333500837; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gA4loM/i0F/XIVDKuQITDHOAZls=; b=piyZajz3rZlAJlol6FGd FQqxUJz10IHkWNLAGAczu4gHsG6+ISVNmbLeuKKwnlcw7C/+gUR0wUPYgq05Y+Gt dqkvqIEics3NzPWjN/3eqXxfmLmo8CumNO2f7lJ2TadhgpKySwWd/n+iwUW0ISdS 8Tvz5Hi/06/yVKqocOT6ABw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 20:53:57 -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 v6.4.454.1) with ESMTP id 2407674211.15526.1580; Tue, 03 Apr 2012 20:53:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=875; t=1333500530; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=t+zrvz+ drTgIUDZ663UNNoZzLr2hJ6Q1fIGVc+CgUN0=; b=WdvCKaRSqfeid4dB8slado7 0Y5GLZNBAH1vnx6XUq4glNy2BJZt4SmGOa49gtPFRs3xUfld+31+3Zr5Qd61F1J2 dS7frxSroDj87TU99Q/JLpB4cMsQXpTDpEAEMEz26WOisfSoqj0FCJcPm+Sgjm4H bYLL0+gnAd6AUYYx/UdY= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 20:48:50 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3006584924.37763.6472; Tue, 03 Apr 2012 20:48:48 -0400 Message-ID: <4F7B9B98.9010203@isdg.net> Date: Tue, 03 Apr 2012 20:53:44 -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: <9452079D1A51524AA5749AD23E0039280C2AF5@exch-mbx901.corp.cloudmark.com> <4F762676.7030906@sonnection.nl> <9452079D1A51524AA5749AD23E0039280C6F68@exch-mbx901.corp.cloudmark.com> <4F7B5693.1050501@sonnection.nl> <4F7B9885.3010003@cisco.com> In-Reply-To: <4F7B9885.3010003@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Experiment document X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 00:54:00 -0000 Philip Gladstone wrote: > > > On 4/3/2012 3:59 PM, Rolf E. Sonneveld wrote: >> >> Aah, I thought you had gathered data by querying 'n' domains for SPF >> and Sender-ID DNS records, but now I understand you have been >> collecting data by looking at real messages, sorry for any confusion I >> might have caused. >> >> /rolf >> > You may have been confusing Murray's data with my data. My data was > gathered by querying 1 million domains as you describe. The repository > at http://www.blackops.org/~msk/spfbis contains both data sets. > > Philip Hi Philip, It would help to indicate the your data is an SQLITE3 database table and Murray's is an MySQL dump that requires an creating a database first. Posting the schema and meaning of the fields would help too. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Tue Apr 3 18:47: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 9648121F85E5 for ; Tue, 3 Apr 2012 18:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkvll4Q57vdL for ; Tue, 3 Apr 2012 18:47:26 -0700 (PDT) Received: from pop3.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AFA7121F85E3 for ; Tue, 3 Apr 2012 18:47:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1443; t=1333504042; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=iALyJZjX8vWgo9ZISm84XX6oQJU=; b=eIZFbdZlIzrkPDssc0vv VmQwmFex9RI5BwcGIxkyi5XKtmVVpLTrEQdVdweAfKI2CXej/PT2XjsIl8eLvV1D Wsm/Yfzbmb3yEEGhcIPZVvDoEsQSYciwqem+gTA3yY9593xDk7V3WoG/8q+SLRPT wyGvNHw/L8LPIfGIsZQt3fw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 21:47:22 -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 v6.4.454.1) with ESMTP id 2410879610.15526.1120; Tue, 03 Apr 2012 21:47:22 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1443; t=1333503735; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Gldl4TA U0hjFyVrQfd57mR4yRQMNMsYSdob1y2+a0f0=; b=kzfrJlPazhGlhmy6AyBY+BS yRVOvgzCHKBrEtp3S1HsCw9NSiQi3b/aHjvLgDR7t0wLIbuzui3sNj68oGLQcZ5I UZEp4UbUh3bKBD2KdFkXPmD0pgF6GpLpwZdzKjHGG0mdAAH1/N7vVzGOUUTIiQVg HQBJiPKdll3IDCrZUUto= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Apr 2012 21:42:15 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3009790424.37766.4312; Tue, 03 Apr 2012 21:42:14 -0400 Message-ID: <4F7BA81C.6050001@isdg.net> Date: Tue, 03 Apr 2012 21:47:08 -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: <4F74E77A.3040503@meetecho.com> <6.2.5.6.2.20120330043944.0dd1cf40@resistor.net> In-Reply-To: <6.2.5.6.2.20120330043944.0dd1cf40@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Team Meetecho , vmeet@ietf.org Subject: Re: [spfbis] Meetecho support for SPFBIS WG meeting session X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 01:47:26 -0000 S Moonesamy wrote: > Hello > There are some user interface and user issues when using Meetecho (I > mistakenly broadcasted video). I used a standalone XMPP client instead > of following the Meetecho (XMPP) chat window. > > Could other remote participants for this session please provide feedback > on: My setup is a factor in my experience: Provider: AT&T U-verse Bandwidth: 5gb download, 3gb upload Browsers: Chrome > (a) What worked for you? Everything except.... > (b) What did not work for you? the Video Adapter. With Chrome, it didn't detect nor have install the java engine. I tried it with FF and it didn't seem to complete its initialization. I was too impatience and just stuck with Chrome. > (c) Could you follow the WG session? Yes, although there was a 2-3 secs lag in Audio/Jabber scribing, it was adequate. > > (d) Do you feel that you were able to participate adequately in the > discussions? Yes. > > (e) Do you feel that you were able to participate adequately in the > decision-making? Yes, if I feel compel to raise a point, I did. Otherwise I felt the meeting was well covered. > (f) Do you have a better understanding of how WG issues can be > resolved after following this session? Yes. It was helpful in showing being involved goes a long way to be part of the process. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Tue Apr 3 19:00: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 C18A921F8629 for ; Tue, 3 Apr 2012 19:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StCT8vnI-+0u for ; Tue, 3 Apr 2012 19:00:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8420221F8624 for ; Tue, 3 Apr 2012 19:00:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B821620E410E; Tue, 3 Apr 2012 21:59:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1333504799; bh=n+DP5rV4cfea7IgibczW11pNxfrESJbZRU8PXyUgi/g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=jjnJcKrX/TNBnl0hdZ2MZc6tosaEbM6UVmvM5Aonhc9CkDIAA8wopFNMI4KfBmIli JgLNG0L1TZqfixzkq2pLKF1I7HASKnuJqGkFyGhhipUBerriQXXBqlp5+/5yTNr2Cm 4eZ28RqHQLeF80t54KP6KTUSLTDURExThckG/OTY= Received: from scott-latitude-e6320.localnet (74-222-219-222.dyn.everestkc.net [74.222.219.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 875E220E4064; Tue, 3 Apr 2012 21:59:59 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Apr 2012 21:59:58 -0400 Message-ID: <2548869.gpH47H9usM@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-17-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F7B9AA2.1040309@isdg.net> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <4F7B3317.2060507@tana.it> <4F7B9AA2.1040309@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] #10: RFC 4408 replace Received-SPF with RFC5451 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 02:00:01 -0000 On Tuesday, April 03, 2012 08:49:38 PM Hector Santos wrote: > Alessandro Vesely wrote: > >> Adding Old-Received-SPF would be a new requirement and I don't think > >> it has wide spread adoption. > > > > I would leave this field's spec as it is, except mentioning RFC 5451 > > and thus recommending that at least one of those fields be used, and > > possibly that in case both are used they should/must agree at least on > > the result and on the mandated key-value pairs. > > > > However, if Murray finds out where in the experiment doc it is worth > > to mention this renaming approach, I'd agree. Received-SPF can be > > considered a precursor of Authentication-Results, although I don't > > know if any of its traits did actually influence any of RFC 5451's > > ideas. > > There has been this "elephant in the room" regarding DKIM. I would > like to set the record straight my position on the matter, if not > already stated before. > > I believe in Murray's effort to integrate, consolidate the various > related email augmented protocols and specifically, SPF and DKIM. My > only concerns is any mindset or efforts to replace SPF and/or SIDF by > watering it down with DKIM. IMV, there causes conflicts, but I think > there is a compromising solution when it is accepted and recognize SPF > has a very fundamental strong deterministic hardfail policy for > rejection that MUST NOT confused with domain intentions and doubt. > > DKIM had a strong deterministic framework with SSP (nor ADSP) but it > was watered down when the unfortunately injection provision was > written in section 10 in RFC5016: > > 10. SSP MUST NOT provide a mechanism that impugns the existence of > non-first party signatures in a message. A corollary of this > requirement is that the protocol MUST NOT link practices of first > party signers with the practices of third party signers. > > INFORMATIVE NOTE: the main thrust of this requirement is that > practices should only be published for that which the publisher > has control, and should not meddle in what is ultimately the > local policy of the receiver. > > This is my main concern with the SPFBIS efforts - strong local > receiver policy honoring of SPF hardfail domain policies can be at > risk with the introduction of AUTH-RES and new similar relaxing > semantics are rejected suggesting local SPF receivers should not > "impugn" on the existence of DKIM information in the message. > > IMV, Auth-Res is important because it provides a means to couple SPF > and DKIM results for mail filtering "evaluators" however, SPFBIS MUST > also recognize that a SPF domain hardfail violation may not be > regarded using a Received-SPF or a AUTH-RES. > > So IMO, Auth-Res should/could be introduced as a way to regard > indeterminate SPF results to assist evaluators of the aggregated > AUTH-RES results. I think that (your last paragraph) is what's proposed. I think use of auth- res for SPFbis is just a natural evolution and unrelated to any larger architectural considerations. Scott K From dotis@mail-abuse.org Tue Apr 3 20:14: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 1B08611E809B for ; Tue, 3 Apr 2012 20:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZqwAgohMdpl for ; Tue, 3 Apr 2012 20:14:55 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 581F511E8072 for ; Tue, 3 Apr 2012 20:14:54 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 7ABCD17403B2 for ; Wed, 4 Apr 2012 03:14:53 +0000 (UTC) Message-ID: <4F7BBCAB.6070705@mail-abuse.org> Date: Tue, 03 Apr 2012 20:14:51 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: SPFbis discussion list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Simplified DDoS concern statement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 03:14:56 -0000 Dear Andrew, Scott, and John, I'll attempt to simplify SPF DDoS discrepancies in response to statements made in the WG meeting without getting too bogged down in details. Those developing SPF offered senders a new role in the selection of DNS services by adding macros that construct "hostnames" in conjunction with "answer" processing. Such macros provided malefactors an ability to have recipients target specific resources using a macro expansion process that requires all DNS transactions be replayed every time a check_host() identity is being resolved. Normally DNS resolves services where clients use hostnames to obtain random or round-robin lists of IP addresses for hosts offering the desired service that can be truncated to fit within a single DNS response. Instead, SPF attempts to define a complete set of IP addresses for ALL hosts authorized to originate a domain's messages used by the recipient. This much larger response is obtained using ahigher level check_host() process that repeats DNS transactions while combining up to 10 additional TXT resource records or macro "mechanisms" where each "mechanism" may include 10 additional DNS transactions which may result in a total of 100 targeted and reflected transactions on behalf of an unknown entity. Email is heavily abused and often leveraged by fairly successful social engineering attacks. As a result, many institutions recommend various authentication or authorization strategies to better vet inbound email. Increased promotion of SPF, when it can be leveraged by malefactors, becomes a growing concern. SPF has not represented a significant opportunity since most large domains don't use SPF to reject messages due to erroneous rejection rates requiring expensive customer support. Exploitation opportunities may grow as otheracceptance policies combine with SPFand its use becomes more common. While indeed SpamAssassin among other email vetting processes make extensive use of DNS, these transactions are against services scaled to handle the volume, such as Surbl, Razor, Pyzor, DCC, and iXhash using specialized DNS zones supporting these various vetting strategies. Extensive use of these typical DNS based services do not permit malefactors a means to target their transactions, however processing incoming email generates extensive levels of legitimate DNS traffic. Local-part macros exemplify a method that allows malefactors a means to leverage cached SPF records to repeatedly generate lengthy DNS transaction sequences. SPF recommends "Mail From" and "HELO" identities be resolved even though neither of these are normally visible to recipients. As currently defined, SPF may still return a "Pass" result after receiving 100 "no data" responses to requests made against non-existent resources in a victim's domain. None of these hosts may be apparent within the triggering message which provides malefactors a means to avoid virtually all current email vetting strategies. In addition, victim domains are completely independent of malefactor domains. It is common to impose shortened limits on retention of negative answers to avoid customer support calls. Once a spam campaign extends beyond a recipient's negative caching limits, repeated use of local-parts will not require malefactors to expend additional resources when generating repeated transactions against victim domains. draft-otis-spf-dos-exploit-01 showed resolving just the "Mail From" identity for a single message generated 34.8K bytes from a victim's name server in response to 28.8K bytes of recipient requests without use of DNSsec. Per message traffic doubles when HELO identities are also resolved because fictitious sub-domains can replace the role of the local-part macro at the expense of caching additional SPF records for each new fictitious sub-domain. As with other resource records supplied by malefactors, these too can be reused after a spam campaign extends beyond the recipient's negative caching limits. While there are other methods available for staging DDoS attacks, risks pertaining to SPF can be easily mitigated without negatively impacting its utility. Murray's SPF database showed only 24 domains used local-part macros. Seven of these domains did not include IP address macros necessary to prevent trivially spoofed messages that place recipients at risk. Use of local-part macros also permits unconstrained dictionary attacks that can expose a domain's valid local-parts. This also represents a use level lower than that used to justify deprecation of SPF (type 99) resource records. A sound interim solution that prevents disruption of services would be to always assert "postmaster" for any local-part reference. This scheme is required to work, or respective servers would be unable to send NDNs from that domain. Since SPF still permits malefactors an ability to target victim domains from recipient resources, reasonable limits should be required for no-data and name error results seen within the check_host() process. It is also unreasonable to expect those operating inbound MTAs are likely to be aware of their possible role in a DDoS attack, or that other services have resources able to absorb even a small fraction of this possible traffic. Use of RFC5451 supplanting the SPF-Received header field would make it more difficult to identify compromised sources. Regards, Douglas Otis From spf2@kitterman.com Tue Apr 3 20:26: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 C3B3611E80D5 for ; Tue, 3 Apr 2012 20:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW2Pp0EtLRM8 for ; Tue, 3 Apr 2012 20:26:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BC38E11E8072 for ; Tue, 3 Apr 2012 20:26:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3531520E410E; Tue, 3 Apr 2012 23:26:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1333509967; bh=mFQmStYVeqf8AIIlTSay5NveJBrPo4h/NEGmOqI+/gY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=cT5JgcaF1W2qy+nm6I7evRN4007CYAFzsIFNPMIukVTZ3YTb7tAfYMWpcotaQsX+T i4nmRdjbL1Kvwc6yWaTaEyyTajTzsFVevgBs+AaiGypIAM6Sc/JhREPmMRg5XBG0LN hOmhnQIMPXrkq7PSc1QBbnv97gPCFXNSR/SVLGLQ= Received: from scott-latitude-e6320.localnet (74-222-219-222.dyn.everestkc.net [74.222.219.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0751820E4064; Tue, 3 Apr 2012 23:26:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Apr 2012 23:26:05 -0400 Message-ID: <1720603.org8o1OiP2@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-17-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F7BBCAB.6070705@mail-abuse.org> References: <4F7BBCAB.6070705@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Simplified DDoS concern statement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 03:26:08 -0000 On Tuesday, April 03, 2012 08:14:51 PM Douglas Otis wrote: > Dear Andrew, Scott, and John, > > I'll attempt to simplify SPF DDoS discrepancies in response to > statements made in the WG meeting without getting too bogged down in > details. > > Those developing SPF offered senders a new role in the selection of DNS > services by adding macros that construct "hostnames" in conjunction with > "answer" processing. Such macros provided malefactors an ability to > have recipients target specific resources using a macro expansion > process that requires all DNS transactions be replayed every time a > check_host() identity is being resolved. Normally DNS resolves services > where clients use hostnames to obtain random or round-robin lists of IP > addresses for hosts offering the desired service that can be truncated > to fit within a single DNS response. > > Instead, SPF attempts to define a complete set of IP addresses for ALL > hosts authorized to originate a domain's messages used by the > recipient. This much larger response is obtained using ahigher level > check_host() process that repeats DNS transactions while combining up to > 10 additional TXT resource records or macro "mechanisms" where each > "mechanism" may include 10 additional DNS transactions which may result > in a total of 100 targeted and reflected transactions on behalf of an > unknown entity. > > Email is heavily abused and often leveraged by fairly successful social > engineering attacks. As a result, many institutions recommend various > authentication or authorization strategies to better vet inbound email. > Increased promotion of SPF, when it can be leveraged by malefactors, > becomes a growing concern. SPF has not represented a significant > opportunity since most large domains don't use SPF to reject messages > due to erroneous rejection rates requiring expensive customer support. > Exploitation opportunities may grow as otheracceptance policies combine > with SPFand its use becomes more common. > > While indeed SpamAssassin among other email vetting processes make > extensive use of DNS, these transactions are against services scaled to > handle the volume, such as Surbl, Razor, Pyzor, DCC, and iXhash using > specialized DNS zones supporting these various vetting strategies. > Extensive use of these typical DNS based services do not permit > malefactors a means to target their transactions, however processing > incoming email generates extensive levels of legitimate DNS traffic. > > Local-part macros exemplify a method that allows malefactors a means to > leverage cached SPF records to repeatedly generate lengthy DNS > transaction sequences. SPF recommends "Mail From" and "HELO" identities > be resolved even though neither of these are normally visible to > recipients. As currently defined, SPF may still return a "Pass" result > after receiving 100 "no data" responses to requests made against > non-existent resources in a victim's domain. None of these hosts may be > apparent within the triggering message which provides malefactors a > means to avoid virtually all current email vetting strategies. In > addition, victim domains are completely independent of malefactor domains. > > It is common to impose shortened limits on retention of negative answers > to avoid customer support calls. Once a spam campaign extends beyond a > recipient's negative caching limits, repeated use of local-parts will > not require malefactors to expend additional resources when generating > repeated transactions against victim domains. > draft-otis-spf-dos-exploit-01 showed resolving just the "Mail From" > identity for a single message generated 34.8K bytes from a victim's name > server in response to 28.8K bytes of recipient requests without use of > DNSsec. Per message traffic doubles when HELO identities are also > resolved because fictitious sub-domains can replace the role of the > local-part macro at the expense of caching additional SPF records for > each new fictitious sub-domain. As with other resource records supplied > by malefactors, these too can be reused after a spam campaign extends > beyond the recipient's negative caching limits. > > While there are other methods available for staging DDoS attacks, risks > pertaining to SPF can be easily mitigated without negatively impacting > its utility. Murray's SPF database showed only 24 domains used > local-part macros. Seven of these domains did not include IP address > macros necessary to prevent trivially spoofed messages that place > recipients at risk. Use of local-part macros also permits unconstrained > dictionary attacks that can expose a domain's valid local-parts. This > also represents a use level lower than that used to justify deprecation > of SPF (type 99) resource records. A sound interim solution that > prevents disruption of services would be to always assert "postmaster" > for any local-part reference. This scheme is required to work, or > respective servers would be unable to send NDNs from that domain. > > Since SPF still permits malefactors an ability to target victim domains > from recipient resources, reasonable limits should be required for > no-data and name error results seen within the check_host() process. It > is also unreasonable to expect those operating inbound MTAs are likely > to be aware of their possible role in a DDoS attack, or that other > services have resources able to absorb even a small fraction of this > possible traffic. Use of RFC5451 supplanting the SPF-Received header > field would make it more difficult to identify compromised sources. The problem is not failing to understand the concern you are stating. It is not agreeing with it. There is nothing new here. Scott K From msk@cloudmark.com Tue Apr 3 20: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 15E1111E8079 for ; Tue, 3 Apr 2012 20:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azIyNGO3VYPB for ; Tue, 3 Apr 2012 20:55:31 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9711E8072 for ; Tue, 3 Apr 2012 20:55:25 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 20:55:24 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 Thread-Index: AQHNASt8VedQGBvKIkWWdm+y3YjKp5ZqmloAgAymWoCAABApgIAAugYAgAAo05CAAerAAIAPrw0AgAAZlICAAAobgIAAe28AgAATpwD//6otcA== Date: Wed, 4 Apr 2012 03:55:23 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C8904@exch-mbx901.corp.cloudmark.com> References: <061.98de32b61319d4971e51f4bca76a455a@tools.ietf.org> <4F7B3317.2060507@tana.it> <4F7B9AA2.1040309@isdg.net> <2548869.gpH47H9usM@scott-latitude-e6320> In-Reply-To: <2548869.gpH47H9usM@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 03:55:32 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, April 03, 2012 7:00 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451 >=20 > > So IMO, Auth-Res should/could be introduced as a way to regard > > indeterminate SPF results to assist evaluators of the aggregated > > AUTH-RES results. >=20 > I think that (your last paragraph) is what's proposed. I think use of > auth- res for SPFbis is just a natural evolution and unrelated to any > larger architectural considerations. I think Scott's last sentence is also right. (Or, to cite APPSAWG for those that were there, "Everything that was just s= aid is true.") -MSK From msk@cloudmark.com Tue Apr 3 21: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 9B81E21F84F6 for ; Tue, 3 Apr 2012 21:13:45 -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.570, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to2Nm-NsEZlc for ; Tue, 3 Apr 2012 21:13:45 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3199921F84EF for ; Tue, 3 Apr 2012 21:13:45 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 21:13:44 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Experiment document Thread-Index: Ac0OX1JElkOuVjEpSX+EejibzakHPAAl/sEAAJYa8LAAL8yQgAAJ052AAAB1RgAACE6VQA== Date: Wed, 4 Apr 2012 04:13:44 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C8931@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C2AF5@exch-mbx901.corp.cloudmark.com> <4F762676.7030906@sonnection.nl> <9452079D1A51524AA5749AD23E0039280C6F68@exch-mbx901.corp.cloudmark.com> <4F7B5693.1050501@sonnection.nl> <4F7B9885.3010003@cisco.com> <4F7B9B98.9010203@isdg.net> In-Reply-To: <4F7B9B98.9010203@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Experiment document X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 04:13:45 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Hector Santos > Sent: Tuesday, April 03, 2012 5:54 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Experiment document >=20 > It would help to indicate the your data is an SQLITE3 database table > and Murray's is an MySQL dump that requires an creating a database > first. Posting the schema and meaning of the fields would help too. > :) It is indeed SQLITE3. You can get the schema from the .schema command: % sqlite3 spf.db SQLite version 3.6.14.2 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .schema CREATE TABLE "spf"(domain varchar(255), record varchar(255), rrtype varchar= (3)); CREATE UNIQUE INDEX spfrr2 on spf(domain, rrtype); Philip's survey was of one million domains, though I don't know how he sele= cted for them. The columns are (obviously) the domain name, the content of= the retrieved record, and the type of the retrieved record. His survey on= ly recorded answers he actually received, and did not record multiple insta= nces of each record type because of the unique index. My survey used MySQL. For the full schema, use either "DESCRIBE spf" or "S= HOW CREATE TABLE spf". It polled 250,000+ domains that were reported throu= gh the OpenDKIM statistics reporting system, and all were domains for which= at some point both an SPF and Sender-ID result had been reported. It incl= udes both replies received and those for which an error or NXDOMAIN were re= turned (the "nxdomain" column) as well as the round-trip time measured in m= icroseconds for the query. If multiple records were returned for a single = query, all of them were recorded, though order cannot be preserved because = the returned order is randomized by the nameservers. It only reported the = returned content; it did not expand any macros (since this survey was not d= one during message receipt). Every domain should have at least one TXT row= and at least one SPF row, since a row is also used to log non-responses. = The columns are: id: unique row ID date: the date/time when the record was retrieved domain: the domain name that was queried type: either 16 (TXT) or 99 (SPF) data: the record's content nxdomain: 1 if there was an error or if a non-reply was returned, 0 otherw= ise rtt: round-trip time, in microseconds I periodically re-run my survey to collect records for new domains not seen= since the previous pass, but there aren't that many new ones going in now. Despite the Subject: of this message, these reports will be very useful inp= ut to the SPFbis document itself when considering what's in use and what is= n't. Let me know if there are any other questions.=20 -MSK From msk@cloudmark.com Tue Apr 3 21:15: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 CC5BB21F84F6 for ; Tue, 3 Apr 2012 21:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.817 X-Spam-Level: X-Spam-Status: No, score=-102.817 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXcwTsMsks+H for ; Tue, 3 Apr 2012 21:15:02 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7073821F84EF for ; Tue, 3 Apr 2012 21:15:02 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 21:15:01 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] SPF survey data Thread-Index: Ac0REAQH1YRvhKczQwizGYXe19gqBQAwB2PQABJXiYAAAAeDIA== Date: Wed, 4 Apr 2012 04:15:00 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C8947@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C677E@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C7BD1@exch-mbx901.corp.cloudmark.com> <4F7B6853.8020901@santronics.com> In-Reply-To: <4F7B6853.8020901@santronics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [spfbis] SPF survey data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 04:15:02 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZWN0b3IgU2FudG9zIFttYWls dG86aHNhbnRvc0BzYW50cm9uaWNzLmNvbV0NCj4gU2VudDogVHVlc2RheSwgQXByaWwgMDMsIDIw MTIgMjoxNSBQTQ0KPiBUbzogTXVycmF5IFMuIEt1Y2hlcmF3eQ0KPiBDYzogc3BmYmlzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbc3BmYmlzXSBTUEYgc3VydmV5IGRhdGENCj4gDQo+IFBsZWFz ZSBhbGxvdyBzb21lIHRpbWUgdG8gYW5hbHl6ZSB0aGUgY29sbGVjdGlvbi4gIE5vdCBzdXJlIGlm IDEgd2Vlaw0KPiBpcyBnb29kLCBidXQgaXNuJ3QgZm9yIG1lLiAgSSB3aWxsIHRyeSB0byBwcmlv cml0aXplIGl0LiAgSSBkaWQgaGF2ZQ0KPiBzb21lIHBvc3QgSUVURiBtZWV0aW5nIGNvbW1lbnRz LCBpbmNsdWRpbmcgaW5wdXQgdG8gdGhlIHJlcXVlc3QgbWFkZSBhdA0KPiB0aGUgbWVldGluZyAo aS5lLiBwcm8vY29ucyBmb3IgcmVjZWl2ZWQtc3BkL2F1dGggcmVzKSwgYnV0IGRpZG4ndCBoYXZl DQo+IHRoZSB0aW1lIHRvIGNvbXBsZXRlIHRoZSBub3RlLg0KDQpXaGF0ZXZlciBJIHBvc3QgbGF0 ZXIgdGhpcyB3ZWVrLCBpdCdzIGhpZ2hseSB1bmxpa2VseSB0aGF0IGl0IHdpbGwgYmUgYSBmaW5h bCB2ZXJzaW9uLiAgWW91IGNlcnRhaW5seSBoYXZlIHRpbWUgdG8gZG8geW91ciBvd24gZXZhbHVh dGlvbi4NCg0KLU1TSw0K From SRS0=PO3NJ=CK==stuart@gathman.org Tue Apr 3 23:12: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 6D87D21F85BD for ; Tue, 3 Apr 2012 23:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtR0mYVdV3EA for ; Tue, 3 Apr 2012 23:12: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 9290121F85BB for ; Tue, 3 Apr 2012 23:12:19 -0700 (PDT) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q346BLTm006965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Apr 2012 02:11:22 -0400 Message-ID: <4F7BE640.7000805@gathman.org> Date: Wed, 04 Apr 2012 02:12:16 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------000509010402030201090805" Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 06:18:59 -0000 This is a multi-part message in MIME format. --------------000509010402030201090805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Long ago, Nostradamus foresaw that on 03/24/2012 12:52 AM, Murray S. Kucherawy would write: > This an interesting tack, but I don't think I agree. SPF takes as > input a domain name and an IP address, does some crunching, and > returns a result. That result is deterministic. At the level of that > interface, the IP address of a forwarder is indistinguishable from any > other, so to say one class of IP address is valid while another is not > seems a non-sequitur to me. Any result produced by taking those two > pieces of input and following the SPF algorithm is an SPF result. If > two different systems have differing outputs given the same inputs, > then we have an interoperability problem and/or a broken > specification. Requiring different treatment of forwarders based on a > heuristic would not be an SPF result, in the same way rfc4408 says: 9.5. MTA Relays The authorization check generally precludes the use of arbitrary MTA relays between sender and receiver of an E-Mail message. Within an organization, MTA relays can be effectively deployed. However, for purposes of this document, such relays are effectively transparent. The SPF authorization check is a check between border MTAs of different domains. For mail senders, this means that published SPF records must authorize any MTAs that actually send across the Internet. Usually, these are just the border MTAs as internal MTAs simply forward mail to these MTAs for delivery. So, alias forwards that are requested/configured by the recipient are a border MTA for the recipients organization. If the alias forwarder does not do the SPF check, any SPF check must use the Received header from the forwarder and not the forwarders IP (or simply don't do the check at all). See paragraph 9.3 which also explains these options. Therefore, I believe you are incorrect. Simply plugging the alias forwarders IP and MAIL FROM domain into the SPF algorithm does NOT produce an SPF result according to rfc4408. --------------000509010402030201090805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Long ago, Nostradamus foresaw that on 03/24/2012 12:52 AM, Murray S. Kucherawy would write:
This an interesting tack, but I don't think I agree. SPF takes as input a domain name and an IP address, does some crunching, and returns a result. That result is deterministic. At the level of that interface, the IP address of a forwarder is indistinguishable from any other, so to say one class of IP address is valid while another is not seems a non-sequitur to me. Any result produced by taking those two pieces of input and following the SPF algorithm is an SPF result. If two different systems have differing outputs given the same inputs, then we have an interoperability problem and/or a broken specification. Requiring different treatment of forwarders based on a heuristic would not be an SPF result, in the same way
rfc4408 says:

9.5. MTA Relays 

   The authorization check generally precludes the use of arbitrary MTA
   relays between sender and receiver of an E-Mail message.

   Within an organization, MTA relays can be effectively deployed.
   However, for purposes of this document, such relays are effectively
   transparent.  The SPF authorization check is a check between border
   MTAs of different domains.

   For mail senders, this means that published SPF records must
   authorize any MTAs that actually send across the Internet.  Usually,
   these are just the border MTAs as internal MTAs simply forward mail
   to these MTAs for delivery.

So, alias forwards that are requested/configured by the recipient are a border MTA for the recipients organization.  If the alias forwarder does not do the SPF check, any SPF check must use the Received header from the forwarder and not the forwarders IP (or simply don't do the check at all).  See paragraph 9.3 which also explains these options.

Therefore, I believe you are incorrect.  Simply plugging the alias forwarders IP and MAIL FROM domain into the SPF algorithm does NOT produce an SPF result according to rfc4408.
--------------000509010402030201090805-- From SRS0=PO3NJ=CK==stuart@gathman.org Tue Apr 3 23:28: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 E79D421F86C2 for ; Tue, 3 Apr 2012 23:28: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHVFLBoK0Q26 for ; Tue, 3 Apr 2012 23:28:52 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 573D821F86A5 for ; Tue, 3 Apr 2012 23:28:52 -0700 (PDT) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q346Rtso007080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Apr 2012 02:27:56 -0400 Message-ID: <4F7BEA22.9050908@gathman.org> Date: Wed, 04 Apr 2012 02:28:50 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> In-Reply-To: <4F6EEFF5.3070306@tana.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 06:28:53 -0000 Long ago, Nostradamus foresaw that on 03/25/2012 06:14 AM, Alessandro Vesely would write: > Until we hold that reject-on-fail is valid, SPF is less optional than > it would seem at a first glance, because it affects a mail operation > that used to be possible without it. A sender who does not opt for SPF > can have its forwarded messages bounced because both the originator > and the target opted to implement SPF in such a way to break that > operation. In this respect, SPF has changed SMTP already, whether > we're gonna document that as an update or not. What's worse is that > there's no guidance on how to avoid such incidents. A protocol worth > its salt should allow to determine what parties are at fault in case > of malfunction. If by "sender" you mean an alias forwarder, then there are three cases: a) the alias forwarding was requested/authorized by the target. In this case, the target screwed up by trying to apply SPF to the forwarder, who has now become a "border MTA" of the target in the language of rfc4408. b) the alias forwarding was requested/authorized by the sender. In this case, the sender screwed up by failing to include the forwarder (who has now become a "border MTA" for the sender) in their Sender Policy. c) the alias forwarding was *not* authorized by the sender or target. In this case, the "forwarder" is a forger and SHOULD be rejected. In brief, an alias forwarder is either an agent of the sender - and therefore a border MTA of the sender, or an agent of the target - and therefore a border MTA of the target, or illegitimate. There is no forwarding problem. Only broken SPF records with sender authorized alias forwarders, or broken implementations for receiver authorized alias forwarders. From SRS0=PO3NJ=CK==stuart@gathman.org Tue Apr 3 23:36: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 4F50011E8093 for ; Tue, 3 Apr 2012 23:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcFW8ilha7QX for ; Tue, 3 Apr 2012 23:36:08 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id AAED411E808E for ; Tue, 3 Apr 2012 23:36:08 -0700 (PDT) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q346ZCRa007147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Apr 2012 02:35:12 -0400 Message-ID: <4F7BEBD7.40500@gathman.org> Date: Wed, 04 Apr 2012 02:36:07 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <9452079D1A51524AA5749AD23E003928098E77@exch-mbx901.corp.cloudmark.com> <4F6CD594.1090909@tana.it> <9452079D1A51524AA5749AD23E0039280995A3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280995A3@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 06:36:09 -0000 Long ago, Nostradamus foresaw that on 03/24/2012 12:57 AM, Murray S. Kucherawy would write: > I would bet real money that this is a non-starter. By doing so, you > would declare a big piece of the deployed email infrastructure > non-compliant. If I may paraphrase John Levine about MLMs: Forwarders > have been doing what they do for decades without complaints, so who > are we to suddenly tell them that they're wrong? Forwarders are not doing it wrong. If they are authorized by the sender, the sender needs to include them in his SPF record as another "border MTA". If authorized by the recipient, then the recipient needs to treat the forwarder as another "border MTA". (This is easier if a large forwarder publishes SPF so the recipient knows in an automatically updated manner which MTAs belong to the forwarder.) From SRS0=PO3NJ=CK==stuart@gathman.org Tue Apr 3 23:40: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 D10EE21F862F for ; Tue, 3 Apr 2012 23:40: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPAYmwfyvdfd for ; Tue, 3 Apr 2012 23:40:32 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3788621F8621 for ; Tue, 3 Apr 2012 23:40:32 -0700 (PDT) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q346dZG3007183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Apr 2012 02:39:36 -0400 Message-ID: <4F7BECDE.3010505@gathman.org> Date: Wed, 04 Apr 2012 02:40:30 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120316221227.14457.qmail@joyce.lan> In-Reply-To: <20120316221227.14457.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 06:40:32 -0000 Long ago, Nostradamus foresaw that on 03/16/2012 06:12 PM, John Levine would write: >> Forwarding is already a small niche. > Forwarding is a small niche, but people collecting and sending mail at sites separate > from their home domain (typically doing so at Gmail or Yahoo) is a growing niche. > It has all the same issues as forwarding, it's not going away, SPF does what it does. > If people want to send MAIL FROM their home domain at gmail and use SPF, then they need to authorize gmail to do so in their SPF record. This should be obvious. It does indeed have all the same issues as forwarding: none that are due to the SPF protocol. From vesely@tana.it Wed Apr 4 08:23: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 A4C2921F87E0 for ; Wed, 4 Apr 2012 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.459 X-Spam-Level: X-Spam-Status: No, score=-4.459 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmZPVKYj9cbm for ; Wed, 4 Apr 2012 08:23:01 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9B64A21F879B for ; Wed, 4 Apr 2012 08:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333552979; bh=RJVYo1qf+v6aQYrC/vVXNEmvV3CQ8RivS66zMip/KCE=; l=2899; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OM2Kjq2348N2KIwI1iBfecOG7/LHH/4u7to7JetsVlPX209f29vUWyOleGSOfhrzu 6BXaFv+I24k/A7Pyh+03eM0kp/RN1n7s+r4qFOW3yTjrjtlr3gOihur2EzcK9tZMtD 45rRmpnAvrmgrqN3ARre/FivXhRsKiwgbeK/WKQk= 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, 04 Apr 2012 17:22:59 +0200 id 00000000005DC039.000000004F7C6753.000055D0 Message-ID: <4F7C6753.8060202@tana.it> Date: Wed, 04 Apr 2012 17:22:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> In-Reply-To: <4F7BEA22.9050908@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 15:23:02 -0000 On 04/Apr/12 08:28 +0200, Stuart Gathman wrote: > that on 03/25/2012 06:14 AM, Alessandro Vesely would write: >> Until we hold that reject-on-fail is valid, SPF is less optional than >> it would seem at a first glance, because it affects a mail operation >> that used to be possible without it. A sender who does not opt for SPF >> can have its forwarded messages bounced because both the originator >> and the target opted to implement SPF in such a way to break that >> operation. In this respect, SPF has changed SMTP already, whether >> we're gonna document that as an update or not. What's worse is that >> there's no guidance on how to avoid such incidents. A protocol worth >> its salt should allow to determine what parties are at fault in case >> of malfunction. > > If by "sender" you mean an alias forwarder, then there are three cases: > > a) the alias forwarding was requested/authorized by the target. In this > case, the target screwed up by trying to apply SPF to the forwarder, who > has now become a "border MTA" of the target in the language of rfc4408. > > b) the alias forwarding was requested/authorized by the sender. In this > case, the sender screwed up by failing to include the forwarder (who has > now become a "border MTA" for the sender) in their Sender Policy. Cases (a) and (b) are not a problem. They imply cooperation between the relevant domains. They are a small niche. > c) the alias forwarding was *not* authorized by the sender or target. > In this case, the "forwarder" is a forger and SHOULD be rejected. False, this case includes legitimate forwarders. People who work in an organization may sport an email address that reflects their affiliation. Email facilities at that organization's site may include the ability to set a forward address. Users may choose a different mail site for its interface, its filtering, or whatever other reason. It is not uncommon to have users forwarding to gmail, and from there to yahoo, and possibly more. At policy-making time, an organization may opt for not changing the bounce address on forwarding. Since that's what the standard says, they may consider it good behavior to do it that way. Indeed, it can result in due NDNs in some cases. Asking authorizations for each forward address is not practical. > In brief, an alias forwarder is either an agent of the sender - and > therefore a border MTA of the sender, or an agent of the target - and > therefore a border MTA of the target, or illegitimate. > > There is no forwarding problem. Only broken SPF records with sender > authorized alias forwarders, or broken implementations for receiver > authorized alias forwarders. Why don't you try and define a proper TXT RR at _dmarc.gathman.org and see what you get? Discussing possible solutions may be more productive than negating that the problem exists. From SRS0=PO3NJ=CK==stuart@gathman.org Wed Apr 4 12:26: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 32D7111E80C4 for ; Wed, 4 Apr 2012 12:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYlPgxmGT64S for ; Wed, 4 Apr 2012 12:26:15 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E90C11E8099 for ; Wed, 4 Apr 2012 12:26:15 -0700 (PDT) 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 q34JPFBQ020790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Apr 2012 15:25:16 -0400 Message-ID: <4F7CA052.3090006@gathman.org> Date: Wed, 04 Apr 2012 15:26:10 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120316 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> In-Reply-To: <4F7C6753.8060202@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Apr 2012 19:26:16 -0000 Long ago, Nostradamus foresaw that on 04/04/2012 11:22 AM, Alessandro Vesely would write: > > c) the alias forwarding was *not* authorized by the sender or target. > In this case, the "forwarder" is a forger and SHOULD be rejected. > False, this case includes legitimate forwarders. People who work in > an organization may sport an email address that reflects their > affiliation. Email facilities at that organization's site may include > the ability to set a forward address. Users may choose a different > mail site for its interface, its filtering, or whatever other reason. > It is not uncommon to have users forwarding to gmail, and from there > to yahoo, and possibly more. > The situations you just described are *authorized* forwarding, so it is case b. I repeat, unauthorized forwarding is forgery and should be rejected. *If* a recipient wants to check SPF, then their implementation must take into account authorized forwarders as described in rfc4408 section 9, esp 9.5. A recipient authorized forwarder is a "border MTA" of the recipient. From msk@cloudmark.com Wed Apr 4 12:26: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 9912811E80CC for ; Wed, 4 Apr 2012 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWcVwNrddObL for ; Wed, 4 Apr 2012 12:26:56 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83711E80C4 for ; Wed, 4 Apr 2012 12:26:56 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 4 Apr 2012 12:26:55 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: New Version Notification - draft-kucherawy-spfbis-experiment-04.txt Thread-Index: AQHNEpgsd998bnc94UO2d3MVO9de7ZaLCz1g Date: Wed, 4 Apr 2012 19:26:54 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C9A7B@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [spfbis] FW: New Version Notification - draft-kucherawy-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 19:26:56 -0000 VGhpcyB2ZXJzaW9uIGlzIHNpZ25pZmljYW50IGJlY2F1c2UgaXQgaW5jbHVkZXMgYSBmaXJzdCBy dW4gYXQgdGhlIGNvbmNsdXNpb25zIHNlY3Rpb24sIGFuZCB0aGUgc3VydmV5IGRhdGEgcHJlc2Vu dGVkIGFyZSBtb3JlIGNvbXBsZXRlLg0KDQpOb3RlIHRoYXQgdGhlIGNvbmNsdXNpb25zIGFyZSBP TkxZIGFuIGluaXRpYWwgcHJvcG9zYWwuICBJIGRvbid0IGNsYWltIHRoZXkgaGF2ZSB3b3JraW5n IGdyb3VwIGNvbnNlbnN1cyBhdCB0aGlzIHBvaW50OyBpdCdzIGp1c3QgYSBzdGFydGluZyBwb2lu dCBmb3IgZGlzY3Vzc2lvbi4gIFdlIGFyZSBzdGlsbCB3YWl0aW5nIGZvciB0aGUgSG90bWFpbCBk YXRhIHRvIGNvbWUgaW4sIHBsdXMgYW55IG90aGVyIGRhdGEgcGVvcGxlIG1pZ2h0IHdhbnQgdG8g c3VibWl0IGJlZm9yZSB3ZSBmaW5hbGl6ZSB0aGUgZG9jdW1lbnQuDQoNCkhvd2V2ZXIsIGlmIHlv dSBoYXZlIGFueSBjaGFuZ2VzIHlvdSB3YW50IHRvIHNlZSB0byB0aGUgY29uY2x1c2lvbnMsIEkg c3VnZ2VzdCBpdCB3aWxsIGJlIGltcG9ydGFudCB0byBqdXN0aWZ5IHlvdXIgc3RhdGVtZW50cyBh Z2FpbnN0IHRoZSBkYXRhIHdlIGhhdmUsIG9yIHByb3ZpZGUgbmV3IGRhdGEuICBPcGluaW9ucyBh bmQgdGhlb3JpZXMgYXJlIGxlc3MgdXNlZnVsIHRoYW4gZmFjdHMgaGVyZSwgc2luY2Ugd2UncmUg YmFzaW5nIGFsbCBvZiB0aGlzIG9uIG9ic2VydmF0aW9uIGFuZCBub3Qgb24gc3BlY3VsYXRpb24u DQoNCldpdGggdGhhdCBzYWlkLCBoYXZlIGF0IGl0IQ0KDQotTVNLDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNCwgMjAxMiAx MjoyMiBQTQ0KVG86IE11cnJheSBTLiBLdWNoZXJhd3k7IGRyYWZ0LWt1Y2hlcmF3eS1zcGZiaXMt ZXhwZXJpbWVudEB0b29scy5pZXRmLm9yZzsgcHJlc25pY2tAcXVhbGNvbW0uY29tDQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1rdWNoZXJhd3ktc3BmYmlzLWV4cGVy aW1lbnQtMDQudHh0DQoNCk5ldyB2ZXJzaW9uICgtMDQpIGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3Ig ZHJhZnQta3VjaGVyYXd5LXNwZmJpcy1leHBlcmltZW50LTA0LnR4dDoNCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWt1Y2hlcmF3eS1zcGZiaXMtZXhwZXJpbWVudC0w NC50eHQNCg0KRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb246DQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWt1Y2hlcmF3eS1zcGZiaXMtZXhwZXJpbWVudC0wNA0KDQpJ RVRGIFNlY3JldGFyaWF0Lg0KDQo= From msk@cloudmark.com Wed Apr 4 12:54: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 17CDF11E80D2 for ; Wed, 4 Apr 2012 12:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZpR0pD9quti for ; Wed, 4 Apr 2012 12:53:59 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9E52A11E8099 for ; Wed, 4 Apr 2012 12:53:59 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 4 Apr 2012 12:53:59 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] FW: New Version Notification - draft-kucherawy-spfbis-experiment-04.txt Thread-Index: AQHNEpgsd998bnc94UO2d3MVO9de7ZaLCz1ggAB+Q2A= Date: Wed, 4 Apr 2012 19:53:58 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C9B68@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C9A7B@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C9A7B@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: New Version Notification - draft-kucherawy-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 19:54:00 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Wednesday, April 04, 2012 12:27 PM > To: spfbis@ietf.org > Subject: [spfbis] FW: New Version Notification - draft-kucherawy- spfbis-= experiment-04.txt >=20 > This version is significant because it includes a first run at the > conclusions section, and the survey data presented are more complete. I should also add that there's an appendix now that talks about the type 99= experience. I think this is important given all the chatter elsewhere in = the IETF lately about developing protocols that use the DNS to store stuff.= If I got any of the history in there wrong, please do feel free to provid= e alternate text that sets the story straight. -MSK From hsantos@isdg.net Wed Apr 4 17:04: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 24AC411E8135 for ; Wed, 4 Apr 2012 17:04:22 -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.127, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+CqLsiol52I for ; Wed, 4 Apr 2012 17:04:21 -0700 (PDT) Received: from mail.santronics.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE66D11E80FE for ; Wed, 4 Apr 2012 17:04:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4246; t=1333584254; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=G9F3RDZSFuvRktC1dWjlWJvr7vI=; b=ThhsCGNa7DFTFyaq4X9P ItYdK0+K97sqfu8A46Ovxt8ZMINgqq1Esg3GrRX2qpU3dAfiHIpZeyeLc7mpamOF bhkfdPbRT0uwgp+pIVxtp4oqYkbBirDdeY3Dph9t3wrPpKPvZHRouZZUEoXui3DN BK0VS5tDvGmIBPFhYFjtSD8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 04 Apr 2012 20:04:14 -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 v6.4.454.1) with ESMTP id 2491090348.16391.3352; Wed, 04 Apr 2012 20:04:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4246; t=1333583947; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=iyzhn9n nkQcpzYrKeNTlMRtRgLbobrCsGjWOjvKbmG4=; b=jJNdgTtYwLS26KanY0pccTb rgcGgrKxt3pJ7irM8zOX3NxosmAScZuRAnTV3zJOn3238XoeZTdFPUgW82kmOubL TE95k6PTrD9VAHcFl2M1OZ7SAhe1OEY98ChvoTy8x12pd0pD9Pz8d4Wcc7kJyWnE CrPR8uhXqHejnJ5xD/yQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 04 Apr 2012 19:59:07 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3090003362.37946.1568; Wed, 04 Apr 2012 19:59:07 -0400 Message-ID: <4F7CE181.5060706@isdg.net> Date: Wed, 04 Apr 2012 20:04:17 -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: <9452079D1A51524AA5749AD23E0039280C9A7B@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C9A7B@exch-mbx901.corp.cloudmark.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: [spfbis] Recommendation #4 - Obsolete SIDF/SUBM/PRA - may be premature X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Apr 2012 00:04:22 -0000 Hi, With a quick review, I believe the recommendation #4 regarding SIDF/SUBMITTER/PRA is premature. This is a clear case of a HMM (Hidden Markov Model) [1] where an analysis is done with one outcome can have a completely different take just by enabling an server option. IMTO, the key questions to be investigated: Why is there a significant amount of clients using SUBMITTER once the server enabled the option? If recommendation #4 is conclusive, is there an new error based in the reflection the server deems as appropriate for SPF verification, and it would open a window of possible non-protected transactions by clients using the PRA? It is very easy to look at various servers "directly" and conclude there are enough ESMTP servers enabling SUBMITTER extension, but then again this form of analysis can apply to many SMTP extensions we have deemed as worthy standards yet are not very popular at the server level across the board. On the flip side, even where there are significant server support for one or more many extensions, it doesn't mean clients need to support it. Would that suggest the protocol should be made obsolete due to lack of client support? Of course not, and if that was the modus operandi for support, quite a few ESMTP protocols would fail to exist today. So in my view, the SPFBIS experiment report needs to look at reasons why there are clients who have obviously took the coding time and expense to programmatically extract the PRA, programmatically modify their ESMTP client to look for the ESMTP service SUBMITTER keyword and then programmatically add SUBMITTER= to the 5321.MAIL FROM command. All of which does not suggest an easy and no cost endeavor. It took "Engineering Thinking" to go about this SUBMITTER consideration by the clients. At best, the recommendation made is that SERVERS are not supporting it, but can't match with what appears to be a high client technical desire to support it. When we look at servers, such as Microsoft Exchange, having ESMTP support for SUBMITTER may be an provisional or 3rd party vendor support [2][3][4] implementation. Overall, IMO, until questions such as the above are addressed, recommendation #4 is premature and its certainly one resembling a Hidden Markov Model. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com [1] http://en.wikipedia.org/wiki/Hidden_Markov_model [2] http://www.bluej.org/extensions/submitter/submitter.html [3] http://www.equisys.com/technotes/ztn1418.htm [4] http://stackoverflow.com/questions/5639836/problem-sending-mail-with-javamail Murray S. Kucherawy wrote: > This version is significant because it includes a first run at the conclusions section, and the survey data presented are more complete. > > Note that the conclusions are ONLY an initial proposal. I don't claim they have working group consensus at this point; it's just a starting point for discussion. We are still waiting for the Hotmail data to come in, plus any other data people might want to submit before we finalize the document. > > However, if you have any changes you want to see to the conclusions, I suggest it will be important to justify your statements against the data we have, or provide new data. Opinions and theories are less useful than facts here, since we're basing all of this on observation and not on speculation. > > With that said, have at it! > > -MSK > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, April 04, 2012 12:22 PM > To: Murray S. Kucherawy; draft-kucherawy-spfbis-experiment@tools.ietf.org; presnick@qualcomm.com > Subject: New Version Notification - draft-kucherawy-spfbis-experiment-04.txt > > New version (-04) has been submitted for draft-kucherawy-spfbis-experiment-04.txt: > http://www.ietf.org/internet-drafts/draft-kucherawy-spfbis-experiment-04.txt > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-kucherawy-spfbis-experiment-04 > > IETF Secretariat. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From vesely@tana.it Thu Apr 5 10:51: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 0DCA221F8723 for ; Thu, 5 Apr 2012 10:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.147 X-Spam-Level: X-Spam-Status: No, score=-4.147 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZnmGzJemQM7 for ; Thu, 5 Apr 2012 10:50:55 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEB321F8722 for ; Thu, 5 Apr 2012 10:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333648253; bh=hGwHzWzTTEbHCuGKPaRN5O/EfgCwAXhBZ541bIx8JAk=; l=2267; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aieErmQ5gcwWjE4ffnu4lPcAZ6m6ndLPV5nMrmAkd04IOPPmLYzn4iVqSOID3fDT3 26ifVfLKf+Nk66GUkUfSJXeH5ojSg3v5x1rgyYmWlCkAH6DVCgXLSi0uG/Ycn/rwZk ZwOh1Tcq0uYhipXnKge557gcRUgz8hfFku2sTs1s= 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; Thu, 05 Apr 2012 19:50:53 +0200 id 00000000005DC044.000000004F7DDB7D.00004DE3 Message-ID: <4F7DDB7C.9080605@tana.it> Date: Thu, 05 Apr 2012 19:50:52 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> In-Reply-To: <4F7CA052.3090006@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Apr 2012 17:51:01 -0000 On Thu 05/Apr/2012 19:26:19 +0200 Stuart D Gathman wrote: > that on 04/04/2012 11:22 AM, Alessandro Vesely would write: >> >>> c) the alias forwarding was *not* authorized by the sender or target. >>> In this case, the "forwarder" is a forger and SHOULD be rejected. >> >> False, this case includes legitimate forwarders. People who work in >> an organization may sport an email address that reflects their >> affiliation. Email facilities at that organization's site may include >> the ability to set a forward address. Users may choose a different >> mail site for its interface, its filtering, or whatever other reason. >> It is not uncommon to have users forwarding to gmail, and from there >> to yahoo, and possibly more. > > The situations you just described are *authorized* forwarding, so it > is case b. I don't see how. You described case (b) as: b) the alias forwarding was requested/authorized by the sender. In this case, the sender screwed up by failing to include the forwarder (who has now become a "border MTA" for the sender) in their Sender Policy. I was talking about generic dot-forward files, whereby they forward any message, irrespectively of the sender, to whatever external addresses the users configured their forwarding recipe with. > I repeat, unauthorized forwarding is forgery and should be rejected. They configure forwarding recipes through web forms. Nobody is going to ask and obtain authorizations, and have SPF records updated. > *If* a recipient wants to check SPF, then their implementation must > take into account authorized forwarders as described in rfc4408 > section 9, esp 9.5. A recipient authorized forwarder is a "border > MTA" of the recipient. Keeping in mind that relaying should be authorized on a per-user basis, the only way to do that consistently, AFAICS, would be that each organization maintains a user+forward whitelist of granted authorizations. Records in such whitelists are inserted after a trusted request of forwarding, presumably performed by web2 means in the server part of the web form that users configure forwarding with. Then, the whitelists are referred from SPF records, using local macros as appropriate. That is SMTP-fictional, IMHO. From hsantos@isdg.net Thu Apr 5 12:06: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 9D98621F86B6 for ; Thu, 5 Apr 2012 12:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-1.341, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3esdPoCMbeor for ; Thu, 5 Apr 2012 12:06:08 -0700 (PDT) Received: from listserv.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 74D5721F86B5 for ; Thu, 5 Apr 2012 12:06:08 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4639; t=1333652765; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=e4TLr9svFoA0ut1tEvtkTV0WJMI=; b=ffWy7Hwtqf3mtWxCwFag sqQBvYanWAshHGX+Vw4kW56IrbseDDru7jI85QNX5V2uR8MSGzAc3dRUSg9hFAT1 kHbgYank5Ljf/q+4GL/9VBHwvpfj+vCJo3w9LE+FXzBRUDnV4x2zhJ8FYpEWLABD bW9Atz/fCkKsoJqjwBLxB6c= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 05 Apr 2012 15:06:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2559601026.17290.2512; Thu, 05 Apr 2012 15:06:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4639; t=1333652456; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=o2s73oC WkXUetdIdNHSXs3vfs5xjv7Wo2RYbXoVI3Dc=; b=kEiFtfuHdG27MAKAAXKxMAo BcB1KJFnq80mPKW250vzjuAXgQSa0JUgl11/aMEFunMuYG6V8HhRLnzDPpeDxZkK e2xxkPickAYN3MabNPuuULRKWnYryRuW98nWhb0ulhlsVELV/XpsBv5wu10nHhEf teSDJamPruRWwxwqjdlc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 05 Apr 2012 15:00:56 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3158512190.38053.3380; Thu, 05 Apr 2012 15:00:56 -0400 Message-ID: <4F7DED0A.6040809@isdg.net> Date: Thu, 05 Apr 2012 15:05:46 -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: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> In-Reply-To: <4F7DDB7C.9080605@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Apr 2012 19:06:09 -0000 Hi, In my view, there are 3-4 SPFBIS clarifications that should be made: 1) Clarification of when SPF verification starts and ends, 1.1) For Client Machine Domain :: IP checks 1.2) For Return Path Domain :: IP checks 2) Clarification of the compliant SPF client expectation to conform to the RFC5321 validity of a EHLO/HELO client domain name (CDN), 3) Clarification of when EHLO/HELO client domain name and Return Path Domain SPF verification together or separately applies, or even delayed until the Forwarding Address is known or deemed valid, and 4) Clarification on how much a domain needs to protect its domain at the client machine level and/or return path level, which can have a direct and indirect affect on #1, #2 and #3. I believe you are proposing #2 and #4 in issue #12 and it appears Stuart is referring to #1 By design, SPF is a single hop, direct to MDA protocol where the sender connecting IP is associated with the public client machine name or domain literal and/or the persistent SMTP return path domain. IMV, anything going beyond this with sender forwarding methods and changing the return path domain is beyond the scope of SPF, or rather what SPF Domain can not expect to occur. The protection is only for first hop. One of the main concerns I always had with SPF is its high waste DNS factor and a prudent implementation SHOULD look at the entire scope of SMTP process parameters for its check_host() function: CIP - client connection IP CDN - client domain name (EHLO/HELO) RPD - sender return path (MAIL FROM) FPA - forwarding path address (RCPT TO) SPFBIS should refer to RFC5321 section 3.3 which provides validation and optimization recommendations: 3.3 Mail Transactions ..... Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. For systems under a typical anonymous attack of spammers and spoofers, a high failure rate of RCPT TO unknowns provide a short-circuiting of SPF DNS waste for the client domain and/or return path domain. For nearly 9 years, we have see a near consistent 60% RCPT TO failure, thus this would correspond to a 60% reduction in SPF DNS overhead. So while its important to recommend SMTP client to conform to RFC5321 valid client domain names and possibly protect the public client domain with SPF, there will be an higher DNS waste with the SPF receiver performing this action. So it SHOULD have some SPFBIS empirical learned intelligence in the validity of all the SMTP transaction parameters before performing SPF checking. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com Alessandro Vesely wrote: >> The situations you just described are *authorized* forwarding, so it >> is case b. > > I don't see how. You described case (b) as: > > b) the alias forwarding was requested/authorized by the sender. > In this case, the sender screwed up by failing to include the > forwarder (who has now become a "border MTA" for the sender) in > their Sender Policy. > > I was talking about generic dot-forward files, whereby they forward > any message, irrespectively of the sender, to whatever external > addresses the users configured their forwarding recipe with. > >> I repeat, unauthorized forwarding is forgery and should be rejected. > > They configure forwarding recipes through web forms. Nobody is going > to ask and obtain authorizations, and have SPF records updated. > >> *If* a recipient wants to check SPF, then their implementation must >> take into account authorized forwarders as described in rfc4408 >> section 9, esp 9.5. A recipient authorized forwarder is a "border >> MTA" of the recipient. > > Keeping in mind that relaying should be authorized on a per-user > basis, the only way to do that consistently, AFAICS, would be that > each organization maintains a user+forward whitelist of granted > authorizations. Records in such whitelists are inserted after a > trusted request of forwarding, presumably performed by web2 means in > the server part of the web form that users configure forwarding with. > Then, the whitelists are referred from SPF records, using local macros > as appropriate. That is SMTP-fictional, IMHO. From vesely@tana.it Fri Apr 6 06:11: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 D4D9421F85E7 for ; Fri, 6 Apr 2012 06:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.49 X-Spam-Level: X-Spam-Status: No, score=-4.49 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGKBvcvqIwgE for ; Fri, 6 Apr 2012 06:11:01 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC1521F85D0 for ; Fri, 6 Apr 2012 06:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333717860; bh=rhtOVIqWCLuSDUsk+kJHDQu5MYEEfyVdVN7auBPzoBk=; l=1786; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Q6ORnSh9lF54nmg9xbvzaK4x/R30IBE0l1IereLJxQiRmMh7/U9C5otcyg5CXfvgI Sh7x95/dF7UNXo17gfuy/MlJPUZjhnWJY5VxwfMEa+N1DrJdFp8eACIqpX4iFR2ca6 o910KLSmghKCY+iS5QeqokA8NiEa18gPcVnYFJwo= 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, 06 Apr 2012 15:11:00 +0200 id 00000000005DC035.000000004F7EEB64.0000633F Message-ID: <4F7EEB63.3050908@tana.it> Date: Fri, 06 Apr 2012 15:10:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F7DED0A.6040809@isdg.net> In-Reply-To: <4F7DED0A.6040809@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 13:11:02 -0000 On Fri 06/Apr/2012 11:29:10 +0200 Hector Santos wrote: > > In my view, there are 3-4 SPFBIS clarifications that should be made: > > 1) Clarification of when SPF verification starts and ends, > > 1.1) For Client Machine Domain :: IP checks > 1.2) For Return Path Domain :: IP checks > > 2) Clarification of the compliant SPF client expectation to conform > to the RFC5321 validity of a EHLO/HELO client domain name (CDN), > > 3) Clarification of when EHLO/HELO client domain name and Return Path > Domain SPF verification together or separately applies, or even > delayed until the Forwarding Address is known or deemed valid, and > > 4) Clarification on how much a domain needs to protect its domain > at the client machine level and/or return path level, which can > have a direct and indirect affect on #1, #2 and #3. > > I believe you are proposing #2 and #4 in issue #12 and it appears > Stuart is referring to #1 It may well be so. Let me clarify by example: Google doesn't check the helo identity, so a type (c) forward to gmail would get an SPF fail. That is good, as long as gmail does not reject on fail. RFC 4408 says, in 2.4. Checking Authorization: At least the "MAIL FROM" identity MUST be checked, but it is RECOMMENDED that the "HELO" identity also be checked beforehand. And then, in 2.5.4. Fail, it substantially says that reject-on-fail gets triggered in such case. (BTW, let me note once more that the need to pretend not to mandate receiver's behavior forces an unclear language in this an similar RFCs. See next message.) The error correction that I'm proposing with issue #12 substantially is that the helo identity must be checked by those who do reject-on- fail, and if it is a "pass" the receiver must not reject. From spf2@kitterman.com Fri Apr 6 06:31: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 6233921F84CE for ; Fri, 6 Apr 2012 06:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU6puXraWnYu for ; Fri, 6 Apr 2012 06:31:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 26FAB21F8499 for ; Fri, 6 Apr 2012 06:31:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DA3CB20E410E; Fri, 6 Apr 2012 09:31:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1333719085; bh=7t20e0gVc5OE4xHajIJM3xqYVT8op3hnhy8rfBrd8e8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=J6/BnH/vuHPkHlTfKaOD5aXLZUD5S+7GmGa2TIqdzIV/iJeMATSd0CCZUO/uZ47+R R3184tuX62R6FGwWnDLYFl/mahp6cg0K+0jCLAsMSv/BnMHTV9tRwcTDQSKT63V6Fl FZ8y4aVh4Th9gmgqwQhsK59Kd2CDI25Zo2im5X1M= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B226820E4083; Fri, 6 Apr 2012 09:31:25 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 06 Apr 2012 09:31:24 -0400 Message-ID: <1832269.tsjzSkJokG@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-17-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F7EEB63.3050908@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <4F7DED0A.6040809@isdg.net> <4F7EEB63.3050908@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 13:31:32 -0000 On Friday, April 06, 2012 03:10:59 PM Alessandro Vesely wrote: > On Fri 06/Apr/2012 11:29:10 +0200 Hector Santos wrote: > > In my view, there are 3-4 SPFBIS clarifications that should be made: > > 1) Clarification of when SPF verification starts and ends, > > > > 1.1) For Client Machine Domain :: IP checks > > 1.2) For Return Path Domain :: IP checks > > > > 2) Clarification of the compliant SPF client expectation to conform > > > > to the RFC5321 validity of a EHLO/HELO client domain name (CDN), > > > > 3) Clarification of when EHLO/HELO client domain name and Return Path > > > > Domain SPF verification together or separately applies, or even > > delayed until the Forwarding Address is known or deemed valid, > > and > > > > 4) Clarification on how much a domain needs to protect its domain > > > > at the client machine level and/or return path level, which can > > have a direct and indirect affect on #1, #2 and #3. > > > > I believe you are proposing #2 and #4 in issue #12 and it appears > > Stuart is referring to #1 > > It may well be so. Let me clarify by example: Google doesn't check > the helo identity, so a type (c) forward to gmail would get an SPF > fail. That is good, as long as gmail does not reject on fail. > > RFC 4408 says, in 2.4. Checking Authorization: > > At least the "MAIL FROM" identity MUST be checked, but it > is RECOMMENDED that the "HELO" identity also be checked beforehand. > > And then, in 2.5.4. Fail, it substantially says that reject-on-fail > gets triggered in such case. (BTW, let me note once more that the > need to pretend not to mandate receiver's behavior forces an unclear > language in this an similar RFCs. See next message.) > > The error correction that I'm proposing with issue #12 substantially > is that the helo identity must be checked by those who do reject-on- > fail, and if it is a "pass" the receiver must not reject. This makes the mail from check meaningless as it's trivial to arrange for a random HELO name to pass SPF checks. HELO pass overriding SPF Fail is only logical if the HELO name is known to you as a 'safe' host. This is usable as a white listing technique, not a general purpose solution to dealing with the intersection of SPF and forwarding. Scott K From vesely@tana.it Fri Apr 6 07:11: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 CF0AC21F858F for ; Fri, 6 Apr 2012 07:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.507 X-Spam-Level: X-Spam-Status: No, score=-4.507 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT+-7gc1Q3Hs for ; Fri, 6 Apr 2012 07:11:00 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0BA21F858E for ; Fri, 6 Apr 2012 07:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333721459; bh=mN4bK7UxKchJLvbQTq+56IpbPjuZbIqn24UIj2tL3P4=; l=884; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=UhMYu3rNMIHoKKyJUT1KyMMofF/qKh42Jqx1VhDsADgtnqYexrWsAjp2EhWGTimI0 0PXDjFzqoVD/fmV3jpCbGwOvohV9ZjbysfiXI6b12CXBi+WIlKprqumerX140GHezI Ovwyu84QqU5JOlCRsZHTNB9OAN1TyhmQfMVJiSmo= 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, 06 Apr 2012 16:10:58 +0200 id 00000000005DC03F.000000004F7EF972.0000711F Message-ID: <4F7EF972.7030404@tana.it> Date: Fri, 06 Apr 2012 16:10:58 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] New issue? A language complementary to RFC 2119 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 14:11:00 -0000 SPF did a number of pioneering endeavors, so maybe this one deserves being here as well. OTOH, it is quite overstretching to include this issue in the charter, so maybe it should be aired somewhere else. RFC 2119 defines imperatives that are required for interoperability. A message delivery is typically not interpreted in such way, so we cannot write "Receivers MUST reject if the result is Fail". As a consequence, we are forced to use circumlocutory language that is often not clear enough. Should we define some imperatives that express the actions that a receiver is expected to take according of the meaning of protocol tokens such as "-all"? If we do, then we'll be able to confer a precise technical meaning to sentences like, e.g., "Receivers NEED reject if the result is Fail, CAN reject on PermError, and DARE reject on TempError". Uh? Just wondering From spf2@kitterman.com Fri Apr 6 07:24: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 159AB21F855D for ; Fri, 6 Apr 2012 07:24: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oznaxTFIBhqz for ; Fri, 6 Apr 2012 07:24:16 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC3B21F84EC for ; Fri, 6 Apr 2012 07:24:16 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E9E8020E410E; Fri, 6 Apr 2012 10:24:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1333722256; bh=OHuC/86dVYg6gPwRwMXfZe3kaD4pnCNK6UCziOOLvYo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Hvjl3kHlmSFL/fR/CYkSLK9ophbKRuWJk3cmaFKBraPrcCS/2aoRPn6v57kx5JXgC RQuOrCfCm/nJddOe7FGJB+qJOmmVY9uVQuW5aG/okehXGQbCLQX5UcODql3vUQmpg4 mOwV7qHX7t87huJS30wnJUHgMDFyV1lHPPUDB8bA= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BD10A20E4083; Fri, 6 Apr 2012 10:24:15 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 06 Apr 2012 10:24:14 -0400 Message-ID: <17101754.tyCITvEt1y@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-17-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F7EF972.7030404@tana.it> References: <4F7EF972.7030404@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? A language complementary to RFC 2119 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 14:24:17 -0000 On Friday, April 06, 2012 04:10:58 PM Alessandro Vesely wrote: > SPF did a number of pioneering endeavors, so maybe this one deserves > being here as well. OTOH, it is quite overstretching to include this > issue in the charter, so maybe it should be aired somewhere else. > > RFC 2119 defines imperatives that are required for interoperability. > A message delivery is typically not interpreted in such way, so we > cannot write "Receivers MUST reject if the result is Fail". As a > consequence, we are forced to use circumlocutory language that is > often not clear enough. > > Should we define some imperatives that express the actions that a > receiver is expected to take according of the meaning of protocol > tokens such as "-all"? If we do, then we'll be able to confer a > precise technical meaning to sentences like, e.g., "Receivers NEED > reject if the result is Fail, CAN reject on PermError, and DARE reject > on TempError". Uh? > > Just wondering No. Scott K From johnl@iecc.com Fri Apr 6 07:49: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 85C7321F8501 for ; Fri, 6 Apr 2012 07:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+Hy+PxS7uI7 for ; Fri, 6 Apr 2012 07:49:32 -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 8B22921F84FE for ; Fri, 6 Apr 2012 07:49:32 -0700 (PDT) Received: (qmail 24564 invoked from network); 6 Apr 2012 14:49:30 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Apr 2012 14:49:30 -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=4f7f027a.xn--30v786c.k1204; i=johnl@user.iecc.com; bh=KPGGrgpoOX1M1YIUkttgnZf2AZWEOVAiC4yepDSmLUM=; b=AySxI9KiLgVa+WiEtizlLGxEG0bpsWOospquORQwIBcExt7NOWNHMtwDfe3JRCThPMQIbCn5690K057tu3tyri0wt+MsYShjwBDftuQqUvnaSZ528dc8CuyNUatb/3yYgErj0LgL8RNFy0UHN4+EcuBjO04T/dG86zBERtzY24A= 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=4f7f027a.xn--30v786c.k1204; olt=johnl@user.iecc.com; bh=KPGGrgpoOX1M1YIUkttgnZf2AZWEOVAiC4yepDSmLUM=; b=MedFFGFYxPCltsdOZGNnWSKXwXqs3/bSL/52Y6g94R8cnh3L0JwXMmR9vY8fr1cWhtC5gfRfawZJ7jBg2ru6eQu1WZy11QcZgZ3KxptqiWuFUVd9bKBXSi+ghT/z58z6SODNUPaegOQ5DZX5QnyjM+JXtHr+oFVE3CxAcLbn0Ok= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Apr 2012 14:49:07 -0000 Message-ID: <20120406144907.53201.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <17101754.tyCITvEt1y@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] New issue? A language complementary to RFC 2119 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 14:49:33 -0000 >> Just wondering > >No. +1 on that No. R's, John From hsantos@isdg.net Fri Apr 6 08:24: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 D72C321F8525 for ; Fri, 6 Apr 2012 08:24:24 -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.544, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JspMwaDfZc1x for ; Fri, 6 Apr 2012 08:24:23 -0700 (PDT) Received: from dkim.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 75B6421F855F for ; Fri, 6 Apr 2012 08:24:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3457; t=1333725852; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xIufZ35Xk9/rH3TsCtuyv3rwtRs=; b=pNZPOPBAlCVcIZbdkzS1 oWG+assi/7v5C1xPnwlimn+CZN9ecH7WwTO6k9eJ6Gdva1nmK97r827GXKOHnkwW lJOTsIkShygMsVlvi8ECBFaRLjoTa4aJoEdd/4A4N5vnOtBM0frre+ldof6lU5co 4w1iQ6zVXTNgO68b0sTXNlU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 11:24: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 v6.4.454.1) with ESMTP id 2632686964.18315.4028; Fri, 06 Apr 2012 11:24:12 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3457; t=1333725541; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=T/1pQPR tcwmvBDvGK4AoSEa0ykf4GkhzYscXPaVJsDA=; b=opWXYDEdAJmtPuK7KHzaHc0 OIef8pQDa4ksHEV8s7QqAy9tw4vH16hYpaZGn/GXifxVAx9ge6IR5EEr2bkV87WT SR2uCuKXraQVZvIvXck1N5OkXzgEfr4k/m7QnI4lU2rgUDQsPxD20fNMLEdVIxl+ RSTyIqy9Fdn0IIHQ5F3c= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 11:19:01 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3231596799.38555.5336; Fri, 06 Apr 2012 11:19:00 -0400 Message-ID: <4F7F0AA5.8010301@isdg.net> Date: Fri, 06 Apr 2012 11:24:21 -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: <9452079D1A51524AA5749AD23E0039280C9A7B@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C9A7B@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] More than two MTA use SUBMITTER X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 15:24:24 -0000 Murray S. Kucherawy wrote: > This version is significant because it includes a first run at the conclusions section, and the survey data presented are more complete. > > Note that the conclusions are ONLY an initial proposal. I don't claim they have working group consensus at this point; it's just a starting point for discussion. We are still waiting for the Hotmail data to come in, plus any other data people might want to submit before we finalize the document. > > However, if you have any changes you want to see to the conclusions, I suggest it will be important to justify your statements against the data we have, or provide new data. Opinions and theories are less useful than facts here, since we're basing all of this on observation and not on speculation. > > With that said, have at it! Hi, I have more data and two comments regarding this section 3 paragraph: In a survey of numerous MTAs in current or recent use, only two (Santronics WinServer and McAfee MxLogic) were found to contain implementations of the SMTP SUBMITTER extension as part of the MTA service, which could act as an enabler to Sender-ID. An unknown number of clients implement it; although there is substantial activity showing its use in logs, it is unclear whether these are separate implementations by legitimate senders, or merely instances of distributed automated malware seeking to improve their odds of reaching the end user. First, in regards to the last sentence, IMO, I don't think this report should be dealing with unproven subjective quality of message or legitimate usage considerations and use this basis for experiment conclusions. Yes, there are brownie points, but that applies to ALL anonymous email senders - good or bad because we (IETF by developing these protocols) told them to support it since it will benefit everyone else to get on board. The DMA even recommends a BCP for compliant eMarketing Mail Delivery Practices. More importantly, clients using SUBMITTER is not a zero-cost implementation. Code changes are required to detect the ESMTP SUBMITTER service keyword, code changes are needed to parse the RFC5322 to extract the PRA and code changes are necessary to add the SUBMITTER=pra attribute to the MAIL FROM command. I am proposing this sentence be removed from the paragraph, Second, in regards to the initial part of the paragraph, the term MTA should be clarified. Was the survey a look at "MTA Vendors/Software" or "MTA Sites?" The two cited MTA are vendors. I did a quick look of our support site outbound mail SMTP session log this morning and the following domains all have SUBMITTER enabled. pcpursuits.com bozax.com cisbbs.nl box24.ch foxriver.net superp.com Gsd-Co.Com thirdrockbbs.com reu.org icsbbs.com tbsp.com rdfig.net techware.dynip.com opcug.ca foxriver.net newsserviceflorida.com statehousenews.com and that is just with small technical support group mailing list. Our much larger general announcement/newsletter mailing list will show perhaps 4-5 hundred domains using SUBMITTER. Sure, small potatoes, but its not just two and McAfee, a much larger vendor, probably has a larger customer base of SMTP servers with SUBMITTER server support. Does this change anything regarding the perception SUBMITTER is not supported? -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From vesely@tana.it Fri Apr 6 08:35: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 6298221F85AA for ; Fri, 6 Apr 2012 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.523 X-Spam-Level: X-Spam-Status: No, score=-4.523 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIKQcmfjn8hP for ; Fri, 6 Apr 2012 08:35:48 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 526A121F85A1 for ; Fri, 6 Apr 2012 08:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333726547; bh=ainQuw7TvCuHg3EvZx/D5lbXUwQgoOiYF+10/Oji/3w=; l=1019; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Y/cy5L/xVdFLfj6RZE/PpTFbQK0HBlqS/nsblD3ZDzP3OH1R1KBNY0XtATXr7CW14 bt0oGTp/azmL7ekzkCF+phF8zKH5j9C0N4ZkJJbIvxpLwC5uZnB37BHzM1GNrSAsW8 CZpgZRH+MNs2A7OI7NQ5P7OY9PGbqZdJcDawx73c= 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, 06 Apr 2012 17:35:47 +0200 id 00000000005DC047.000000004F7F0D53.00000682 Message-ID: <4F7F0D52.30405@tana.it> Date: Fri, 06 Apr 2012 17:35:46 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F7DED0A.6040809@isdg.net> <4F7EEB63.3050908@tana.it> <1832269.tsjzSkJokG@scott-latitude-e6320> In-Reply-To: <1832269.tsjzSkJokG@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 15:35:49 -0000 On Fri 06/Apr/2012 17:02:46 +0200 Scott Kitterman wrote: > On Friday, April 06, 2012 03:10:59 PM Alessandro Vesely wrote: >> >> The error correction that I'm proposing with issue #12 substantially >> is that the helo identity must be checked by those who do reject-on- >> fail, and if it is a "pass" the receiver must not reject. > > This makes the mail from check meaningless as it's trivial to arrange for a > random HELO name to pass SPF checks. HELO pass overriding SPF Fail is only > logical if the HELO name is known to you as a 'safe' host. This is usable as > a white listing technique, not a general purpose solution to dealing with the > intersection of SPF and forwarding. Pardon my being thick, but why would a helo name be easier to forge than a bounce address? Besides, we don't need to specify how different identities may concur to form a "final" assertion, we can just specify the reject-on-fail behavior such that it works in all cases, and can thus be recommended to all hosts. From hsantos@isdg.net Fri Apr 6 08:48: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 DA01B21F8597 for ; Fri, 6 Apr 2012 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWDxiRKPDhow for ; Fri, 6 Apr 2012 08:48:05 -0700 (PDT) Received: from dkim.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 07DFE21F8587 for ; Fri, 6 Apr 2012 08:48:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1805; t=1333727283; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=XwP1Fi3YZrm8j6vcRW+w+t3XM1w=; b=wetR3z/x59EtBnA8I3mH SbScP33+y8peO1FKJx0lztqQNNn+GczVcxOIi6CHMNQmA0uMajcjBHV7mU1uE8sN amdrD2+LIIj6i2vBvilHNYAuzb37upRoIYLAv6Ht7716+oObZc4VsFRDQqXca4YI fIaXQcKcUwKWgkFZdlBOV2Q= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 11:48: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2634117197.18315.1552; Fri, 06 Apr 2012 11:48:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1805; t=1333726969; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=eQoPL/9 qRhk5nuKXTn2bt5WGMUmzrTXWBXErYSOShzA=; b=MFzQZsXPjOZyT4g3RN5PJXE gqP5Fogrp4cbS1VPajNueYfU2oM3S9gai43EKAbNzGXJt4hxy7OEjpBKEMJUJRb5 5Wo/pCl79wJ3XTQz+P2qG7YBIqbAitLlF7xW6WSLtHr1wUp2GecPpcjvyyN5iv4q Ivd2fd9Z62GJcNeWLQDQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 11:42:49 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3233024924.38558.1920; Fri, 06 Apr 2012 11:42:48 -0400 Message-ID: <4F7F1039.7090407@isdg.net> Date: Fri, 06 Apr 2012 11:48:09 -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: <4F7EF972.7030404@tana.it> In-Reply-To: <4F7EF972.7030404@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue? A language complementary to RFC 2119 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 15:48:06 -0000 Alessandro Vesely wrote: > Should we define some imperatives that express the actions that a > receiver is expected to take according of the meaning of protocol > tokens such as "-all"? Yes. Already done. A sender violation of a SPF HARD FAIL domain policy should always be a rejection. Ignoring this defeats the high benefit SPF potential and purpose SPF offers and wastes everyone's time across the board when not honored. It certainly violates the domain's wishes to secure and protect its brand. Note, of course, a receiver can decide to accept the failed SPF message and tag it or whatever, but its certainly not doing the DOMAIN any favor. > If we do, then we'll be able to confer a > precise technical meaning to sentences like, e.g., "Receivers NEED > reject if the result is Fail, CAN reject on PermError, and DARE reject > on TempError". Uh? No. Rejection Mandates could only be technically justified as a zero false positive/negative (depending on your pov) verification or validation result where there are absolutely NO accidents or errors, in which case, it is indeterminate state and the protocol failed. It is a blessing and curse. Its blessing when the protocol works as expected and there no errors. Its a curse when the protocol doesn't work or weak policy provisions are used because it continues to provide the legacy loop hole for "bad-guys" to get around any sort of strong rejection policies without a zero-false positive result. On the other hand, there is nothing stopping an implementation from learning the failure rates and using some scoring concept where an indeterminate condition could be promoted/demoted to a more stronger actionable state. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From spf2@kitterman.com Fri Apr 6 09:04: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 1E05521F851E for ; Fri, 6 Apr 2012 09:04: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxhyDJouGkiI for ; Fri, 6 Apr 2012 09:04:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6BECF21F84D8 for ; Fri, 6 Apr 2012 09:04:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9BC9520E410E; Fri, 6 Apr 2012 12:04:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1333728268; bh=AW0cMGCuzasce/Biw9BkJ+HP4OZcqhq1AsoH82186YU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Z/I4S31UBDN4y/J4ziufr8/juTnK6c0zn0lChMlspifQIH34y5RTqkTu81I4swg56 4cJH1Jw8U5LB8iFebs9omsRPJaYOFO2xjcjXyax6tYuYhQz3yQ8Vz1rWq0RgzwXhFh 8wB7tE4nItRYNyyCtqa0h0hI0ESQO2popVM2UUAc= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6D18E20E4083; Fri, 6 Apr 2012 12:04:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 06 Apr 2012 12:04:26 -0400 Message-ID: <3193488.lvEsj8R6CO@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-17-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F7F0D52.30405@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 16:04:30 -0000 On Friday, April 06, 2012 05:35:46 PM Alessandro Vesely wrote: > On Fri 06/Apr/2012 17:02:46 +0200 Scott Kitterman wrote: > > On Friday, April 06, 2012 03:10:59 PM Alessandro Vesely wrote: > >> The error correction that I'm proposing with issue #12 substantially > >> is that the helo identity must be checked by those who do reject-on- > >> fail, and if it is a "pass" the receiver must not reject. > > > > This makes the mail from check meaningless as it's trivial to arrange > > for a random HELO name to pass SPF checks. HELO pass overriding SPF > > Fail is only logical if the HELO name is known to you as a 'safe' host. > > This is usable as a white listing technique, not a general purpose > > solution to dealing with the intersection of SPF and forwarding. > > Pardon my being thick, but why would a helo name be easier to forge > than a bounce address? > > Besides, we don't need to specify how different identities may concur > to form a "final" assertion, we can just specify the reject-on-fail > behavior such that it works in all cases, and can thus be recommended > to all hosts. They are equally easy to forge. If the design is that a HELO pass overrides a Mail From fail then if HELO passes one can use arbitrary Mail Froms and SPF won't care. Since there need be no relationship between HELO name and Mail From (and the specifically won't be in the case of forwarders) that means that all a sender needs to do is publish an SPF record for HELO and then the can use any Mail From they want. That's why you can only use HELO pass to white list from SPF Mail From checks if you have reason to trust the host in question. It doesn't work for arbitrary senders. Scott K From vesely@tana.it Fri Apr 6 09:53: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 C876F21F85DF for ; Fri, 6 Apr 2012 09:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.547 X-Spam-Level: X-Spam-Status: No, score=-4.547 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbUZgOXTl6U8 for ; Fri, 6 Apr 2012 09:53:09 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B0A3821F85DD for ; Fri, 6 Apr 2012 09:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333731187; bh=DATSt5QuFH6A5hY/Vmfb3YE8Gr0Ec5Saxv04HBXF6bc=; l=2632; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=VemR3TKxVRPd0lENyZoId22bVGGhFKXhLaPEHSueLGyw2d00LPB6bPJ7tM7gy8LSE LWKMTf5Po03jFxGBWPFujLHX/wDisJsK/uk/pNxVgtLXi20oLbmrWcFTCYnDTTrzIp 6sOHJy6j3NbkhAnp+vcGFvXmHJH+czMmO7tISkxQ= 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, 06 Apr 2012 18:53:07 +0200 id 00000000005DC046.000000004F7F1F73.0000189F Message-ID: <4F7F1F73.505@tana.it> Date: Fri, 06 Apr 2012 18:53:07 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> In-Reply-To: <3193488.lvEsj8R6CO@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 16:53:09 -0000 On Fri 06/Apr/2012 18:18:50 +0200 Scott Kitterman wrote: > On Friday, April 06, 2012 05:35:46 PM Alessandro Vesely wrote: >> On Fri 06/Apr/2012 17:02:46 +0200 Scott Kitterman wrote: >>> On Friday, April 06, 2012 03:10:59 PM Alessandro Vesely wrote: >>>> The error correction that I'm proposing with issue #12 substantially >>>> is that the helo identity must be checked by those who do reject-on- >>>> fail, and if it is a "pass" the receiver must not reject. >>> >>> This makes the mail from check meaningless as it's trivial to arrange >>> for a random HELO name to pass SPF checks. HELO pass overriding SPF >>> Fail is only logical if the HELO name is known to you as a 'safe' host. >>> This is usable as a white listing technique, not a general purpose >>> solution to dealing with the intersection of SPF and forwarding. >> >> Pardon my being thick, but why would a helo name be easier to forge >> than a bounce address? >> >> Besides, we don't need to specify how different identities may concur >> to form a "final" assertion, we can just specify the reject-on-fail >> behavior such that it works in all cases, and can thus be recommended >> to all hosts. > > They are equally easy to forge. > > If the design is that a HELO pass overrides a Mail From fail then if HELO > passes one can use arbitrary Mail Froms and SPF won't care. Since there need > be no relationship between HELO name and Mail From (and the specifically won't > be in the case of forwarders) that means that all a sender needs to do is > publish an SPF record for HELO and then they can use any Mail From they want. Yes! IOW, if we can have forwarders publish an SPF record for (at least) each mailout of theirs, it will then work reliably. > That's why you can only use HELO pass to white list from SPF Mail From checks > if you have reason to trust the host in question. It doesn't work for > arbitrary senders. I fail to see how you derive the latter paragraph. Nowadays, nobody is sending out bounces after accepting a message. Receivers who rely on SPF results for bouncing can (and IMHO should) continue to use the relevant SPF result for doing so. Inducing backscatter seems to be the only reason why a spammer would opt for gaming the Mail From rather than Helo, but backscatter can be considered solved. OTOH, we'd keep requiring the ability to publish an SPF record in order to send from a given IP address. And if we can sell reject-on-fail as reliable and recommendable, it will get more adoption. Casting the spam problem upon the market of throw-away domains was the original SPF intent. From msk@cloudmark.com Fri Apr 6 13:19: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 4849811E809B for ; Fri, 6 Apr 2012 13:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJolvWuT6-MC for ; Fri, 6 Apr 2012 13:19:51 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4249611E8098 for ; Fri, 6 Apr 2012 13:19:51 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 13:19:50 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: SUBMITTER survey Thread-Index: Ac0UMp4VlpNopD8yRG+QHJ/7seYDvA== Date: Fri, 6 Apr 2012 20:19:49 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280CD27Dexchmbx901corpclo_" MIME-Version: 1.0 Subject: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 20:19:52 -0000 --_000_9452079D1A51524AA5749AD23E0039280CD27Dexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the sake of being thorough, I have initiated a second survey, this time= checking MTAs for which ones advertise SUBMITTER. The 220 banner and whet= her or not SUBMITTER was among the listed ESMTP extensions will be recorded= for each host; the banner is recorded so that we can tell which ones appea= r to be the same MTA software. It's checking the MXes of over a million do= mains, filtering for duplicates. This will obviously take some time, but i= t has reasonable timeouts so we should get a decent sample subset in a shor= t period of time. I don't expect the results of this to allow for a different conclusion than= the one we've already reached. Even if we find a lot of MTAs offering the= extension, not many sending domains expect it to be used. Specifically, b= y the specs, SUBMITTER provides input to Sender-ID (either in place of, or = for direct comparison to, the PRA), and there are so few "spf2.0/pra" polic= ies out there (under 5%) that even if SUBMITTER is offered and used, the va= lue is typically discarded. -MSK --_000_9452079D1A51524AA5749AD23E0039280CD27Dexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the sake of being thorough, I have initiated a s= econd survey, this time checking MTAs for which ones advertise SUBMITTER.&n= bsp; The 220 banner and whether or not SUBMITTER was among the listed ESMTP= extensions will be recorded for each host; the banner is recorded so that we can tell which ones appear to be the sam= e MTA software.  It’s checking the MXes of over a million domain= s, filtering for duplicates.  This will obviously take some time, but = it has reasonable timeouts so we should get a decent sample subset in a short period of time.

 

I don’t expect the results of this to allow fo= r a different conclusion than the one we’ve already reached.  Ev= en if we find a lot of MTAs offering the extension, not many sending domain= s expect it to be used.  Specifically, by the specs, SUBMITTER provides input to Sender-ID (either in place of, or for direct c= omparison to, the PRA), and there are so few “spf2.0/pra” polic= ies out there (under 5%) that even if SUBMITTER is offered and used, the va= lue is typically discarded.

 

-MSK

--_000_9452079D1A51524AA5749AD23E0039280CD27Dexchmbx901corpclo_-- From hsantos@isdg.net Fri Apr 6 14:15: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 2310411E80D3 for ; Fri, 6 Apr 2012 14:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1uhaCoprS79 for ; Fri, 6 Apr 2012 14:15:25 -0700 (PDT) Received: from groups.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2185311E809B for ; Fri, 6 Apr 2012 14:15:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1593; t=1333746913; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=updsXPx5y+UpXICeuHn5h1KoLkQ=; b=TcEjG6MYxcz050z0OjE2 TsjxP20RgJojvXpG7SFXBhKdc0JNAfCeCCYKzr6jaAdAAgAEs/JhYZ1rhDCJAkfT IqnkglUf0lysprDxQaAeijx/vEGqNcRzHcSZNhjturzxRDtfp3dqky4jW/VNs4MR pg+8eVXkMImZ0e8qCEQzez8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 17:15:13 -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 v6.4.454.1) with ESMTP id 2653747504.18315.1436; Fri, 06 Apr 2012 17:15:12 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1593; t=1333746600; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=k1M6F5h KmkIYDD2KdM1msoZPBO7IFYv4uc90rwTmKXM=; b=sapAGwHFEZqkHeoyjJXE7MI i7lVuyv0tj45Wy2+Q2mBADj3mbNJf3WXeG0oEnO1Uxqfme3uMArzIoJ9y+HPKWIc 4dypWVn+vhdNNCcB4jL34xi2uKGFTvMnw1He4BOeCJ1QGBgqNRNeQH4/ocCy5DLH t+hHiR5iO31jK8Ne95bU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 17:10:00 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3252655674.38589.6720; Fri, 06 Apr 2012 17:09:59 -0400 Message-ID: <4F7F5CB3.1030103@isdg.net> Date: Fri, 06 Apr 2012 17:14: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: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.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] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 21:15:26 -0000 Murray S. Kucherawy wrote: > For the sake of being thorough, I have initiated a second survey, this time checking MTAs for which ones advertise SUBMITTER. The 220 banner and whether or not SUBMITTER was among the listed ESMTP extensions will be recorded for each host; the banner is recorded so that we can tell which ones appear to be the same MTA software. It's checking the MXes of over a million domains, filtering for duplicates. This will obviously take some time, but it has reasonable timeouts so we should get a decent sample subset in a short period of time. > > I don't expect the results of this to allow for a different conclusion than the one we've already reached. Even if we find a lot of MTAs offering the extension, not many sending domains expect it to be used. Specifically, by the specs, SUBMITTER provides input to Sender-ID (either in place of, or for direct comparison to, the PRA), and there are so few "spf2.0/pra" policies out there (under 5%) that even if SUBMITTER is offered and used, the value is typically discarded. Hi, Ok, but the report should also be prepared to ask and answer the question if there is a new lost of email security for 5% of the domains when SPFBIS recommends receivers should not longer be supported and just ignore it. What level of Security Threshold does the IETF use to measure significant? 1% 5% 10% or higher? Even if it happens for the few, it can also raise product liability concerns - its not something I am trained to ignore. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From spf2@kitterman.com Fri Apr 6 14:24: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 9CAB311E80AA for ; Fri, 6 Apr 2012 14:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klSBx7yXJJKB for ; Fri, 6 Apr 2012 14:24:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2A11E8098 for ; Fri, 6 Apr 2012 14:24:08 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D181720E410E; Fri, 6 Apr 2012 17:24:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1333747447; bh=NGq3RlMZnI7hJOzu8xhEPHeyoyq95neRzN2sVzm+BuQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=GBygErBH3XMNu/+W6BCYSJM3kXEIbUQOgvWMWWTRk64bqgL5sc6uFjjqzIRYTy0K0 UuXjhMZAhkyLAxqCaq/8HFWtTLDF5azRdqAI4vnu66tXAC7R6UycpYM4sc2fIBSK5k lLoxT00ETgdHA64H32eI1baaCUK5+nvwinlAzH9g= Received: from scott-latitude-e6320.localnet (unknown [74.5.120.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4DBD720E4083; Fri, 6 Apr 2012 17:24:07 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 06 Apr 2012 17:23:57 -0400 Message-ID: <3370800.21ekH8ejiJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-17-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F7F5CB3.1030103@isdg.net> References: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@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] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 21:24:09 -0000 On Friday, April 06, 2012 05:14:27 PM Hector Santos wrote: > Murray S. Kucherawy wrote: > > For the sake of being thorough, I have initiated a second survey, this > > time checking MTAs for which ones advertise SUBMITTER. The 220 banner > > and whether or not SUBMITTER was among the listed ESMTP extensions will > > be recorded for each host; the banner is recorded so that we can tell > > which ones appear to be the same MTA software. It's checking the MXes > > of over a million domains, filtering for duplicates. This will > > obviously take some time, but it has reasonable timeouts so we should > > get a decent sample subset in a short period of time. > > > > I don't expect the results of this to allow for a different conclusion > > than the one we've already reached. Even if we find a lot of MTAs > > offering the extension, not many sending domains expect it to be used. > > Specifically, by the specs, SUBMITTER provides input to Sender-ID > > (either in place of, or for direct comparison to, the PRA), and there > > are so few "spf2.0/pra" policies out there (under 5%) that even if > > SUBMITTER is offered and used, the value is typically discarded. > Hi, > > Ok, but the report should also be prepared to ask and answer the > question if there is a new lost of email security for 5% of the > domains when SPFBIS recommends receivers should not longer be > supported and just ignore it. What level of Security Threshold does > the IETF use to measure significant? 1% 5% 10% or higher? Even if it > happens for the few, it can also raise product liability concerns - > its not something I am trained to ignore. Support or non-support of SUBMITTER is irrelevant from a security perspective unless you are worried about people spoofing resent-sender. Scott K From dotis@mail-abuse.org Fri Apr 6 14:41: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 5ABF621F8475 for ; Fri, 6 Apr 2012 14:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpt4wdxjuofo for ; Fri, 6 Apr 2012 14:41:37 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC6721F8473 for ; Fri, 6 Apr 2012 14:41:37 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 4863F17404BA for ; Fri, 6 Apr 2012 21:41:37 +0000 (UTC) Message-ID: <4F7F6310.6080201@mail-abuse.org> Date: Fri, 06 Apr 2012 14:41:36 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> In-Reply-To: <3193488.lvEsj8R6CO@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Apr 2012 21:41:38 -0000 On 4/6/12 9:04 AM, Scott Kitterman wrote: > On Friday, April 06, 2012 05:35:46 PM Alessandro Vesely wrote: > >> On Fri 06/Apr/2012 17:02:46 +0200 Scott Kitterman wrote: > >>>> On Friday, April 06, 2012 03:10:59 PM Alessandro Vesely > >>>> wrote: > >>>>>> The error correction that I'm proposing with issue #12 > >>>>>> substantially is that the helo identity must be checked > >>>>>> by those who do reject-on- fail, and if it is a "pass" > >>>>>> the receiver must not reject. > >>>> > >>>> This makes the mail from check meaningless as it's trivial to > >>>> arrange for a random HELO name to pass SPF checks. HELO pass > >>>> overriding SPF Fail is only logical if the HELO name is known > >>>> to you as a 'safe' host. This is usable as a white listing > >>>> technique, not a general purpose solution to dealing with the > >>>> intersection of SPF and forwarding. > >> > >> Pardon my being thick, but why would a helo name be easier to > >> forge than a bounce address? > >> > >> Besides, we don't need to specify how different identities may > >> concur to form a "final" assertion, we can just specify the > >> reject-on-fail behavior such that it works in all cases, and can > >> thus be recommended to all hosts. > > They are equally easy to forge. > > If the design is that a HELO pass overrides a Mail From fail then if > HELO passes one can use arbitrary Mail Froms and SPF won't care. > Since there need be no relationship between HELO name and Mail From > (and the specifically won't be in the case of forwarders) that means > that all a sender needs to do is publish an SPF record for HELO and > then the can use any Mail From they want. > > That's why you can only use HELO pass to white list from SPF Mail > From checks if you have reason to trust the host in question. It > doesn't work for arbitrary senders. Dear Scott, Neither "Mail From" nor "Helo" offers protection from unknown senders, nor is either visible to recipients. Reject messages on SPF "Helo" failures but not "Mail From". Rejecting messages on "Mail From" failure is not compliant with unresolved forwarding conflicts. Lack of compliance incurs support expenses not compensated by claims acceptance goes against a third-party desire to dictate handling that also lessens SMTP delivery integrity. SPF should only require rejection for "Helo" check failures, not for "Mail From". Regards, Douglas Otis From internet-drafts@ietf.org Fri Apr 6 15:12: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 5FAA811E80AA; Fri, 6 Apr 2012 15:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaWnFpf58SDu; Fri, 6 Apr 2012 15:12:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E3B11E8098; Fri, 6 Apr 2012 15:12:55 -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.00 Message-ID: <20120406221255.6603.12555.idtracker@ietfa.amsl.com> Date: Fri, 06 Apr 2012 15:12:55 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-00.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, 06 Apr 2012 22:12:56 -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 : Resolution of The SPF/Sender-ID Experiment Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-00.txt Pages : 9 Date : 2012-04-06 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender-ID, two proposed email authentication protocols. Because of interoperability concerns created by simultaneous use of the two protocols by a receiver, and some concerns with Sender-ID and compatibility with existing standards, the IESG required them to have Experimental status and invited the community to observe their deployments for a period of time, hoping convergence would be possible later. After six years, sufficient experience and evidence have been collected that the experiment thus created can be considered concluded, and a single protocol can be advanced. This memo presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-00.txt From ajs@anvilwalrusden.com Fri Apr 6 17:46: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 EBABA21F843C for ; Fri, 6 Apr 2012 17:46: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zJYTW6X9DDE for ; Fri, 6 Apr 2012 17:46:33 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 655C521F8425 for ; Fri, 6 Apr 2012 17:46:33 -0700 (PDT) Received: from crankycanuck.ca (209.77-ppp.3menatwork.com [72.0.209.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3EB7E1ECB41D for ; Sat, 7 Apr 2012 00:46:23 +0000 (UTC) Date: Fri, 6 Apr 2012 20:46:15 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120407004607.GA35694@crankycanuck.ca> References: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F7F5CB3.1030103@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 00:46:34 -0000 My chair hat is on, but I have not discussed this with SM yet. Hector: On Fri, Apr 06, 2012 at 05:14:27PM -0400, Hector Santos wrote: > Ok, but the report should also be prepared to ask and answer the > question if there is a new lost of email security for 5% of the > domains when SPFBIS recommends receivers should not longer be > supported and just ignore it. Why? This WG is not chartered to add SUBMITTER support to SPF. Even if we concluded that it would be desirable, to do that would require rechartering. But in any case, without an operational definition of "email security" in your note, the claim is inoperative. The empirical evidence we have so far is that this feature is just not widely supported. You would need a strong argument indeed to show that a feature that is not widely used and is also not part of the work we are chartered to undertake is something that we nevertheless need to address. If you have alternative study evidence to contradict the evidence Murray has so far produced -- i.e. to show that the feature is in fact widely used in conjunction with SPF, or else that the feature provides critical additional benefit not provided by SPF, then present that. Your note instead attempts to define the conclusions we are drawing from the data in advance, so as to reflect a preferred outcome. That's not drawing conclusions from data; that's drawing a conclusion and then finding data. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Fri Apr 6 18:20: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 9E17221F854E for ; Fri, 6 Apr 2012 18:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA0g5HfG2zzr for ; Fri, 6 Apr 2012 18:20:40 -0700 (PDT) Received: from groups.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6E81021F854D for ; Fri, 6 Apr 2012 18:20:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3229; t=1333761634; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=pMCThLk8VPgwRAXOip83qqqwRE4=; b=Cd6frUug6rWw3n8tLzec llt/OQZngrs4xwrEcjtR+zLcnUzHgTNUsUUiSt4Pvui7t3SjHH79I1u6JQb82FUf RtwEmAnV7zXB7SyZ6Lt+ti5QY2FVIBf/kvFZk7l4VXCyARYvmRQ4mnG6+GP6PFpP tvmVwVUfhyjWX9mH/bbyCkg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 21:20:34 -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 v6.4.454.1) with ESMTP id 2668467681.18315.5592; Fri, 06 Apr 2012 21:20:33 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3229; t=1333761323; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HIMI9+M 3iwiwXiPENL4l+KvkW3KIXLWIj3mC3fwAX4M=; b=GjT0mJbRuwyx/ADbg229MCD KKsZiCd9E2TGaKV+LddsWz81j2qXUewq9pNOFS2u8wsXJX8kS2jNggmegx2ohfCL GoB7OSFkL003aU13x9t1WAwoWLACd4bIIPPhkSkzxtJ3C5g65oVVPEAdFKqzd5cC ySG2+smMZX5ryjySPcsw= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 21:15:23 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3267379221.38616.4712; Fri, 06 Apr 2012 21:15:23 -0400 Message-ID: <4F7F964E.9060905@isdg.net> Date: Fri, 06 Apr 2012 21:20:14 -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: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <20120407004607.GA35694@crankycanuck.ca> In-Reply-To: <20120407004607.GA35694@crankycanuck.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 01:20:41 -0000 Andrew Sullivan wrote: > My chair hat is on, but I have not discussed this with SM yet. > > Hector: > > On Fri, Apr 06, 2012 at 05:14:27PM -0400, Hector Santos wrote: > >> Ok, but the report should also be prepared to ask and answer the >> question if there is a new lost of email security for 5% of the >> domains when SPFBIS recommends receivers should not longer be >> supported and just ignore it. > > Why? This WG is not chartered to add SUBMITTER support to SPF. Even > if we concluded that it would be desirable, to do that would require > rechartering. > > But in any case, without an operational definition of "email security" > in your note, the claim is inoperative. The empirical evidence we > have so far is that this feature is just not widely supported. You > would need a strong argument indeed to show that a feature that is not > widely used and is also not part of the work we are chartered to > undertake is something that we nevertheless need to address. > > If you have alternative study evidence to contradict the evidence > Murray has so far produced -- i.e. to show that the feature is in fact > widely used in conjunction with SPF, or else that the feature provides > critical additional benefit not provided by SPF, then present that. > Your note instead attempts to define the conclusions we are drawing > from the data in advance, so as to reflect a preferred outcome. > That's not drawing conclusions from data; that's drawing a conclusion > and then finding data. I don't agree that that view of the post. In fact, what you describe is exactly what was being done first. State a goal, then go about to find data to justify killing the protocol. It is a premature report conclusion on the first point that there is no support, incorrect on the 2nd point only two MTAs supporting it, and irregular on the 3rd point to use a subjective, unproven "Malware" quality of message consideration in an inter-op report to explain the clear evidence of extremely wide client support and why this subjective type of client support just not be considered. http://www.ietf.org/mail-archive/web/spfbis/current/msg01054.html http://www.ietf.org/mail-archive/web/spfbis/current/msg01062.html There is clear evidence of thousands of MTA site support. It should not matter than its just two MTA vendors. This would be suggesting sendmail is or is not supporting XYZ feature, therefore it is/not a standard, when in fact, it would be vital data point due to its wide MTA sites implementation and would be use as evidence of support or lack there of. I also believe it is not my duty to justify why it should remain, but I believe I did provide clear interop, engineering and security related input. IMO, it is duty of the reporter to clearly justify why should it be removed and also make sure there is no repercussions, including security related potentials when it is fact removed. Finally, the WG is chartered to decide its fate. The goal was pretty much well known what was wanted by the editor and in my opinion, the reasons cited so far are not quite adequate. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Fri Apr 6 21:01: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 77D3621F843F for ; Fri, 6 Apr 2012 21:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2xDWTBv7Yhp for ; Fri, 6 Apr 2012 21:01:47 -0700 (PDT) Received: from news.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5DC21F842C for ; Fri, 6 Apr 2012 21:01:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1354; t=1333771304; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=y0q0kvim8JmkolR1YkiVQyRYpb8=; b=hrg4JsKydjiHNdrG2NPl L5eUqKkZ7mbh8mdVLnI8cV3abXXU00WWETuP50sRgeIxrMx3XKHZzW0xKAnJEaTw E9z6V+Rxy8lfGK/qPKmJnSZYuS8Uio+h67Ds6Y/TX87KJ5DcWs3uTaHo/eQfN0DH fWdPi6+yxHyhg+NgKRTM4vw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 07 Apr 2012 00:01: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 v6.4.454.1) with ESMTP id 2678137871.18315.2340; Sat, 07 Apr 2012 00:01:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1354; t=1333770991; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=twl2bUZ xhqAFuCyHEvt2CvU+rX9w0dvBwehacv7ZYdE=; b=TllXM5cJLi/L49YItiGDRS1 0wCYywsEj5AmqVbWZnmotXIw2q/lup7yQMsx2FscWdAvo5BTdsHcpuH6j/5Qe1TO PAdNmDibfLGL8P9dY2Lgl85M7sBIG8e0xZoWOo38YLA4c05gk3X79zIg0p08/9mH PPqpdrHkf3diMkESmZwk= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Apr 2012 23:56:31 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3277045830.38629.6340; Fri, 06 Apr 2012 23:56:29 -0400 Message-ID: <4F7FBC18.5090100@isdg.net> Date: Sat, 07 Apr 2012 00:01:28 -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: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <3370800.21ekH8ejiJ@scott-latitude-e6320> In-Reply-To: <3370800.21ekH8ejiJ@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 04:01:48 -0000 Scott Kitterman wrote: > On Friday, April 06, 2012 05:14:27 PM Hector Santos wrote: >> Ok, but the report should also be prepared to ask and answer the >> question if there is a new lost of email security for 5% of the >> domains when SPFBIS recommends receivers should not longer be >> supported and just ignore it. What level of Security Threshold does >> the IETF use to measure significant? 1% 5% 10% or higher? Even if it >> happens for the few, it can also raise product liability concerns - >> its not something I am trained to ignore. > > Support or non-support of SUBMITTER is irrelevant from a security perspective > unless you are worried about people spoofing resent-sender. Hi, I'm an implementator the protocol automaton and 2nd guessing the value or source of the PRA is not part of it. The reasons why SIDF clients use it would be expected to be one based on security and/or their the ADMD desire to protect the PRA domain. So I don't quite follow the presumed irrelevancy of security being made. If there is a 5% usage of SPF2.0/PRA, subjectively dropping the protocol where there is clear protocol support for it, needs to satisfy answering the ADMD lost of PRA security question. It can't be ignored or thrown side lightly. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From dotzero@gmail.com Sat Apr 7 01:21: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 1731B21F842A for ; Sat, 7 Apr 2012 01:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMIlKnBOJpEW for ; Sat, 7 Apr 2012 01:21:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6421F84FE for ; Sat, 7 Apr 2012 01:21:29 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3135116pbb.31 for ; Sat, 07 Apr 2012 01:21: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:content-transfer-encoding; bh=kAkQur3mIQ3yF4CoUuIwxRz6yFO4up/cX42PbmhmoVw=; b=bmhg4lc0Mf1kySPTxRbuabpFXwlwQAXTRMtKzhITVq2fqoKAXXO9E3EOlroF5kAZYI bAujWKGfJ4xRE/S+DYPKoXD9oCUvZDBzW7vfrLvibKgwIgxAYjCDlSYlvBqShkZQ459R h4GeydF1HPvilJ17Oe3uzS+KpyOMHGszMQyrvEq1tXd5/lvnjXNyD8+BT2m8TpFHt+75 P+vPV+7OZl/2Gzqj4j044I/MFlsAVvT8/aemtcXWTxyliLZqQmdsJ4IaTPkx/hpnq5GK xsIOZFElTquKT45tQwDkiNO+TEaBbyV81AQWqEHJBPBkQKJRs0/FeKuMboH+mdirwbsq SBzg== MIME-Version: 1.0 Received: by 10.68.125.131 with SMTP id mq3mr1847543pbb.123.1333786888901; Sat, 07 Apr 2012 01:21:28 -0700 (PDT) Received: by 10.68.195.106 with HTTP; Sat, 7 Apr 2012 01:21:28 -0700 (PDT) In-Reply-To: <4F7FBC18.5090100@isdg.net> References: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <3370800.21ekH8ejiJ@scott-latitude-e6320> <4F7FBC18.5090100@isdg.net> Date: Sat, 7 Apr 2012 04:21:28 -0400 Message-ID: From: Dotzero To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 08:21:31 -0000 On Sat, Apr 7, 2012 at 12:01 AM, Hector Santos wrote: > Scott Kitterman wrote: >> >> On Friday, April 06, 2012 05:14:27 PM Hector Santos wrote: > > >>> Ok, but the report should also be prepared to ask and answer the >>> question if there is a new lost of email security for 5% of the >>> domains when SPFBIS recommends receivers should not longer be >>> supported and just ignore it. =A0What level of Security Threshold does >>> the IETF use to measure significant? 1% 5% 10% or higher? =A0Even if it >>> happens for the few, it can also raise product liability concerns - >>> its not something I am trained to ignore. >> >> >> Support or non-support of SUBMITTER is irrelevant from a security >> perspective unless you are worried about people spoofing resent-sender. > > > Hi, > > I'm an implementator the protocol automaton and 2nd guessing the value or > source of the PRA is not part of it. =A0The reasons why SIDF clients use = it > would be expected to be one based on security and/or their the ADMD desir= e > to protect the PRA domain. So I don't quite follow the presumed irrelevan= cy > of security being made. =A0If there is a 5% usage of SPF2.0/PRA, subjecti= vely > dropping the protocol where there is clear protocol support for it, needs= to > satisfy answering the ADMD lost of PRA security question. =A0It can't be > ignored or thrown side lightly. > > Hector, Apart from the fact that we are updating 4408 and not SIDF, PRA is broken (I can send mail all day long and get a neutral no matter what a domain publishes) which I publicly documented as far back as 2006. Mike From vesely@tana.it Sat Apr 7 04:49: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 0ACCA21F8552 for ; Sat, 7 Apr 2012 04:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.557 X-Spam-Level: X-Spam-Status: No, score=-4.557 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u7LkEnIk7uU for ; Sat, 7 Apr 2012 04:49:08 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D24DD21F84D0 for ; Sat, 7 Apr 2012 04:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333799345; bh=Mqtm2QB59kjjY8bmckGxbU757QVlEIx/YTAxbuj6sjw=; l=1610; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hXiwRuD9JyAJk4vaXc90a6pDJd7Fq6ilWe/v2TL6Ra9iqZgjoHIwuEsbYFd8KxOxw wpbdpAyk+ifK1crCh8w9ITX4kT/EhQg4RrRwJkjPDmVuwdyd/17WkaY6wx1JnmWtfB kFSjD+m2h9XTTrC1/oO9oxHk3OHPMlZVNcs011Dc= 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, 07 Apr 2012 13:49:05 +0200 id 00000000005DC03F.000000004F8029B1.000015C6 Message-ID: <4F8029B1.1060102@tana.it> Date: Sat, 07 Apr 2012 13:49:05 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> In-Reply-To: <4F7F6310.6080201@mail-abuse.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 11:49:09 -0000 On Sat 07/Apr/2012 13:10:52 +0200 Douglas Otis wrote: > On 4/6/12 9:04 AM, Scott Kitterman wrote: >> >> If the design is that a HELO pass overrides a Mail From fail then if >> HELO passes one can use arbitrary Mail Froms and SPF won't care. >> Since there need be no relationship between HELO name and Mail From >> (and the specifically won't be in the case of forwarders) that means >> that all a sender needs to do is publish an SPF record for HELO and >> then the can use any Mail From they want. >> >> That's why you can only use HELO pass to white list from SPF Mail >> From checks if you have reason to trust the host in question. It >> doesn't work for arbitrary senders. > > Neither "Mail From" nor "Helo" offers protection from unknown senders, > nor is either visible to recipients. Reject messages on SPF "Helo" > failures but not "Mail From". Rejecting messages on "Mail From" > failure is not compliant with unresolved forwarding conflicts. Lack > of compliance incurs support expenses not compensated by claims > acceptance goes against a third-party desire to dictate handling that > also lessens SMTP delivery integrity. SPF should only require > rejection for "Helo" check failures, not for "Mail From". Except for forwarding, however, the domain part of the mailfrom is a better authentication token, because it is more meaningful and has an SPF record more often, than the helo identity. The SMTP's bar for the ehlo parameter is implausibly low, due to the broadness of the context. Raising the bar for the specific case of forwarding may be more acceptable. From hsantos@isdg.net Sat Apr 7 05:58: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 7A8BB21F854E for ; Sat, 7 Apr 2012 05:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBHdRuVTUmeR for ; Sat, 7 Apr 2012 05:58:37 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A4EF321F854D for ; Sat, 7 Apr 2012 05:58:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1108; t=1333803513; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=G1p74uiv+8oR1uvXQzBCV8jo9Kg=; b=PT0Sf7gB3aQMCRkONAcq j2zT9inxcuWsBO10L3ViAziuM7VMGhLJwV99EcbE+2n4W21bXwozYAyp+iZPEruE M+KvDJy2rU4wTFXrQPWPToHhjGEDGCd+jABhgoX/AGrWcMmRbed3XBs4OJF5awNQ 5GdJvabdmHR8pBAzT1UwSEA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 07 Apr 2012 08:58:33 -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 v6.4.454.1) with ESMTP id 2710346009.20139.5484; Sat, 07 Apr 2012 08:58:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1108; t=1333803200; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=sE2Audl ccxLaew+CXAIAhdOxB38L3o5W7Ae1KVOOFNs=; b=PJb0aRw2kvjT8e5rm7P40vQ XTqnGHVe1gV4x/QFe5FWRhLGbaKSw2Xv+Uyj7JF3qw0Ho1pORC8rif+uFf1bn3t+ KiPOMSnAUHvwQLLaeGqrMk+bMyd2NSx5Z5UMcAMgvpRSxSWIdyMwxvRAHA5rllLw gj7sKo8EKCZ8hRGb4m/U= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 07 Apr 2012 08:53:20 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3309255315.102.7656; Sat, 07 Apr 2012 08:53:19 -0400 Message-ID: <4F8039F2.70606@isdg.net> Date: Sat, 07 Apr 2012 08:58:26 -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: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <20120407004607.GA35694@crankycanuck.ca> In-Reply-To: <20120407004607.GA35694@crankycanuck.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 12:58:38 -0000 Andrew Sullivan wrote: > But in any case, without an operational definition of "email security" > in your note, the claim is inoperative. Andrew, In regards to SPF, I submit it is an email security-related protocol and thus prime reason SPF/SIDF has enjoyed wide adoption and deployment. It wasn't done just for kicks and laughs. The abstract is pretty clear what SPF attempts to offer an email domain protection and security protocol: E-Mail 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 reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. Any suggestion the SPF/SIDF protocols are not email security-related protocols is "inoperative." -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From sm@elandsys.com Sat Apr 7 09:15: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 2FB9D21F859B for ; Sat, 7 Apr 2012 09:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQJSz1-OWydt for ; Sat, 7 Apr 2012 09:15: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 E468E21F8564 for ; Sat, 7 Apr 2012 09:15:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.121]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q37GFMu4017027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2012 09:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1333815335; i=@elandsys.com; bh=bscPy1x3UAJpikTpQJddK+9t0/mEVnY+EqqS9hywNrM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=msVCfIipSd8qMPMoaRXARg7lLZd81HVJ07rj6uBNxKn0ENvlyN8Ph3uJWJXstpL2x 6qN6Ibl36pfiFIe1afsGq/Un70Aumxlwfmje6tXE0WN/7/bubKxsENuSGdu51ZWi3B 7kJhIrNJu3MOz6+lncK4NYkT16OrhLO8QagH38as= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1333815335; i=@elandsys.com; bh=bscPy1x3UAJpikTpQJddK+9t0/mEVnY+EqqS9hywNrM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ifSzTgNpyzw564bnOSFuwLjnQIbQ9vepuyogAFSr52t5BardrG4OsMWbNd9iKKri1 seSL8manBfELP+eF+qE+7Ij2HjG+r76vpaP1kH/FzFZfGp8csJ9VG5aH9uOLDCcuEM CMJHaqFM1gGZDyMCsGlRi4UgUy8yzwKr5pU47IMo= Message-Id: <6.2.5.6.2.20120407083104.08e464d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Apr 2012 09:12:23 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F8039F2.70606@isdg.net> References: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <20120407004607.GA35694@crankycanuck.ca> <4F8039F2.70606@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 16:15:44 -0000 After reading the messages on this thread, it seems that the discussion is about the following text in draft-ietf-spfbis-experiment-00: (i) "In a survey of numerous MTAs in current or recent use, only two (Santronics WinServer and McAfee MxLogic) were found to contain implementations of the SMTP SUBMITTER extension as part of the MTA service, which could act as an enabler to Sender-ID." I gather that there isn't any disagreement about Santronics WinServer and McAfee MxLogic having implementations of RFC 4405. Are there any other SMTP server implementations of RFC 4405, and if so, please provide information which can be used to convince the IETF about that fact? And this text: (ii) "An unknown number of clients implement it; although there is substantial activity showing its use in logs, it is unclear whether these are separate implementations" The above mentions "an unknown number of clients implement it". Are there any other (excluding the names mentioned above) SMTP client implementations of RFC 4405? And this text: (iii) "by legitimate senders, or merely instances of distributed automated malware seeking to improve their odds of reaching the end user." Is the issue about part (i), part (ii), part (iii) or something else? Regards, S. Moonesamy SPFBIS co-chair From msk@cloudmark.com Sat Apr 7 21:47: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 F419F21F85F1 for ; Sat, 7 Apr 2012 21:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+OplWTwpwaO for ; Sat, 7 Apr 2012 21:47:08 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1FB21F85E1 for ; Sat, 7 Apr 2012 21:47:07 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sat, 7 Apr 2012 21:47:07 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] SUBMITTER survey Thread-Index: Ac0UMp4VlpNopD8yRG+QHJ/7seYDvAAQk3OAAAdlpIAAGZI7AAAGxgyAAAnGcgA= Date: Sun, 8 Apr 2012 04:47:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280CDB23@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <20120407004607.GA35694@crankycanuck.ca> <4F8039F2.70606@isdg.net> <6.2.5.6.2.20120407083104.08e464d0@resistor.net> In-Reply-To: <6.2.5.6.2.20120407083104.08e464d0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.203.59.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Apr 2012 04:47:09 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of S Moonesamy > Sent: Saturday, April 07, 2012 9:12 AM > To: spfbis@ietf.org > Cc: Andrew Sullivan > Subject: Re: [spfbis] SUBMITTER survey >=20 > After reading the messages on this thread, it seems that the discussion > is about the following text in draft-ietf-spfbis-experiment-00: >=20 > (i) "In a survey of numerous MTAs in current or recent use, only two > (Santronics WinServer and McAfee MxLogic) were found to contain > implementations of the SMTP SUBMITTER extension as part of the MTA > service, which could act as an enabler to Sender-ID." >=20 > I gather that there isn't any disagreement about Santronics WinServer > and McAfee MxLogic having implementations of RFC 4405. >=20 > Are there any other SMTP server implementations of RFC 4405, and if so, > please provide information which can be used to convince the IETF about > that fact? To give background on the cited text: I found no others after doing searches online for any documentation or disc= ussion of other implementations. I only found out that MxLogic does it fro= m a MAAWG mailing list and WinServer from this list. Three links to other instances of "submitter" were posted to the list earli= er, but they were red herrings: One used "submitter" to talk about the SMTP= AUTH identity, one used it to refer to a component of a mass mail system t= hat basically acted as an MSA, and one was a software module for submitting= homework (i.e., it was courseware, and had nothing at all to do with email= ). Thus, they aren't considered for the experiment report. The survey being run right now has so far polled 19,553 distinct MTAs (of t= he million-plus domains it will check, it's going in alphabetical order and= has only gone as far as "ag*" at the moment). 774 of those claim SUBMITTE= R as an extension. That's less than 4%. That survey records the MX name that was queried in each instance. Of the = 774 that advertised SUBMITTER, all but 39 were actually MxLogic. The bulk = of the remainder were mx-route.com, which I presume to be something like wh= at MxLogic does. The rest appeared to be unassociated instances of somethi= ng called "mxl_mta". > And this text: >=20 > (ii) "An unknown number of clients implement it; although there is sub= stantial > activity showing its use in logs, it is unclear whether these ar= e > separate implementations" >=20 > The above mentions "an unknown number of clients implement it". Are > there any other (excluding the names mentioned above) SMTP client > implementations of RFC 4405? Actually I didn't find documentation or discussion of a single client imple= mentation that uses it; MxLogic and WinServer are SMTP servers that use it.= The text you cited above is based on Hector's logs that show clients actu= ally using it, so we know they exist. However, unlike SMTP servers, SMTP c= lients don't identify themselves in any interesting ways, so we can't tell = from his logs whether all of them are the same implementation, or all of th= em are unique implementations, or somewhere in between. > And this text: >=20 > (iii) "by legitimate senders, or merely instances of distributed autom= ated > malware seeking to improve their odds of reaching the end user.= " A quick glance over the log Hector provided certainly looked to me a lot li= ke the SUBMITTER parameter was generated rather than being legitimate most = of the time, a lot like what spam bots and other malware do for MAIL FROM. = That made me think that these are mostly spam bots using SUBMITTER as an a= ttempt to do anything to improve their chances of getting to the inbox. =20 I admit that last clause is an educated guess at who, in general, those cli= ents are. We could remove it if we believe it's a problem, as I suspect it= doesn't affect the rest of the document, but I thought it might be of inte= rest to readers. To the point raised about a small number of implementations but a wide net,= I agree that we need our analysis to consider both breadth and depth of im= plementation (i.e., number of implementations vs. deployment of each), but = I also think we are doing that already. But even if Exchange, sendmail and postfix all had implemented SUBMITTER, t= here's no ignoring the fact that such a small segment of the ecosystem is a= ctually asking for PRA processing which is where SUBMITTER is actually used= . -MSK From vesely@tana.it Sun Apr 8 03:22: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 3722721F8592 for ; Sun, 8 Apr 2012 03:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.566 X-Spam-Level: X-Spam-Status: No, score=-4.566 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw9F7VpETHqt for ; Sun, 8 Apr 2012 03:22:39 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5521F8577 for ; Sun, 8 Apr 2012 03:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333880557; bh=HWYpq9/gK6c6maAwCFlmiaIz1CejcxIjOto/k+Ro21E=; l=1689; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=KXenaNoD8vF2uPaQ45AcUAJkSt84awj6KpDopw8ok2sLqA+/8GwQFkKY0lw2cZZLx FX1yv4xfa7vPk3MJnOk/Hb4E3P49Ip/BQ1Rfc91vSnt7hnhwWuNuY4oVerzRDEOwYT 9w4wadGHE+vIyQYNCE8aaI0vRUrM8Yfs7Kbk4RSQ= 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, 08 Apr 2012 12:22:37 +0200 id 00000000005DC044.000000004F8166ED.00004069 Message-ID: <4F8166EC.20302@tana.it> Date: Sun, 08 Apr 2012 12:22:36 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120406221255.6603.12555.idtracker@ietfa.amsl.com> In-Reply-To: <20120406221255.6603.12555.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120406221255.6603.12555.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] Fwd: I-D Action: draft-ietf-spfbis-experiment-00.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: Sun, 08 Apr 2012 10:22:40 -0000 This is identical to draft-kucherawy-spfbis-experiment-04, but I'm happy to see that we have a WG document now. I take the occasion to say that I find the document interesting, useful, and its conclusions seem fair to me. I'd hope it will remain open as long as possible, so that new data, tests, and surveys can be added to it if they become available, if that doesn't interfere with working on the WG's main document. -------- Original Message -------- From: internet-drafts@ietf.org Date: Fri, 06 Apr 2012 15:12:55 -0700 To: i-d-announce@ietf.org Cc: spfbis@ietf.org Subject: I-D Action: draft-ietf-spfbis-experiment-00.txt 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 : Resolution of The SPF/Sender-ID Experiment Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-00.txt Pages : 9 Date : 2012-04-06 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender-ID, two proposed email authentication protocols. Because of interoperability concerns created by simultaneous use of the two protocols by a receiver, and some concerns with Sender-ID and compatibility with existing standards, the IESG required them to have Experimental status and invited the community to observe their deployments for a period of time, hoping convergence would be possible later. After six years, sufficient experience and evidence have been collected that the experiment thus created can be considered concluded, and a single protocol can be advanced. This memo presents those findings. From dotis@mail-abuse.org Mon Apr 9 11:41: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 0E4B021F87D1 for ; Mon, 9 Apr 2012 11:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKi7I8E-Y9zI for ; Mon, 9 Apr 2012 11:41:10 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 80BD021F87CF for ; Mon, 9 Apr 2012 11:41:09 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 6F69117402A3 for ; Mon, 9 Apr 2012 18:41:03 +0000 (UTC) Message-ID: <4F832D3D.3020007@mail-abuse.org> Date: Mon, 09 Apr 2012 11:41:01 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> In-Reply-To: <4F8029B1.1060102@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:41:11 -0000 On 4/7/12 4:49 AM, Alessandro Vesely wrote: >> > Neither "Mail From" nor "Helo" offers protection from unknown senders, >> > nor is either visible to recipients. Reject messages on SPF "Helo" >> > failures but not "Mail From". Rejecting messages on "Mail From" >> > failure is not compliant with unresolved forwarding conflicts. Lack >> > of compliance incurs support expenses not compensated by claims >> > acceptance goes against a third-party desire to dictate handling that >> > also lessens SMTP delivery integrity. SPF should only require >> > rejection for "Helo" check failures, not for "Mail From". > Except for forwarding, however, the domain part of the mailfrom is a > better authentication token, because it is more meaningful and has an > SPF record more often, than the helo identity. > > The SMTP's bar for the ehlo parameter is implausibly low, due to the > broadness of the context. Raising the bar for the specific case of > forwarding may be more acceptable. Dear Alessandro, Consider http://tools.ietf.org/html/rfc6531 alters this concept of authentication "tokens" where exchange of U-labels rather than A-labels are not properly handled by SPF. Only the EHLO response is limited to use of A-labels. Per RFC5321, the same forwarding procedures first specified in RFC821 only defines forward path modifications where refusal of this accepted practice places a burden on providers where their customers may make upstream modifications in the delivery of their messages. Domains using "-all" against the "Mail From" identity may conflict with explicit and valid desires of recipient without any reasonable solution available. This issue does not exist when applied against the "Helo" identity. Regards, Douglas Otis From hsantos@isdg.net Tue Apr 10 00:27: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 6ED1921F868A for ; Tue, 10 Apr 2012 00:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q5K9dMN4Rj0 for ; Tue, 10 Apr 2012 00:27:44 -0700 (PDT) Received: from secure.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEF621F864E for ; Tue, 10 Apr 2012 00:27:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3652; t=1334042862; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/7IQUK3W+Cpf8BvTH7e1bVmuYgU=; b=Sn+4DfwkqS/uFYSf4k2o 2NFPQWhq0Nwm0Na6mCyaHls6OeAbQI5SvusnFYNnhehAVpUgx+LmQ+bPIv2ZT62U yNZO73EqQH7UX5EN9VnCxw4yqiwswUjNyDj+wPboXIlXk6FJVohX2jaFAGWmLQf7 EikCgdnmFuzUIBUWnL+8BmI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 03:27: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 v6.4.454.1) with ESMTP id 2949693335.23051.2144; Tue, 10 Apr 2012 03:27:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3652; t=1334042545; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=D1gcqgZ ryQ2nwG9z36REhr1eW8h3DpboDARRe60nB1s=; b=CI5rITtVDDnlmsJ6R2H448L piyLfNOkrfUBYFKLxkf7soRvmvb0LLt1UfVErqUcvtBiIMTGhjZlrZbsyLpLSOuz 9u/vbcw5gxvxqCfbPf46QL6BDpwUX+btTcNcEDTU9Z1QZtBAIkIcqtyPKJywatvt T5/YqHo5SxJKCSyQUpqc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 03:22:25 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3548600190.801.4548; Tue, 10 Apr 2012 03:22:24 -0400 Message-ID: <4F83E0CC.7010006@isdg.net> Date: Tue, 10 Apr 2012 03:27:08 -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: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <20120407004607.GA35694@crankycanuck.ca> <4F8039F2.70606@isdg.net> <6.2.5.6.2.20120407083104.08e464d0@resistor.net> In-Reply-To: <6.2.5.6.2.20120407083104.08e464d0@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:27:45 -0000 S Moonesamy wrote: > After reading the messages on this thread, it seems that the discussion > is about the following text in draft-ietf-spfbis-experiment-00: > > [SEE http://www.ietf.org/mail-archive/web/spfbis/current/msg01078.html] > > Is the issue about part (i), part (ii), part (iii) or something else? Yes, Yes, Yes and Yes. Short comment and suggestion. I think the WG should get a better handle of the issue and address the fundamental conflict that existed since day one which started the need for an IETF MARID concluding experiment: The CEP (CallerID Email Policy) XML version of SPF introduction of the payload based 3rd domain identity called the PRA. I propose we stop this slippery slope "Who's Who Usage" measurement and focus on the technical merits of RFC4407 (PRA) as part of the integrated SPF protocol solution to deal with all the transactional domains that may be part of an IP::DOMAIN SPF1.0 vs SPF2.0 domain protection policy. If the SPFBIS group consensus concludes the PRA was technical failure and offered little value to the total integrated SPF framework, the concluding to abandoning it, automatically defines the result of SenderID and SUBMITTER. Optional reading and background: My opinion. One of the main difficulties with this issue is that there are different viewpoints of the SPF Experiment goals and the SPFBIS key cogs charter authoring and goals to "End" the experiment. It was in conflict and error with the integrated deployment of two similar protocols that only differ with one essential idea: The CEP (CallerID Email Policy) XML version of SPF introduction of the payload based 3rd domain identity called the PRA. When CEP was changed to SenderID and the agreement was to allow it to piggy back of the SPF established policy language syntax, including using a XML structure, at the end of the day, the so called "Experiment" was over how two protocols would work together to cover three potential domains to authorized an email sender: - SPF1.0 IP::EHLO/HELO domain (ENVELOPE) IP::MAIL FROM domain (ENVELOPE) - SPF2.0 IP::PRA (PAYLOAD) While I personally had an opinion for the algorithm used to extract the PRA, its need to be supported was not in question, especially one of the top Software company was purposing it was part of the total email use case scenarios and the FTC was very interesting in making it happen for wide adoption. The reason concern was the implementation overhead and hence the RFC4405 SUBMITTER was invented to help address that PRA overhead concern. Now I am being told to believe a SPFBIS effort and interop report that for all intent and purposes implies the PRA was a failure and therefore we are ending SIDF and all receivers can being to drop the support of the SUBMITTER protocol without any repercussions. But its not saying the PRA was a failure. Instead its concluding SUBMITTER is not supported by a majority of MTA out of the box, and when it is supported by the few MTA vendors but in fact enabled by thousands of MTA sites, the high volume of SUBMITTER MTA clients using this MAIL FROM parameter should be ignored as possibly a high volume of "Malware" or wrong type of PRA clients exposing it via SUBMITTER. I just think this is not correct and its considerate of the many engineering considerations that was put all leading up to the conclusion of the past WG and the initiation of multi-protocol integrated SPF framework and IETF experiment. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Tue Apr 10 02:12: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 7A0FD21F8683 for ; Tue, 10 Apr 2012 02:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR2nG84GCftO for ; Tue, 10 Apr 2012 02:12:20 -0700 (PDT) Received: from dkim.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDBF21F8681 for ; Tue, 10 Apr 2012 02:12:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5875; t=1334049128; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=rO1MDUeXJGFdKc3vaYB6GRO75Jg=; b=wyv+ZKjp/LaeBMYhgBp5 vzdjvl0mEZ6XCVtdK/AnP7ikBgeIzp08tUhX8dRniIRIu8Y56oiWOpi+rhfhZkgs QhWDV6avcHxNOhM0vpTfB+nhQkfRxkqfEEHGFpo/I6v7pg7+M0AXXn9kv2GXADmx 5gU+iZ+XeY5w9/UrTOxKgcQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 05:12:08 -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 v6.4.454.1) with ESMTP id 2955958569.23051.4332; Tue, 10 Apr 2012 05:12:07 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5875; t=1334048809; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=Up8KTiC gThEgWYCEDREynqNd6F2U16SE7cRslaHCSqY=; b=S1tO1uoiZpyUFkPXFCxAdpe vuXaplEspBxAmAnBBKG93KZqzD2W5nfKB1NVGxeHIiXleY2dUsYVyAglC41PJxDg o7kRsf/eCbxl0Wu/YpSb1T6jvrUk5IzPqFre1WoyezXl2PUI02+DJwh8WOETdgzp YqM5UqDJCIN3uum2Phdw= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 05:06:49 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3554864846.806.5372; Tue, 10 Apr 2012 05:06:48 -0400 Message-ID: <4F83F944.1000106@isdg.net> Date: Tue, 10 Apr 2012 05:11:32 -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: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <20120407004607.GA35694@crankycanuck.ca> <4F8039F2.70606@isdg.net> <6.2.5.6.2.20120407083104.08e464d0@resistor.net> <9452079D1A51524AA5749AD23E0039280CDB23@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280CDB23@exch-mbx901.corp.cloudmark.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] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:12:21 -0000 Hi, I don't know where to begin but I think the effort is not correct from many angles. But I do believe we can remedy the situation with a valid WG review of whether part of the 2006 IETF experiment question regarding the PRA is something the SPFBIS can finally decide on. Its a waste of time trying to justify lack of usage and hope on leveraging the "IETF consensus" to ram down a predetermine goal. The report is not providing convincing reasons why SUBMITTER should be dropped and no longer supported by receivers. I think the "experiment" conclusion regarding SIDF needs to be based on the value of the RFC4407 (PRA). If the WG believes this part of the consolidated SPF consolidations is no longer important from an email security-based use case standpoint as proposed by Microsoft, then that would automatically put an end to 4405, 4406 and 4407. However, if the WG is not ready to make that decision, then in my view, the WG should not be making any determination on these protocols based on usage. It should just focus on 4408 and no more, making no INTEROP report on 4405, 4406 and 4407. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of S Moonesamy >> Sent: Saturday, April 07, 2012 9:12 AM >> To: spfbis@ietf.org >> Cc: Andrew Sullivan >> Subject: Re: [spfbis] SUBMITTER survey >> >> After reading the messages on this thread, it seems that the discussion >> is about the following text in draft-ietf-spfbis-experiment-00: >> >> (i) "In a survey of numerous MTAs in current or recent use, only two >> (Santronics WinServer and McAfee MxLogic) were found to contain >> implementations of the SMTP SUBMITTER extension as part of the MTA >> service, which could act as an enabler to Sender-ID." >> >> I gather that there isn't any disagreement about Santronics WinServer >> and McAfee MxLogic having implementations of RFC 4405. >> >> Are there any other SMTP server implementations of RFC 4405, and if so, >> please provide information which can be used to convince the IETF about >> that fact? > > To give background on the cited text: > > I found no others after doing searches online for any documentation or discussion of other implementations. I only found out that MxLogic does it from a MAAWG mailing list and WinServer from this list. > > Three links to other instances of "submitter" were posted to the list earlier, but they were red herrings: One used "submitter" to talk about the SMTP AUTH identity, one used it to refer to a component of a mass mail system that basically acted as an MSA, and one was a software module for submitting homework (i.e., it was courseware, and had nothing at all to do with email). Thus, they aren't considered for the experiment report. > > The survey being run right now has so far polled 19,553 distinct MTAs (of the million-plus domains it will check, it's going in alphabetical order and has only gone as far as "ag*" at the moment). 774 of those claim SUBMITTER as an extension. That's less than 4%. > > That survey records the MX name that was queried in each instance. Of the 774 that advertised SUBMITTER, all but 39 were actually MxLogic. The bulk of the remainder were mx-route.com, which I presume to be something like what MxLogic does. The rest appeared to be unassociated instances of something called "mxl_mta". > >> And this text: >> >> (ii) "An unknown number of clients implement it; although there is substantial >> activity showing its use in logs, it is unclear whether these are >> separate implementations" >> >> The above mentions "an unknown number of clients implement it". Are >> there any other (excluding the names mentioned above) SMTP client >> implementations of RFC 4405? > > Actually I didn't find documentation or discussion of a single client implementation that uses it; MxLogic and WinServer are SMTP servers that use it. The text you cited above is based on Hector's logs that show clients actually using it, so we know they exist. However, unlike SMTP servers, SMTP clients don't identify themselves in any interesting ways, so we can't tell from his logs whether all of them are the same implementation, or all of them are unique implementations, or somewhere in between. > >> And this text: >> >> (iii) "by legitimate senders, or merely instances of distributed automated >> malware seeking to improve their odds of reaching the end user." > > A quick glance over the log Hector provided certainly looked to me a lot like the SUBMITTER parameter was generated rather than being legitimate most of the time, a lot like what spam bots and other malware do for MAIL FROM. That made me think that these are mostly spam bots using SUBMITTER as an attempt to do anything to improve their chances of getting to the inbox. > > I admit that last clause is an educated guess at who, in general, those clients are. We could remove it if we believe it's a problem, as I suspect it doesn't affect the rest of the document, but I thought it might be of interest to readers. > > To the point raised about a small number of implementations but a wide net, I agree that we need our analysis to consider both breadth and depth of implementation (i.e., number of implementations vs. deployment of each), but I also think we are doing that already. > > But even if Exchange, sendmail and postfix all had implemented SUBMITTER, there's no ignoring the fact that such a small segment of the ecosystem is actually asking for PRA processing which is where SUBMITTER is actually used. > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From vesely@tana.it Tue Apr 10 02:27: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 E446821F8661 for ; Tue, 10 Apr 2012 02:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.574 X-Spam-Level: X-Spam-Status: No, score=-4.574 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSvc2PLmT3Sc for ; Tue, 10 Apr 2012 02:27:07 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE7C21F85B9 for ; Tue, 10 Apr 2012 02:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334050025; bh=gOgaNlp+t6STspJ1VSbGjZgHGzKa3ES73OUhAOhnFsc=; l=2247; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BkybFhgymW1s8e0q39ho+af16yZC+syYszh0M38FzE8Zw1byBi/ErHLdsz0RwlH8M IYqFMSpTEaHNqo4nFnWK7bxJzq4bJI9HdbQb4Lz6i3fPcXOPl+geStgB3Y5DD2eTSg 6D8luOpV+8QUD9M/RCZ1B4p9kKSQeW2vlfkmSY1Y= 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, 10 Apr 2012 11:27:05 +0200 id 00000000005DC045.000000004F83FCE9.00003AB1 Message-ID: <4F83FCE8.7050206@tana.it> Date: Tue, 10 Apr 2012 11:27:04 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> In-Reply-To: <4F832D3D.3020007@mail-abuse.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:27:12 -0000 On Tue 10/Apr/2012 10:44:53 +0200 Douglas Otis wrote: > On 4/7/12 4:49 AM, Alessandro Vesely wrote: >> >>> SPF should only require rejection for "Helo" check failures, >>> not for "Mail From". >> >> Except for forwarding, however, the domain part of the mailfrom is a >> better authentication token, because it is more meaningful and has an >> SPF record more often, than the helo identity. >> >> The SMTP's bar for the ehlo parameter is implausibly low, due to the >> broadness of the context. Raising the bar for the specific case of >> forwarding may be more acceptable. > > Consider http://tools.ietf.org/html/rfc6531 alters this concept of > authentication "tokens" where exchange of U-labels rather than > A-labels are not properly handled by SPF. IMHO, SPF should be compatible with EAI, I'll write a separate message about this. > Only the EHLO response is limited to use of A-labels. In the "Domain / address-literal" part that may make an helo id, the "Domain" can be an U-label when the server supports SMTPUTF8. > Per RFC5321, the same forwarding procedures first specified in > RFC821 only defines forward path modifications where refusal of > this accepted practice places a burden on providers where their > customers may make upstream modifications in the delivery of their > messages. > Domains using "-all" against the "Mail From" identity may conflict > with explicit and valid desires of recipient without any reasonable > solution available. This issue does not exist when applied against > the "Helo" identity. Correct. However, the publishing domain cannot specify which identity -all is meant to be applied against. At verifying time, two possibly different result are obtained, and reflected in their own stanzas of Received-SPF or Authentication-Results. The accept-vs-reject decision that we're talking about appears to be the only one place where the two results are merged. Your reasoning is also supported by Postel's principle. The only interpretation that supports reject-on-mailfrom-fail is the fact that, due to its somewhat reduced significance, checking the helo identity is not mandated. This may seem a conceptual error similar to the RR-type mismatch. From vesely@tana.it Tue Apr 10 02:27: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 9237521F85B9 for ; Tue, 10 Apr 2012 02:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.582 X-Spam-Level: X-Spam-Status: No, score=-4.582 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26LSsoiVZuWt for ; Tue, 10 Apr 2012 02:27:22 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E26D521F8683 for ; Tue, 10 Apr 2012 02:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334050041; bh=PX6hx/IYLElpFRYcDS3cqZDRjR1u/WHAO/WYZYvRrxs=; l=677; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=ZUCxqZIiTgkLKlby5E4oHHXBiRgElVcmF28lF2qacGwZ23RNPZ+CA9SbjWqLcmOcQ sIyxDXJTKcm8BfR9H5zLPUd9PdLA49GIPq4wZFoUn0QwgrT/5A25bkvBecNPqFgIWl AOxs9T8jhAoo+5bdR2xCQtgESG7RHdTrq1RZXz+4= 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, 10 Apr 2012 11:27:21 +0200 id 00000000005DC045.000000004F83FCF9.00003ADD Message-ID: <4F83FCF8.6030901@tana.it> Date: Tue, 10 Apr 2012 11:27:20 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:27:26 -0000 Chairs, all: Last year Frank wrote I'm willing to update or rewrite the SPF-EAI draft if somebody plans to implement it. I intend to revive the SPF options draft when and if I feel that it helps for SPF "modifier registry" or "scope" discussions. http://www.ietf.org/mail-archive/web/spfbis/current/msg00012.html He was referring to the active I-D http://tools.ietf.org/html/draft-ellermann-spf-eai I couldn't find an issue on the datatracker for SPF-EAI. Is there one? Unfortunately, Frank suddenly disappears from the Internet every now and then. I guess that's why he missed to signal that issue at the proper time for it. Do we add it now? TIA From hsantos@isdg.net Tue Apr 10 02:38: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 77CA521F8721 for ; Tue, 10 Apr 2012 02:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FdgKUGuxXOF for ; Tue, 10 Apr 2012 02:38:46 -0700 (PDT) Received: from dkim.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 97F6121F8720 for ; Tue, 10 Apr 2012 02:38:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2229; t=1334050723; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=SIX4TN4BpqPxkp1sl8+HtrKMDvE=; b=qliWsDDsA6IcYiqWRchm 0nc5ozYeG3E7hlvoBtVEWSxfUrho/opBhKoAdx734Lnl6gcItjIeUgXXqqpC8v7S KFOiQUJUZFUA/lxfZ6SFKyAol9lANAeNCDmzMb3P46BEpWwZRSaMCgBO2zuktThX ICcsFoDOB/Ny73U7NIF4Po0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 05:38:43 -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 v6.4.454.1) with ESMTP id 2957553789.23051.5476; Tue, 10 Apr 2012 05:38:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2229; t=1334050407; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=eetAFgF piPK0RN8qRgJnhJhYeW7BjRdoYvtrkSvETAo=; b=v8httNgxiTmq/ihEb8d1UQM WnT5pys8K1Ayt+UI9kI1S51I26WzTED77UOa3uMrXJLSYTltBhusN67iZjaE4+Jf 9F5CeeP1h5Wi2Qs+cufUEDcMDWttOUH8MW+RPW22CFc9yv5BJ2gUcKpcrtFIvGbB eOs/1jz0A00yiglibvlA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 05:33:27 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3556462518.808.5936; Tue, 10 Apr 2012 05:33:26 -0400 Message-ID: <4F83FF82.9070902@isdg.net> Date: Tue, 10 Apr 2012 05:38:10 -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: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> In-Reply-To: <4F832D3D.3020007@mail-abuse.org> 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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:38:47 -0000 Douglas Otis wrote: >> The SMTP's bar for the ehlo parameter is implausibly low, due to the >> broadness of the context. Raising the bar for the specific case of >> forwarding may be more acceptable. > Dear Alessandro, > > Consider http://tools.ietf.org/html/rfc6531 alters this concept of > authentication "tokens" where exchange of U-labels rather than A-labels > are not properly handled by SPF. Only the EHLO response is limited to > use of A-labels. Per RFC5321, the same forwarding procedures first > specified in RFC821 only defines forward path modifications where > refusal of this accepted practice places a burden on providers where > their customers may make upstream modifications in the delivery of their > messages. Domains using "-all" against the "Mail From" identity may > conflict with explicit and valid desires of recipient without any > reasonable solution available. This issue does not exist when applied > against the "Helo" identity. It submit it does when the expectation is a 100% hop to hop chain of trust and the criteria is not always satisfied. The basic problem as I view is the receiver making matters worst by disputing domain policies. I suggest that you will have a lower benefit by not honoring domain policies by second guessing them, in fact, you may realize a greater attraction of attackers because of the continued weaker relaxed provisions the receiver offers to attackers. The domain with -ALL main interest in protecting that MDA expected transaction. What the MDA does beyond that initial protection is not defined by SPf should of recommending a lower strength policy for domains not aware of their domain usage and outbound activity. I continue to believe that anything short of a hardfail is an extremely hight DNS waste on the network especially when you look at the high volume of NXDOMAIN that still exist. In addition, the Hardfail policy offers a solution to mitigating the high abusive of legacy bad guys that don't hat to do anything but continue to spoof the domain. Only a strong policy can protect against legacy abuse of spoofers. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From sm@elandsys.com Tue Apr 10 02:58: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 A052821F876C for ; Tue, 10 Apr 2012 02:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh8j-VlGkSUL for ; Tue, 10 Apr 2012 02:58:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5159D21F864B for ; Tue, 10 Apr 2012 02:58:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.129]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3A9wckt017766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 02:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334051932; i=@elandsys.com; bh=0SUnMXMvS/sZ7mgcgTlZbJgRAbNetKOuOKHHqlLULJI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g8cZsiZG5rN6z0gkl5PV61/YAgJf2PTyoo7vN6v9hN/as0PipssZzRtIq1ZC/1IBy 06fMLjFZogXXkb/pOVVqySbJf/5D0HjisYaBKHQxSZbcgA64fJgn82TlWF8MK/OhFE 05iDl0+eY3jMFXCNxQx4MWmsVcLQLnQTiKWbR1SY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334051932; i=@elandsys.com; bh=0SUnMXMvS/sZ7mgcgTlZbJgRAbNetKOuOKHHqlLULJI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CSTNpHpbXbFp5XfM1JjAg9bUxpR2NUYrcOHEDFYk7jP4SpjfJ6zA6WqRuCIoQ7Bcj qI1QIqLICbcv5aSkVHeoxNYlG3OfkJhVjunHd4fGy+jUrBwPMhPmrIWyR4Wkxjh8/W wHVnZuqBuGFp/1ShCmNv9FGXpSrOuqJJ2IzejBEw= Message-Id: <6.2.5.6.2.20120410023044.0b25c520@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 02:37:21 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4F83FCF8.6030901@tana.it> References: <4F83FCF8.6030901@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:58:57 -0000 Hi Alessandro, At 02:27 10-04-2012, Alessandro Vesely wrote: >I couldn't find an issue on the datatracker for SPF-EAI. Is there >one? Unfortunately, Frank suddenly disappears from the Internet every >now and then. I guess that's why he missed to signal that issue at >the proper time for it. Do we add it now? No, it's better not to add more drafts for now. Regards, S. Moonesamy SPFBIS co-chair From hsantos@isdg.net Tue Apr 10 03:05: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 DFB3221F883F for ; Tue, 10 Apr 2012 03:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgxDXw3ILMN5 for ; Tue, 10 Apr 2012 03:05:39 -0700 (PDT) Received: from dkim.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D939F21F882E for ; Tue, 10 Apr 2012 03:05:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1471; t=1334052328; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=GmtZ9y3K77UczDX0VYTEYB2CDro=; b=vhw4oXNNp+tYUG486KGn GvNJkl9y30b0clnIym4WbxQtlj/NmOd2ihbju3ATAR65RG3zJxyc9/j7LwWY8Lvm IQY+2AJcu2q2hCWFndKTn/Dv4AbIwah8KW7ZhoVKauUZn4U4LfzGbWdlthPvlO8E k4gkaindmEv1avj8kM53nV4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 06:05:28 -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 v6.4.454.1) with ESMTP id 2959158945.23051.1468; Tue, 10 Apr 2012 06:05:27 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1471; t=1334052011; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=28xQ6f4 Xnoh7kYBZdTFAEC3tnWenuNIP0T/IKp6NTPY=; b=oqAUsz+jgXGgVqKSlgcSRc7 xjflXeRNHW1ROMXWuL+FQSTG2rvi4sx8Ewn/NOWOaGEEFwuqrsVRgBV6fLziKNuh PYhoHjqBc+2TpySyeN0raWcQkbJOgKP6uN46Lep7EMWiNGjjUTn5m4c6G3ZeOret uG74m9UXJJL9FgqdfbmQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 06:00:11 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3558067377.813.7804; Tue, 10 Apr 2012 06:00:11 -0400 Message-ID: <4F8405C7.6070803@isdg.net> Date: Tue, 10 Apr 2012 06:04:55 -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: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> In-Reply-To: <4F83FCE8.7050206@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:05:40 -0000 Alessandro Vesely wrote: >> Domains using "-all" against the "Mail From" identity may conflict >> with explicit and valid desires of recipient without any reasonable >> solution available. This issue does not exist when applied against >> the "Helo" identity. > > Correct. However, the publishing domain cannot specify which identity > -all is meant to be applied against. At verifying time, two possibly > different result are obtained, and reflected in their own stanzas of > Received-SPF or Authentication-Results. The accept-vs-reject decision > that we're talking about appears to be the only one place where the > two results are merged. > > Your reasoning is also supported by Postel's principle. The only > interpretation that supports reject-on-mailfrom-fail is the fact that, > due to its somewhat reduced significance, checking the helo identity > is not mandated. This may seem a conceptual error similar to the > RR-type mismatch. Let me ask this question: What is more important, protecting the remote domains or your own local domains? To me, that is on-par with the Postel's principle, which fundamentally in general has always suggested you can only confidently protect your own domains first and what you know to be 100% true all the time, everything else come second. Does it matter what EHLO/HELO, MAIL FROM is if RCPT TO fails? -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From vesely@tana.it Tue Apr 10 03: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 4D08321F873B for ; Tue, 10 Apr 2012 03:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.588 X-Spam-Level: X-Spam-Status: No, score=-4.588 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grsOJGILEH6X for ; Tue, 10 Apr 2012 03:34:09 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3C44F21F8665 for ; Tue, 10 Apr 2012 03:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334054048; bh=kcLd7GnPWVJOy9XXGbfUIEI2ia3JcAQulxXJnsoOMH4=; l=635; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hi2EqZdWSNOIXAH3CxALDGvWPGfoN02MTPHhkDh1uEdgyYntb6FzGw8HNKTCWKyFR pZwZbFNJHgfgpmx0jCxcXLLC+ytLy4YUvkjZfzCp8iH9wsqSfZhWk5V6UZ6Xn692xY yrzrGBY/zzRkoEfn/bIG5CniDqzkroum+i13HOg8= 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, 10 Apr 2012 12:34:08 +0200 id 00000000005DC045.000000004F840CA0.00004AD8 Message-ID: <4F840C9F.2020406@tana.it> Date: Tue, 10 Apr 2012 12:34:07 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F83FCF8.6030901@tana.it> <6.2.5.6.2.20120410023044.0b25c520@resistor.net> In-Reply-To: <6.2.5.6.2.20120410023044.0b25c520@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:34:10 -0000 Hi SM, On Tue 10/Apr/2012 12:27:45 +0200 S Moonesamy wrote: > At 02:27 10-04-2012, Alessandro Vesely wrote: >> I couldn't find an issue on the datatracker for SPF-EAI. Is there >> one? Unfortunately, Frank suddenly disappears from the Internet every >> now and then. I guess that's why he missed to signal that issue at >> the proper time for it. Do we add it now? > > No, it's better not to add more drafts for now. Yeah, we only got the experiment I-D, as of now. I meant a ticket on the issue tracker, before we forget about EAI again. I thought this issue was already there, but I'm 92% sure it's actually missing. From vesely@tana.it Tue Apr 10 04:25: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 8431F21F8622 for ; Tue, 10 Apr 2012 04:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.694 X-Spam-Level: X-Spam-Status: No, score=-3.694 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgKDiCEYx8os for ; Tue, 10 Apr 2012 04:25:29 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 786F521F8620 for ; Tue, 10 Apr 2012 04:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334057128; bh=oqseXgEmZFCx3enkz4FGDlqpTGL3As1/JtU4ki6fgs4=; l=1820; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cyuHyPe0igJzsaxOtLS1V2ORzoB+Mvg/QwQj48JWdTYcJ8p7SWkd4oIqRFelocNhZ S5aKWRhifA3lhME+xuKlx2WNIgrDBPTgyja48iTgQ58mZVSrsTekoy0pEzntDkAq/v jiAvJbvW46552/l3ijSi/mTtBT5nzhZ27b9/UHik= 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, 10 Apr 2012 13:25:28 +0200 id 00000000005DC045.000000004F8418A8.000057BA Message-ID: <4F8418A8.4070007@tana.it> Date: Tue, 10 Apr 2012 13:25:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> In-Reply-To: <4F8405C7.6070803@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:25:30 -0000 On Tue 10/Apr/2012 13:02:48 +0200 Hector Santos wrote: > Alessandro Vesely wrote: > >>> Domains using "-all" against the "Mail From" identity may conflict >>> with explicit and valid desires of recipient without any reasonable >>> solution available. This issue does not exist when applied against >>> the "Helo" identity. >> >> Correct. However, the publishing domain cannot specify which identity >> -all is meant to be applied against. At verifying time, two possibly >> different result are obtained, and reflected in their own stanzas of >> Received-SPF or Authentication-Results. The accept-vs-reject decision >> that we're talking about appears to be the only one place where the >> two results are merged. >> >> Your reasoning is also supported by Postel's principle. The only >> interpretation that supports reject-on-mailfrom-fail is the fact that, >> due to its somewhat reduced significance, checking the helo identity >> is not mandated. This may seem a conceptual error similar to the >> RR-type mismatch. > > Let me ask this question: > > What is more important, protecting the remote domains or your own > local domains? You don't trust an spf=pass due to smtp.helo, but you would have trusted the same message if the sender had changed the smtp.mailfrom? Given that malicious senders can change any part of the envelope, I don't see why one of its parts would be trustworthier than another. > To me, that is on-par with the Postel's principle, which fundamentally > in general has always suggested you can only confidently protect your > own domains first and what you know to be 100% true all the time, > everything else come second. I meant http://en.wikipedia.org/wiki/Postel%27s_law > Does it matter what EHLO/HELO, MAIL FROM is if RCPT TO fails? No. From hsantos@isdg.net Tue Apr 10 05:04: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 3CBC021F85CD for ; Tue, 10 Apr 2012 05:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ4sdr+RLv31 for ; Tue, 10 Apr 2012 05:04:11 -0700 (PDT) Received: from listserv.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 187BA21F85CC for ; Tue, 10 Apr 2012 05:04:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1293; t=1334059443; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=mGWGXvch7b/NP4RR0SfIeihlBiU=; b=M8pEi7TCJ6uX+q3nlzNR HdSJHoGfv6B1SNcg09O8LtiVOmC/xRncumzdkWnU3FdFFQf6eWJ5EzZ1fJTTU2JQ HuRTOjMkVrybazizrgc1VScrwu7jcfNnQiROY9IXLGx90PlAaijn+4lFT0IiMlYc WOT+MWye4v3d6PH4Lzs5AzI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 08:04: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2966274042.23051.3980; Tue, 10 Apr 2012 08:04:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1293; t=1334059125; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zx+bRLl qjEF+ZqDK/envUNUnsB4brgTT9XQHyT8FMlo=; b=ZEoduUJ49XQuGHmdDuMpqUZ NNIJu/GdyL/npb7H+1WAVDz7HPg8zQV9FiAMVx5sf5Fq7HqY9LjiX9UKARcPgroB zlKx8dCU/hRKrHQJlVFuFm4W01uY6NKll9rgI/jRi/l7hJuqYKHoPyCaWbjUh7qW r8X9nu61Wsns+Xm4LtzE= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 07:58:45 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3565179971.823.3572; Tue, 10 Apr 2012 07:58:43 -0400 Message-ID: <4F84219D.10302@isdg.net> Date: Tue, 10 Apr 2012 08:03:41 -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: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> In-Reply-To: <4F8418A8.4070007@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:04:12 -0000 Alessandro Vesely wrote: > On Tue 10/Apr/2012 13:02:48 +0200 Hector Santos wrote: >> Let me ask this question: >> >> What is more important, protecting the remote domains or your own >> local domains? > > You don't trust an spf=pass due to smtp.helo, but you would have > trusted the same message if the sender had changed the smtp.mailfrom? In the anonymous world, a pass is meaningless, no trust. It is with FAILURE where you get real deterministic value in the anonymous world. Another way is to state that if a pass of one item MUST equal a pass for the other and it would be illogical to have a valid set of PASS and FAIL. So if the premise is such a HELO must be valid, then a mechanism above and beyond SMTP could be useful using detected failure with a higher payoff than passage. Same with MAIL FROM. > Given that malicious senders can change any part of the envelope, I > don't see why one of its parts would be trustworthier than another. Exactly. So looking at one entity usually doesn't tell you the entire story. >> Does it matter what EHLO/HELO, MAIL FROM is if RCPT TO fails? > > No. I think so too. Practically, it offers short-circuiting of DNS overhead. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From ajs@anvilwalrusden.com Tue Apr 10 05:21: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 00FE321F85DB for ; Tue, 10 Apr 2012 05:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCZPDqKK884y for ; Tue, 10 Apr 2012 05:21:30 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D19B121F85D9 for ; Tue, 10 Apr 2012 05:21:26 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id A40381ECB41C for ; Tue, 10 Apr 2012 12:21:25 +0000 (UTC) Date: Tue, 10 Apr 2012 08:21:17 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120410122109.GA37812@mail.yitter.info> References: <9452079D1A51524AA5749AD23E0039280CD27D@exch-mbx901.corp.cloudmark.com> <4F7F5CB3.1030103@isdg.net> <20120407004607.GA35694@crankycanuck.ca> <4F8039F2.70606@isdg.net> <6.2.5.6.2.20120407083104.08e464d0@resistor.net> <9452079D1A51524AA5749AD23E0039280CDB23@exch-mbx901.corp.cloudmark.com> <4F83F944.1000106@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F83F944.1000106@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] SUBMITTER survey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:21:31 -0000 Hector, On Tue, Apr 10, 2012 at 05:11:32AM -0400, Hector Santos wrote: > However, if the WG is not ready to make that decision, then in my > view, the WG should not be making any determination on these > protocols based on usage. It should just focus on 4408 and no > more, making no INTEROP report on 4405, 4406 and 4407. Speaking as co-chair, your view is noted. Thank you for making it abundantly clear. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From vesely@tana.it Tue Apr 10 06:27: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 44BD911E8072 for ; Tue, 10 Apr 2012 06:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.56 X-Spam-Level: X-Spam-Status: No, score=-4.56 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+hQXZ08OJA1 for ; Tue, 10 Apr 2012 06:27:02 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 524C821F8554 for ; Tue, 10 Apr 2012 06:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334064420; bh=r/zPVTafNvSPWci6EMUGg1TVM2uLv7uFs+BTnSyoFTs=; l=1177; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YRAj2qREJ+l2nZl6HnBMw4n4UWCtnOIVodaQHwLrZVSl6z2K/d5CilyG7A14H4TzI Ab0KSv9QBvXc5sfh6LQudqO1/IMaEX3gWkDrwLsrvT3HVAJHUDEWoJpSH5BW4E/S0x oZuuwt7m5QXUwj0gVZw7YhJVlQVL9Soa8bYVe/vs= 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, 10 Apr 2012 15:27:00 +0200 id 00000000005DC046.000000004F843524.00007572 Message-ID: <4F843523.30508@tana.it> Date: Tue, 10 Apr 2012 15:26:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> In-Reply-To: <4F84219D.10302@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:27:03 -0000 On Tue 10/Apr/2012 14:56:18 +0200 Hector Santos wrote: > > In the anonymous world, a pass is meaningless, no trust. I beg to differ. A pass means that a domain claims some responsibility on the SMTP transaction. The receiver might be temporarily unable to assess such domain's trustworthiness. But we believe reputation can be linked to domain names more consistently than IP addresses. That's what domain authentication is all about. > It is with FAILURE where you get real deterministic value in the > anonymous world. Another way is to state that if a pass of one > item MUST equal a pass for the other and it would be illogical to > have a valid set of PASS and FAIL. So if the premise is such a HELO > must be valid, then a mechanism above and beyond SMTP could be > useful using detected failure with a higher payoff than passage. > Same with MAIL FROM. A pass cannot be spoofed, when using an authentication method worth its salt. If you get a pass on the helo identity, which actually requires more setup effort than mailfrom, the difference is most probably due to the nature of SPF being retrofitted to SMTP, rather than integrated into it. From hsantos@isdg.net Tue Apr 10 06:54: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 1111321F85DB for ; Tue, 10 Apr 2012 06:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLPPpB3S2dUd for ; Tue, 10 Apr 2012 06:54:16 -0700 (PDT) Received: from pop3.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE10211E80BE for ; Tue, 10 Apr 2012 06:54:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1232; t=1334066044; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=OjnrHtjTuWj813wHcjdaroKKfnk=; b=q7lzcO1AYZhh9uopSznS qxY686HWWinZMaXw9cXlrfQY/crqSyWPYcs98YGZbD/aCJaSpjW1nANHJMolu8cm q22f3xSv8sngJM/od2zsNhTFCTJA2BXS+h7oaPI08xZNnB2BCxrpbrOX5IalGaAx P2A8n4bifKCb+zoC4ZMLabQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 09:54:04 -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 v6.4.454.1) with ESMTP id 2972874241.23051.2804; Tue, 10 Apr 2012 09:54:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1232; t=1334065723; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nrKXCh4 XhU9j1LW1Lkt4i4pTon4VliGOrBFQTyx9PAA=; b=OCf2/h0UnpKOX4JIw84crSg W3ytVpmdWHaL5tPMC7BS8vEkpXoeKKqBJCc/I1U3jJ4Tgy1j0bc3Em7N8WSIniVs Ru89ohVWFj1A3G7iUH9IqbXN+LRpPYwmSp5Y3Y1G0B3cqbmumUMPt1bfuTdeAXZz I5xFP3dylIlxtuphL7FQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 09:48:43 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3571779346.839.7872; Tue, 10 Apr 2012 09:48:43 -0400 Message-ID: <4F843B65.9030500@isdg.net> Date: Tue, 10 Apr 2012 09:53:41 -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: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> <4F843523.30508@tana.it> In-Reply-To: <4F843523.30508@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:54:17 -0000 Alessandro Vesely wrote: > On Tue 10/Apr/2012 14:56:18 +0200 Hector Santos wrote: >> In the anonymous world, a pass is meaningless, no trust. > > I beg to differ. A pass means that a domain claims some > responsibility on the SMTP transaction. The receiver might be > temporarily unable to assess such domain's trustworthiness. But we > believe reputation can be linked to domain names more consistently > than IP addresses. That's what domain authentication is all about. Well, I am not sure if thats whats its all about. Nevertheless, the only way for this to be theoretically and conceivably true is well, not to be anonymous and I guess you mean a 3rd party trust system where you would be known and not anonymous. Again, key word - ANONYMOUS. And this idea hasn't work and won't work because the "batteries required" market would not be universally persistent and consistent across all receivers. If you can't reach consistent applicability of "Reputation" modeling then you have a security loophole of targeted receiver victims market where the "batteries" are not all the same or are lacking in various market segments. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From pmidge@microsoft.com Tue Apr 10 07:27: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 5376611E80B8 for ; Tue, 10 Apr 2012 07:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFTbCGsAB9Kw for ; Tue, 10 Apr 2012 07:27:21 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAB721F8597 for ; Tue, 10 Apr 2012 07:27:21 -0700 (PDT) Received: from mail160-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 14:27:20 +0000 Received: from mail160-va3 (localhost [127.0.0.1]) by mail160-va3-R.bigfish.com (Postfix) with ESMTP id 79F853E02AF; Tue, 10 Apr 2012 14:27:20 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail160-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail160-va3 (localhost.localdomain [127.0.0.1]) by mail160-va3 (MessageSwitch) id 133406803960598_6879; Tue, 10 Apr 2012 14:27:19 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.254]) by mail160-va3.bigfish.com (Postfix) with ESMTP id F36994A0143; Tue, 10 Apr 2012 14:27:18 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 14:27:17 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.185]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Tue, 10 Apr 2012 14:27:16 +0000 From: Paul Midgen To: Alessandro Vesely , "spfbis@ietf.org" Thread-Topic: [spfbis] Meaning of SPF and domain authentication in general, was #12 Thread-Index: AQHNFx2mMTroLw1QGkepWlhYFROL65aUGtow Date: Tue, 10 Apr 2012 14:27:15 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E20F80227@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> <4F843523.30508@tana.it> In-Reply-To: <4F843523.30508@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:27:22 -0000 I'd submit that robust use of reputation is in practice not about domain or= IP but both. We've been doing IP-based reputation for years very effective= ly using it to partition and group transmitting IPs based on threat level, = how aggressive filtering should be, and so on. The real next-level applicat= ion of it lies in some kind of entity-level correlation of IPs - things lik= e registrar data (e.g. netblocks, ASNs, entity names), domains, and other o= rthogonal grouping methods that allow you to transitively use reputation. To Alessandro's point, being able to segment (at a minimum) a domain's mail= stream using the results of one or more authentication mechanisms is incred= ibly useful. We already know "pass" is most useful as a predicate for aggre= gating results. I'm not entirely certain what the point of this discussion is though, since= reputation is not part of SPFbis, and barring the presentation of incontro= vertible data-based evidence there is no possible way this thread will caus= e major receivers to stop using path authorization and to discontinue deepl= y integrating it into IP and Domain reputation systems, positive identifica= tion feedback UX, and so on. -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Alessandro Vesely Sent: Tuesday, April 10, 2012 6:27 AM To: spfbis@ietf.org Subject: [spfbis] Meaning of SPF and domain authentication in general, was = #12 On Tue 10/Apr/2012 14:56:18 +0200 Hector Santos wrote: >=20 > In the anonymous world, a pass is meaningless, no trust. I beg to differ. A pass means that a domain claims some responsibility on = the SMTP transaction. The receiver might be temporarily unable to assess s= uch domain's trustworthiness. But we believe reputation can be linked to d= omain names more consistently than IP addresses. That's what domain authen= tication is all about. > It is with FAILURE where you get real deterministic value in the=20 > anonymous world. Another way is to state that if a pass of one item=20 > MUST equal a pass for the other and it would be illogical to have a=20 > valid set of PASS and FAIL. So if the premise is such a HELO must be=20 > valid, then a mechanism above and beyond SMTP could be useful using=20 > detected failure with a higher payoff than passage. > Same with MAIL FROM. A pass cannot be spoofed, when using an authentication method worth its sal= t. If you get a pass on the helo identity, which actually requires more se= tup effort than mailfrom, the difference is most probably due to the nature= of SPF being retrofitted to SMTP, rather than integrated into it. _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From sm@elandsys.com Tue Apr 10 07:38: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 0032321F8685 for ; Tue, 10 Apr 2012 07:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-Sx6ONNnVTK for ; Tue, 10 Apr 2012 07:37: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 A89A321F866D for ; Tue, 10 Apr 2012 07:37:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.129]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3AEbex8027253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 07:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334068673; i=@elandsys.com; bh=SUJH2pGVCP6KVAewciqL0TYDEkKDbRLRqejU4bx2n+w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0i5Fq6NEAyIVtJmb/ZppeLjQNMsF5FEDTmYiMiiY0nDuJ2g0+G7DblMkM7WmnDs1h R5qB1jaTYsyjuQmnjJwqbdNr5U3X+Fsk06u0dK0XXe6V60mpFDprmW4P6Expwb4oe+ Oxvamej8OeI4QBvhSbbybIhuBo8lAGC/xjIDS+Z8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334068673; i=@elandsys.com; bh=SUJH2pGVCP6KVAewciqL0TYDEkKDbRLRqejU4bx2n+w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ef03gYbkuAOwt3+B3IjBY3eZgewthkB490y4gd/1jcTHZKVLKgHi1ooVWJ9nFL3Qg Deq9RbCL/3uLlDkREh6JLB0CYoAFwFWuQuG+o8Y4DeFs1RcfkoA0cJSh1/jBaZc1rY vMHuKVz2UNGpCxAyyY+9AlkY4CYNtGX9q2eH+i40= Message-Id: <6.2.5.6.2.20120410064354.0b278e58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 07:29:35 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4F840C9F.2020406@tana.it> References: <4F83FCF8.6030901@tana.it> <6.2.5.6.2.20120410023044.0b25c520@resistor.net> <4F840C9F.2020406@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:38:01 -0000 Hi Alessandro, At 03:34 10-04-2012, Alessandro Vesely wrote: >Yeah, we only got the experiment I-D, as of now. I meant a ticket on >the issue tracker, before we forget about EAI again. I thought this >issue was already there, but I'm 92% sure it's actually missing. Let's assume that you are the chair of this working group. This is what you know: 1. The working group did not have any clue on how to conclude the experiment 2. The working group has an I-D discussing about the conclusion 3. The working group has a document editor for the I-D 4. There are over five working group participants who have committed to work on the I-D If you open a ticket now, there is one more problem to solve. I'll leave it as an option for you, or anyone else, to raise this as an issue if/when there is a working group I-D for 4408bis. Regards, S. Moonesamy SPFBIS WG co-chair P.S. As an individual comment, I am ok if you raise an objection to the above. From hsantos@isdg.net Tue Apr 10 08:33: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 2A68211E810A for ; Tue, 10 Apr 2012 08:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjP3sTZMPeBJ for ; Tue, 10 Apr 2012 08:33:11 -0700 (PDT) Received: from ntbbs.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C8E6111E8104 for ; Tue, 10 Apr 2012 08:33:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3812; t=1334071984; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=YPT24qtrCqVhXVQV8AlD/bqCFhQ=; b=ta7FmT5o5bBOZ5GAhbyN t4xTSqhFr2ZAmAjU1vpk7LnG6YGQaS1bDE/4B6UNjyGMG7YJ49k1N/m2SZxmwpce y/UxwWsKOVuQ4ueIzJXoTAyTyl/movqHnwdyAQQGYuesGdbHw+kMJHmP8i0Fu2sV X8EAnko81fNwyAYhnNKCzH4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 11:33:04 -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 v6.4.454.1) with ESMTP id 2978814385.23051.6128; Tue, 10 Apr 2012 11:33:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3812; t=1334071667; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ZcoCSxx /Te72c6TYZ5I0egclFxhgOoHBh5lDVjGhaM8=; b=k7JAmhNN5+Nv8YV9FbeTGQH c7+43khRHRsK0YLABQ24vSu3/7kL8k3HHGjyFOMaTfom9hXWC5CfTY+z3yUldMPV bAeTSnKrymLg9oXfFpeqcro9Lv9oqH2xJh7wnnybqFOHdb6jZJCHroS7UdkEyjcQ nUNsp03TO72Cj+9kFQDU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 11:27:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3577723315.857.4492; Tue, 10 Apr 2012 11:27:47 -0400 Message-ID: <4F8452A3.8060909@isdg.net> Date: Tue, 10 Apr 2012 11:32: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: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> <4F843523.30508@tana.it> <7F7F36E50398F84DBAF25C9D51732F1E20F80227@TK5EX14MBXC293.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E20F80227@TK5EX14MBXC293.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:33:12 -0000 Hi, My only input is that in the world of *anonymous* transactions where most of the abuse exist, the only thing we have left from a common and universal applicability standpoint is protocol compliancy enforcement and only with the deviation from this expected compliancy can faults be leveraged. The problem with EHLO/HELO SPF checking is that it can't be enforced and therefore legacy "bad guy" adaption can not be expected to occur. In other words, the easiest way for the bad guy to avoid it, is well, by simply not playing the game. Don't use a valid EHLO/HELO domain, use the non-confirmable netbios or undotted string. Don't use IP literal. The only SMTP authorized solution to this is RFC4409 and even then MUAs don't always get it right and the MSA may have to delay its enforcement until the ESMTP AUTH required state is reached. Increasingly, MUA are behinds SOHO/Home tier with NAT environments where the connecting IP will not match the MSA/MUA exposed EHLO/HELO in any way. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com Paul Midgen wrote: > I'd submit that robust use of reputation is in practice not about domain or IP but both. We've been doing IP-based reputation for years very effectively using it to partition and group transmitting IPs based on threat level, how aggressive filtering should be, and so on. The real next-level application of it lies in some kind of entity-level correlation of IPs - things like registrar data (e.g. netblocks, ASNs, entity names), domains, and other orthogonal grouping methods that allow you to transitively use reputation. > > To Alessandro's point, being able to segment (at a minimum) a domain's mailstream using the results of one or more authentication mechanisms is incredibly useful. We already know "pass" is most useful as a predicate for aggregating results. > > I'm not entirely certain what the point of this discussion is though, since reputation is not part of SPFbis, and barring the presentation of incontrovertible data-based evidence there is no possible way this thread will cause major receivers to stop using path authorization and to discontinue deeply integrating it into IP and Domain reputation systems, positive identification feedback UX, and so on. > > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Alessandro Vesely > Sent: Tuesday, April 10, 2012 6:27 AM > To: spfbis@ietf.org > Subject: [spfbis] Meaning of SPF and domain authentication in general, was #12 > > On Tue 10/Apr/2012 14:56:18 +0200 Hector Santos wrote: >> In the anonymous world, a pass is meaningless, no trust. > > I beg to differ. A pass means that a domain claims some responsibility on the SMTP transaction. The receiver might be temporarily unable to assess such domain's trustworthiness. But we believe reputation can be linked to domain names more consistently than IP addresses. That's what domain authentication is all about. > >> It is with FAILURE where you get real deterministic value in the >> anonymous world. Another way is to state that if a pass of one item >> MUST equal a pass for the other and it would be illogical to have a >> valid set of PASS and FAIL. So if the premise is such a HELO must be >> valid, then a mechanism above and beyond SMTP could be useful using >> detected failure with a higher payoff than passage. >> Same with MAIL FROM. > > A pass cannot be spoofed, when using an authentication method worth its salt. If you get a pass on the helo identity, which actually requires more setup effort than mailfrom, the difference is most probably due to the nature of SPF being retrofitted to SMTP, rather than integrated into it. > _______________________________________________ From sm@elandsys.com Tue Apr 10 08:56: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 21B7421F8554 for ; Tue, 10 Apr 2012 08:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIRi+E3OFjCW for ; Tue, 10 Apr 2012 08:56: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 5470921F854F for ; Tue, 10 Apr 2012 08:56:38 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.129]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3AFuOnn010785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 08:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334073397; i=@elandsys.com; bh=TtCbdorXJllXsdp6Y5eaO3qrG5TvDEpqUkEor8ywD+8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tX6un/MD3lJGftpDyNHu843XOnT793/CNyCjPjIZRgGuR8mgJdCSid5NcHsAX3dLA hZ2D6URbQ7i5NLFhIYud/audwOV6gMu7jvN93uZzFX4P7FceBuxRFxdjHXlyA9vDZn amOWzYO/PCsiVoxwQo8jk737qJXz7pMlwBlwCZ0s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334073397; i=@elandsys.com; bh=TtCbdorXJllXsdp6Y5eaO3qrG5TvDEpqUkEor8ywD+8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LZohjSNMJJG7u14aUjuTBc8YDGZBVVpyENWgVxpHWUFe2y0ItBu7wVariMslsp6cg Trw9i3Enn/c1KEK2IwsA5gMO3vamspYURrUyKI3cPs7aDhznfeXZG01hlc7nFlzZ6G IHqAWxFF03jBd/IGWL+yyNpSQvrHvJHH+avc9dXo= Message-Id: <6.2.5.6.2.20120410083555.07d72540@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 08:56:17 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4F840C9F.2020406@tana.it> References: <4F83FCF8.6030901@tana.it> <6.2.5.6.2.20120410023044.0b25c520@resistor.net> <4F840C9F.2020406@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:56:41 -0000 Hi Alessandro, At 03:34 10-04-2012, Alessandro Vesely wrote: >Yeah, we only got the experiment I-D, as of now. I meant a ticket on >the issue tracker, before we forget about EAI again. I thought this >issue was already there, but I'm 92% sure it's actually missing. My co-chair performed a sanity check on the message I posted today ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01096.html ). It makes sense to open a ticket (#28) based on the message you posted at http://www.ietf.org/mail-archive/web/spfbis/current/msg01085.html Regards, S. Moonesamy SPFBIS WG co-chair From vesely@tana.it Tue Apr 10 10:37: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 0C30111E80DF for ; Tue, 10 Apr 2012 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.567 X-Spam-Level: X-Spam-Status: No, score=-4.567 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvI6bJauO2eQ for ; Tue, 10 Apr 2012 10:37:49 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1D40F21F8682 for ; Tue, 10 Apr 2012 10:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334079466; bh=nDLygY2jCzDIqnLdspBSCac/cWNBlAj98ZwMkZxTG3s=; l=285; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OiIa1Q+LWYMzZ4ilRk2HU/RBQ3+kfhNuytyTiFeBMyPkK9HOIgY0GBxLAmqUt1+rW rmPJTo3kT4Fpf97o9s7StGCxPsmTEGfr8U52BHcQiJyYqKjN7kkCKgf6JsG8uqtKUb tVZTP5/IBqfhmqNra11pK/PhE1gCAXGj+YgaxXLs= 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, 10 Apr 2012 19:37:46 +0200 id 00000000005DC044.000000004F846FEA.00003366 Message-ID: <4F846FE9.6040402@tana.it> Date: Tue, 10 Apr 2012 19:37:45 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F83FCF8.6030901@tana.it> <6.2.5.6.2.20120410023044.0b25c520@resistor.net> <4F840C9F.2020406@tana.it> <6.2.5.6.2.20120410083555.07d72540@resistor.net> In-Reply-To: <6.2.5.6.2.20120410083555.07d72540@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:37:51 -0000 On Tue 10/Apr/2012 19:35:24 +0200 S Moonesamy wrote: > > It makes sense to open a ticket (#28) based on the message you posted > at http://www.ietf.org/mail-archive/web/spfbis/current/msg01085.html Thank you so much for that, also on behalf of Frank (as far as I can guess...) From spf2@kitterman.com Tue Apr 10 14:30: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 BF05121F85D4 for ; Tue, 10 Apr 2012 14:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dFBbxTqaDOs for ; Tue, 10 Apr 2012 14:30:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A1C1B21F85D0 for ; Tue, 10 Apr 2012 14:30:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A96B820E4099; Tue, 10 Apr 2012 17:30:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334093424; bh=oUyOuRb4Ai3YMMWAoc7jwIZVcWArZeFbxVAd967yEXA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=O0uVtKN0goWig9zmHuFzb3gP1FNQDfEAGe/Djm11tkMfLwBDMxtFu2NJO9+9SWgWg T09FyPG9iscAQx3oiFUToIQCC0ZgEr4LFuLdqz0BNVI19233LeOKUFmoKLnpfbsSGm G2t4vJq4MPRffP3znSrbi3HRLCa2Jkbt0L+uaYs4= Received: from scott-latitude-e6320.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 ESMTPSA id 9033E20E4064; Tue, 10 Apr 2012 17:30:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Apr 2012 17:30:24 -0400 Message-ID: <3678680.VmTt9c0jeu@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-22-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F83FCE8.7050206@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:30:27 -0000 On Tuesday, April 10, 2012 11:27:04 AM Alessandro Vesely wrote: ... > Your reasoning is also supported by Postel's principle. ... That was a principle for a different age. While it is still useful in some cases it is not generally applicable. It is certainly not applicable in trying to determine what mail to accept. Scott K From dotis@mail-abuse.org Tue Apr 10 14:32: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 A865F21F8663 for ; Tue, 10 Apr 2012 14:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPnIli+BRnnY for ; Tue, 10 Apr 2012 14:32:55 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id AD7AE21F8633 for ; Tue, 10 Apr 2012 14:32:55 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 47445174050B for ; Tue, 10 Apr 2012 21:32:55 +0000 (UTC) Message-ID: <4F84A706.7090700@mail-abuse.org> Date: Tue, 10 Apr 2012 14:32:54 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> <4F843523.30508@tana.it> <7F7F36E50398F84DBAF25C9D51732F1E20F80227@TK5EX14MBXC293.redmond.corp.microsoft.com> <4F8452A3.8060909@isdg.net> In-Reply-To: <4F8452A3.8060909@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:32:56 -0000 On 4/10/12 8:32 AM, Hector Santos wrote: > My only input is that in the world of *anonymous* transactions where > most of the abuse exist, the only thing we have left from a common > and universal applicability standpoint is protocol compliancy > enforcement and only with the deviation from this expected compliancy > can faults be leveraged. > > The problem with EHLO/HELO SPF checking is that it can't be enforced > and therefore legacy "bad guy" adaption can not be expected to occur. > In other words, the easiest way for the bad guy to avoid it, is well, > by simply not playing the game. Don't use a valid EHLO/HELO domain, > use the non-confirmable netbios or undotted string. Don't use IP > literal. The only SMTP authorized solution to this is RFC4409 and > even then MUAs don't always get it right and the MSA may have to > delay its enforcement until the ESMTP AUTH required state is reached. > Increasingly, MUA are behinds SOHO/Home tier with NAT environments > where the connecting IP will not match the MSA/MUA exposed EHLO/HELO > in any way. Dear Hector, Thousands of new domains are registered daily. See: http://www.domaintools.com/internet-statistics/ It does not matter whether a domain is found in a "Mail From" or "Helo" SMTP parameter. When nothing of the domain is known, the decision must be based upon default refusal, especially for domains normally not visible. http://tools.ietf.org/html/rfc6531#section-3.7.1 ,--- When an SMTP connection is opened, the SMTP server sends a "greeting" response consisting of the 220 reply-code and some information. The SMTP client then sends the EHLO command. Since the SMTP client cannot know whether the SMTP server supports SMTPUTF8 until after it receives the response to the EHLO, the SMTPUTF8-aware SMTP client MUST send only ASCII (LDH label or A-label [RFC5890 ]) domains in the EHLO command. If the SMTPUTF8-aware SMTP server provides domain names in the EHLO response, they MUST be in the form of LDH labels or A-labels. '--- Most email today is blocked by IP address reputation. "Helo" permits use of domains to consolidate positive reputations. In addition to RFC1918, which is easily solved by senders, LSN exchanges over 100.64.0.0/10 represents a problem only be resolved by recipients. Inbound MTAs must offer IPv6 addresses or the 100.64.0.0/10 space can not be refused without being disruptive. IP address authorization compliance requires exchanges uniquely identified by route-able IP addresses. Consolidation of reputation for IPv6 is where "Helo" becomes both useful and practical. For all the reasons previously stated, including UTF-8 encoded email addresses, Mail parameters can not be refused without disrupting valid email exchanges. Combining multiple addresses within the From header field using http://tools.ietf.org/html/rfc6541 to authorize use (in conjunction with DKIM) offers a means to visually demonstrate affiliations. This might be for something like From: jon.doe@unknown.domain, unknown.domain@good-standing.reputation-service.domain where the known good-standing.reputation-service.domain authorizes the jon-doe.domain. This approach can only resolve UTF-8 addresses after having been converted to A-labels, but would be a perfect extension for DMARC as well as offering a means to adopt default refusal for unknown domains. Regards, Douglas Otis From msk@cloudmark.com Tue Apr 10 14:43: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 794A821F867A for ; Tue, 10 Apr 2012 14:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+9U-1bXMS5o for ; Tue, 10 Apr 2012 14:43:13 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 997E521F8678 for ; Tue, 10 Apr 2012 14:43:13 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id wMj41i0010ZaKgw01Mj5Rx; Tue, 10 Apr 2012 14:43:05 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Y/Z6Q2iN c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=bq0z3-o-wY0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=A6i4I0diIpbzHeUZ0z0A:9 a=zP6qNOgRzoT25CtUvFgA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=caKFksYWKh3XJM7I:21 a=VyWa0dsg0qMkWYBO:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 14:42:51 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Meaning of SPF and domain authentication in general, was #12 Thread-Index: AQHNFx2mRmlsLLh7AECoB7lS1ViRbJaUlIQw Date: Tue, 10 Apr 2012 21:42:50 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> <4F843523.30508@tana.it> In-Reply-To: <4F843523.30508@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334094185; bh=A3ZUibQeOh8zqEZt/nKlNl+WiuU3pAKGQNTMQZXWQiY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=wzfHYhhh1XjPvfBMIT5FNVv71F7x1lH/hWoa/xM89a2ydi1xNoSyOPP/7UJ7nw9jP fQeag68zVuyRUJAfCXGbNU/gUvMijz4NHmFTpeWKQEl+N6W8mabMqfzRtD60qw1Juc hy+TQVoDCQSXVuDpc9wg+5rHG3ncuoH2sHri9Kxg= Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:43:14 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Tuesday, April 10, 2012 6:27 AM > To: spfbis@ietf.org > Subject: [spfbis] Meaning of SPF and domain authentication in general, wa= s #12 >=20 > I beg to differ. A pass means that a domain claims some responsibility > on the SMTP transaction. The receiver might be temporarily unable to > assess such domain's trustworthiness. But we believe reputation can be > linked to domain names more consistently than IP addresses. That's > what domain authentication is all about. +1. "pass" is the only interesting case in DKIM, as well. -MSK From spf2@kitterman.com Tue Apr 10 15:21: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 329D411E8125 for ; Tue, 10 Apr 2012 15:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZS3OvjUjjRE for ; Tue, 10 Apr 2012 15:21:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 381B011E8119 for ; Tue, 10 Apr 2012 15:21:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 74A9A20E4099; Tue, 10 Apr 2012 18:21:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334096491; bh=008JNaiApyTofeWqoGWP8ouC+WT0B4g0xq/LmvNDcoc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=N/xsnBUsBMKJ+ntq6IpP8qKH3LGb5VvpiSOlnKlYOmtp2bZH756Tdqvh6OOjQU5qR Cp7qAjW5cDRmNSpvBwsmTVNTmcB0i6gkH6Y41zG3YuJwMSuXlVjP6UwHr5y0jMQ25Z 5PDo3BYWkoDeWTufCjFM/CPy/r4TazUEFtnaFUBY= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 55A6F20E4064; Tue, 10 Apr 2012 18:21:31 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Apr 2012 18:21:30 -0400 Message-ID: <13757064.SIaPQFyNoO@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-22-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <4F843523.30508@tana.it> <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:21:34 -0000 On Tuesday, April 10, 2012 09:42:50 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Alessandro Vesely Sent: Tuesday, April 10, 2012 6:27 AM > > To: spfbis@ietf.org > > Subject: [spfbis] Meaning of SPF and domain authentication in general, was > > #12 > > > > I beg to differ. A pass means that a domain claims some responsibility > > on the SMTP transaction. The receiver might be temporarily unable to > > assess such domain's trustworthiness. But we believe reputation can be > > linked to domain names more consistently than IP addresses. That's > > what domain authentication is all about. > > +1. "pass" is the only interesting case in DKIM, as well. I agree that pass is the only interesting case for DKIM. I agree that pass is interesting for SPF. I very much disagree that it's the only interesting case for SPF. My personal experience with having published a -all SPF record for 7 or 8 years (I don't recall when I initially published it) is that it's been a mostly effective deterrent against spammers forging my domain (with the related almost total elimination of backscatter from such mails) with virtually no negative side effects. I find the fail case extremely interesting and unlike DKIM, where there's not integral policy mechanism, it's a core part of SPF to be able to take advantage of it. Scott K P.S. I know there are false positives and not everyone is in a position to publish a -all record as a result. I'm only speaking to my experience. From dotis@mail-abuse.org Tue Apr 10 15:35: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 3B59911E8141 for ; Tue, 10 Apr 2012 15:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em5cNHrWZbhd for ; Tue, 10 Apr 2012 15:35:29 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id AC51A11E8103 for ; Tue, 10 Apr 2012 15:35:29 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 8C79A17404E9 for ; Tue, 10 Apr 2012 22:35:29 +0000 (UTC) Message-ID: <4F84B5A6.2010100@mail-abuse.org> Date: Tue, 10 Apr 2012 15:35:18 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> <4F843523.30508@tana.it> <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:35:30 -0000 On 4/10/12 2:42 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Alessandro Vesely >> Sent: Tuesday, April 10, 2012 6:27 AM >> To: spfbis@ietf.org >> Subject: [spfbis] Meaning of SPF and domain authentication in general, was #12 >> >> I beg to differ. A pass means that a domain claims some responsibility >> on the SMTP transaction. The receiver might be temporarily unable to >> assess such domain's trustworthiness. But we believe reputation can be >> linked to domain names more consistently than IP addresses. That's >> what domain authentication is all about. > +1. "pass" is the only interesting case in DKIM, as well. > Dear Murray, Agreed. However, when the "Mail From" identity references an SPF record, the result only offers an "authorization" not "authentication". Higher levels of assurance would require SPF records to be specifically referenced by the "HELO". Such specificity is simply not possible with SPF semantics. This is also why SPF may not allow domains to defend their reputation. Regards, Douglas Otis P.S. Lack of "Helo" specificity represents a basic departure from- http://tools.ietf.org/html/draft-ietf-marid-csv-csa-02 From hsantos@isdg.net Tue Apr 10 15:58: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 2F5A411E80F4 for ; Tue, 10 Apr 2012 15:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B92mBAdc9aWd for ; Tue, 10 Apr 2012 15:58:52 -0700 (PDT) Received: from ftp.catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1756511E8081 for ; Tue, 10 Apr 2012 15:58:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1171; t=1334098724; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=tr3MFCah4fRpkNmTs8jzpmE4BQE=; b=Ps1RlxxZG5qmsOwHmbYu UzplglkPtSqlB/sKJzM60/5s7Mb0DUA4In7giuxaUTVXjq94YbhFB5BZKOspSpN9 id5MhUuSvGRktgvS/qUvndnxL8j2v1bWImFpmWdhlP5S48aaf2NPDrG/qxvvQheT 2UDCYbu/hWssksiDlm3XROE= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 18:58: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3005554657.23051.4452; Tue, 10 Apr 2012 18:58:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1171; t=1334098407; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=I6sW4RC 92ZZKnKRX5YOVilaem/7iRJqg+sTkimxlHQ4=; b=aFU3Wolvyla+HgkhqpiftS9 EvlpConZ0rmKZXZOyRQU/iUVkmU+pv1io8joUUQ44gH5y3DwQsm6HCleRXTugw9H qinK9exdUhj50255EatNNnNuFlaa0zjUDlTAy0xCWA4uk1s5YG7pRmDJtW3r/P15 1GIzzI+A79hHHCtFtAOc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 18:53:27 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3604463018.889.6508; Tue, 10 Apr 2012 18:53:26 -0400 Message-ID: <4F84BAF1.2040307@isdg.net> Date: Tue, 10 Apr 2012 18:57:53 -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: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> <4F843523.30508@tana.it> <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:58:53 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Alessandro Vesely >> Sent: Tuesday, April 10, 2012 6:27 AM >> To: spfbis@ietf.org >> Subject: [spfbis] Meaning of SPF and domain authentication in general, was #12 >> >> I beg to differ. A pass means that a domain claims some responsibility >> on the SMTP transaction. The receiver might be temporarily unable to >> assess such domain's trustworthiness. But we believe reputation can be >> linked to domain names more consistently than IP addresses. That's >> what domain authentication is all about. > > +1. "pass" is the only interesting case in DKIM, as well. It can easily be argued it was also its peril sans policy based protocol security wrappers. DKIM is not SPF and the comparison is not there. The SPF framework is peppered with rejection guidelines when policy is violated out of the box. This is not DKIM where failures are not promoted to unsigned signature statuses. This "DKIM" mindset MUST not creep into SPFBIS. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Tue Apr 10 16:03: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 6860121F85AC for ; Tue, 10 Apr 2012 16:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QbXxS7+H62d for ; Tue, 10 Apr 2012 16:03:51 -0700 (PDT) Received: from ftp.catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 52E6B21F8597 for ; Tue, 10 Apr 2012 16:03:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1100; t=1334099024; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=/4xUC8mEOrWSlg3LXFhfwGrFr7U=; b=v78KjxWT2L7CDm2IbDsk OmnPB2JiN/l06qi119sBUTorhn4f0M5wrwfWfpZW2m/+W1IQqV2KUIEfEobcdR1r RCi+c5OeYS+cntvesP0xhk8+ZdI7eSCowZmX6zN6NjqKdvezlPGE8IWKhfYTgMfA 9DJwEyTooUKNkNSVq+FUaEA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 19:03: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3005854803.23051.2524; Tue, 10 Apr 2012 19:03:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1100; t=1334098707; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=Y0Usz8D HKfyDuPDa14ShUYGWuK+JwzfG67YiAjs05eQ=; b=HVIBR6fqraZV4uKU+a8IFXk Sj6hElT8u+YwJehT4N/igrBDqWnWtpocDSax5lydwGd2kymtmiDiUdLz455qOlTQ XnObzs3mMIiKxUtSnL7lCixVwaVUXwOJFo3DaHtyBT/aZm71jitDPC7qh9VVx1S0 ZvP/0qMOCsPxF9G3PpgQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 10 Apr 2012 18:58:27 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3604762502.891.3276; Tue, 10 Apr 2012 18:58:26 -0400 Message-ID: <4F84BC1C.8060300@isdg.net> Date: Tue, 10 Apr 2012 19:02:52 -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: <20120324090349.15462.qmail@joyce.lan> <1832269.tsjzSkJokG@scott-latitude-e6320> <4F7F0D52.30405@tana.it> <3193488.lvEsj8R6CO@scott-latitude-e6320> <4F7F6310.6080201@mail-abuse.org> <4F8029B1.1060102@tana.it> <4F832D3D.3020007@mail-abuse.org> <4F83FCE8.7050206@tana.it> <4F8405C7.6070803@isdg.net> <4F8418A8.4070007@tana.it> <4F84219D.10302@isdg.net> <4F843523.30508@tana.it> <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> <4F84BAF1.2040307@isdg.net> In-Reply-To: <4F84BAF1.2040307@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 Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:03:53 -0000 Hector Santos wrote: > Murray S. Kucherawy wrote: >>> -----Original Message----- >>> From: Alessandro Vesely >>> >>> I beg to differ. A pass means that a domain claims some responsibility >>> on the SMTP transaction. The receiver might be temporarily unable to >>> assess such domain's trustworthiness. But we believe reputation can be >>> linked to domain names more consistently than IP addresses. That's >>> what domain authentication is all about. >> >> +1. "pass" is the only interesting case in DKIM, as well. > > It can easily be argued it was also its peril sans policy based protocol > security wrappers. DKIM is not SPF and the comparison is not there. > The SPF framework is peppered with rejection guidelines when policy is > violated out of the box. This is not DKIM where failures are not > promoted to unsigned signature statuses. This "DKIM" mindset MUST not > creep into SPFBIS. That should be: This is not DKIM where failures are promoted to unsigned signature statuses. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Tue Apr 10 16:04: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 29C3111E80F4 for ; Tue, 10 Apr 2012 16:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oavaAx3F-1-9 for ; Tue, 10 Apr 2012 16:04:02 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id A8B8811E80DE for ; Tue, 10 Apr 2012 16:04:02 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id wP421i0020as01C01P425g; Tue, 10 Apr 2012 16:04:02 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=MpDQGhme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=bq0z3-o-wY0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=l97pT1T60LDNTadXwg0A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 16:04:02 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Meaning of SPF and domain authentication in general, was #12 Thread-Index: AQHNFx2mRmlsLLh7AECoB7lS1ViRbJaUlIQwgACDJwD//5X1EA== Date: Tue, 10 Apr 2012 23:03:59 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D27DC@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <4F843523.30508@tana.it> <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> <13757064.SIaPQFyNoO@scott-latitude-e6320> In-Reply-To: <13757064.SIaPQFyNoO@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334099042; bh=z+EpstndxYfPkqzP9Bu2PDhUsWW9tHI2apjhJdGqsWU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=kAruxa3UEfuwogK7chhlshnNo6Brsm/j2/6irrgxLaCeEAdX2bIbtM6oEykpSqNaU tWossmBV8tWi5RFe6gksP+FJz3zPleJXAbK8XnyEqQAnNJOir/s/RkqX7MjAA23Ebc noD1+TGZaOXQ8LnzXubCF5m0UOomeg+uk0f9qjr0= Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:04:03 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, April 10, 2012 3:22 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Meaning of SPF and domain authentication in general= , was #12 >=20 > I find the fail case extremely interesting and unlike DKIM, where > there's not integral policy mechanism, it's a core part of SPF to be > able to take advantage of it. >=20 > Scott K >=20 > P.S. I know there are false positives and not everyone is in a > position to publish a -all record as a result. I'm only speaking to my > experience. Similarly, some places can do ADSP "discardable" and be totally happy with = it. It all depends on how a false negative will impact what you're doing. But specifically in terms of developing reputation on a domain (which is wh= at I was replying to), the "pass" case is the only interesting case for eit= her mechanism. -MSK From spf2@kitterman.com Tue Apr 10 16:06: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 A630021F85A8 for ; Tue, 10 Apr 2012 16:06: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBGwcFWCfAdg for ; Tue, 10 Apr 2012 16:06:18 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F2D9B21F85AC for ; Tue, 10 Apr 2012 16:06:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2592020E4099; Tue, 10 Apr 2012 19:06:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334099176; bh=aP3ujo+0E/miGKcYNJH+MM3yjmGJqsreU7xO/RlqxtE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Y2mr5reSV7tKjKftnP6AbyuAoqBHgzo3xbWqjccp966Yx+6Jj798PQr9NawKgbzW5 3PGO16ekd9jQAXjfYa4nDTYhi5xhKLEBic1/ChFVQBfbfXRLq1PCWtKxfy4mi9vZ4H ijY53c1tl1FsXcEm5lu+5YenqxPOADil2vGIfOig= Received: from scott-latitude-e6320.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 ESMTPSA id 0BF8920E4064; Tue, 10 Apr 2012 19:06:15 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Apr 2012 19:06:15 -0400 Message-ID: <6040139.OxyMbgc6SQ@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-22-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F84B5A6.2010100@mail-abuse.org> References: <20120324090349.15462.qmail@joyce.lan> <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> <4F84B5A6.2010100@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:06:19 -0000 On Tuesday, April 10, 2012 03:35:18 PM Douglas Otis wrote: > On 4/10/12 2:42 PM, Murray S. Kucherawy wrote: > >> -----Original Message----- > >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > >> Of Alessandro Vesely Sent: Tuesday, April 10, 2012 6:27 AM > >> To: spfbis@ietf.org > >> Subject: [spfbis] Meaning of SPF and domain authentication in general, > >> was #12 > >> > >> I beg to differ. A pass means that a domain claims some responsibility > >> on the SMTP transaction. The receiver might be temporarily unable to > >> assess such domain's trustworthiness. But we believe reputation can be > >> linked to domain names more consistently than IP addresses. That's > >> what domain authentication is all about. > > > > +1. "pass" is the only interesting case in DKIM, as well. > > Dear Murray, > > Agreed. However, when the "Mail From" identity references an SPF > record, the result only offers an "authorization" not > "authentication". Higher levels of assurance would require SPF records > to be specifically referenced by the "HELO". Such specificity is simply > not possible with SPF semantics. This is also why SPF may not allow > domains to defend their reputation. > > Regards, > Douglas Otis > > > P.S. Lack of "Helo" specificity represents a basic departure from- > http://tools.ietf.org/html/draft-ietf-marid-csv-csa-02 Your insistence on the distinction between authorized and authenticated making a difference is, in any practical terms, wrong. We shouldn't get wrapped up in it here. I think when RFC 5451 was published the issue was pretty well put to bed and trying to rehash it now is a waste of everyone's time. BTW, it's a difference not a departure. SPF HELO checking is unrelated to CSV. Scott K From spf2@kitterman.com Tue Apr 10 16:08: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 BFEB711E80DE for ; Tue, 10 Apr 2012 16:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec14bAxCmoij for ; Tue, 10 Apr 2012 16:08:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 48DBA11E8081 for ; Tue, 10 Apr 2012 16:08:05 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D088320E4099; Tue, 10 Apr 2012 19:08:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334099284; bh=OShDtVjs+6h9sEmstKs4oWInQ5YASI+FsRqymooO5CE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=qVqYU6Eq6XL5lmubCqxGCIvqVR2E8EQP6ZPEOL1GfAkb0OFLu91CyGnTWksKY16/Z HAW2jqGe3sF33jIuXpBs+qz33E3amlfnUCaPUQVRgyUKSJASTtPUTTDblFObG492fo ZGDRgrC9pZdPZP1Jdpr8V8Opuc/eDUD2xQyLl4Ek= Received: from scott-latitude-e6320.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 ESMTPSA id B3F7B20E4064; Tue, 10 Apr 2012 19:08:04 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Apr 2012 19:08:04 -0400 Message-ID: <2223291.Gx3ANL6thl@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-22-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280D27DC@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <13757064.SIaPQFyNoO@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280D27DC@exch-mbx901.corp.cloudmark.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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:08:05 -0000 On Tuesday, April 10, 2012 11:03:59 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Tuesday, April 10, 2012 3:22 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, > > was #12 > > > > I find the fail case extremely interesting and unlike DKIM, where > > there's not integral policy mechanism, it's a core part of SPF to be > > able to take advantage of it. > > > > Scott K > > > > P.S. I know there are false positives and not everyone is in a > > position to publish a -all record as a result. I'm only speaking to my > > experience. > > Similarly, some places can do ADSP "discardable" and be totally happy with > it. It all depends on how a false negative will impact what you're doing. > > But specifically in terms of developing reputation on a domain (which is > what I was replying to), the "pass" case is the only interesting case for > either mechanism. As an input to a reputation system, I agree, but SPF has an independent utility in the absence of such a system. ADSP is not part of the core DKIM protocol. It's a after the fact bolt-on, so it's a bit different. Scott K From msk@cloudmark.com Tue Apr 10 16:15: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 AFB0111E80DE for ; Tue, 10 Apr 2012 16:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a5UxoTAdUVB for ; Tue, 10 Apr 2012 16:15:49 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA411E8081 for ; Tue, 10 Apr 2012 16:15:49 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id wPFh1i0010ZaKgw01PFh6K; Tue, 10 Apr 2012 16:15:41 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=HuX06jvS c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=bq0z3-o-wY0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=hcHaK51lciA1XOnNxjoA:9 a=1JIk5TgxMv2MF1EwWEsA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::751c:35a8:71a2:8e8]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 16:15:27 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Meaning of SPF and domain authentication in general, was #12 Thread-Index: AQHNFx2mRmlsLLh7AECoB7lS1ViRbJaUlIQwgACDJwD//5X1EIAAdw4A//+LxPA= Date: Tue, 10 Apr 2012 23:15:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D284C@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <13757064.SIaPQFyNoO@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280D27DC@exch-mbx901.corp.cloudmark.com> <2223291.Gx3ANL6thl@scott-latitude-e6320> In-Reply-To: <2223291.Gx3ANL6thl@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334099741; bh=Mi9746ixR34Os8tgFloQlAxW6RBf6eXoUu04vGTSiI4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=iu1Q9m0Lsy80jVgKj1nRwhqNBDQMtBOGrS1piDWq2qB+8xZVJ34lUhjmypCHRHfuU wcy0egMIq3ooaFrBbpcGkYG5Ji4U8FRzpg9EPWbAuwsh1mdedYZCs2XzsvRxq9Q6qX 4WRyI0FznnGW1YSb/QcayZNPS5Q5uKq4eNBpeBqo= Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:15:51 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, April 10, 2012 4:08 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Meaning of SPF and domain authentication in general= , was #12 >=20 > ADSP is not part of the core DKIM protocol. It's a after the fact > bolt-on, so it's a bit different. Other than the fact that they're in separate documents, how are they differ= ent? SPF receivers often elect not to bounce mail that fails SPF checks even wit= h "-all" in the policy, specifically because of the false negatives concern= . Thus, they seem on par to me. -MSK From spf2@kitterman.com Tue Apr 10 16:19: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 0D7B921F85DD for ; Tue, 10 Apr 2012 16:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhVwjE62fPVj for ; Tue, 10 Apr 2012 16:19:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB2E21F85BB for ; Tue, 10 Apr 2012 16:19:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E40FF20E4099; Tue, 10 Apr 2012 19:19:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334099972; bh=ruyqedC/grpRweOm89giwm49DeL/dzf8cfFtynx5QPk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=d5+dCWEcKx9tIIQlwGDBIbEIxrPi6aJ+oCHo5cxyN7CfOhlSyh6ULVg89RiALVDKk aUS7a56MrJTJauVrzQxN+vczgh7zGKX1mNHjyOzVcyZS6jbOHZNgQ/jAMizJWQx+NI nCBlaUwzr3xRaR44HLDcm+wJcqwReNXUVtIhiHQg= Received: from scott-latitude-e6320.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 ESMTPSA id C5C6C20E4064; Tue, 10 Apr 2012 19:19:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Apr 2012 19:19:32 -0400 Message-ID: <1740601.l8OcLQSMQM@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-22-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280D284C@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <2223291.Gx3ANL6thl@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280D284C@exch-mbx901.corp.cloudmark.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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:19:34 -0000 On Tuesday, April 10, 2012 11:15:27 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Tuesday, April 10, 2012 4:08 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, > > was #12 > > > > ADSP is not part of the core DKIM protocol. It's a after the fact > > bolt-on, so it's a bit different. > > Other than the fact that they're in separate documents, how are they > different? > > SPF receivers often elect not to bounce mail that fails SPF checks even with > "-all" in the policy, specifically because of the false negatives concern. > Thus, they seem on par to me. There are certainly similarities, but I think the false positive concern is a lot greater with ADSP. It certainly is for me. From my POV, ADSP is only suitable for a few high profile phishing targets while SPF -all is something that has general utility if one is willing to accept some noise level breakage in fringe cases. Scott K From msk@cloudmark.com Tue Apr 10 16:32: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 E2C5021F86A4 for ; Tue, 10 Apr 2012 16:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRLbbI0cgd3J for ; Tue, 10 Apr 2012 16:32:03 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4678F21F86A3 for ; Tue, 10 Apr 2012 16:32:03 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id wPY21i0010as01C01PY2BM; Tue, 10 Apr 2012 16:32:02 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=MpDQGhme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=bq0z3-o-wY0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=ujkXnqXtybOq4kCMHboA:9 a=lVfLMU5Imr6HIZCSbVYA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::751c:35a8:71a2:8e8]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 16:32:02 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Meaning of SPF and domain authentication in general, was #12 Thread-Index: AQHNFx2mRmlsLLh7AECoB7lS1ViRbJaUlIQwgACDJwD//5X1EIAAdw4A//+LxPCAAHdwAP//jZTw Date: Tue, 10 Apr 2012 23:32:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D28B8@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <2223291.Gx3ANL6thl@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280D284C@exch-mbx901.corp.cloudmark.com> <1740601.l8OcLQSMQM@scott-latitude-e6320> In-Reply-To: <1740601.l8OcLQSMQM@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334100722; bh=2puseKD7qPjliyGaV3kbE81vNMYoL20KyA4yoPIcJ30=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rx7n5Ygq/irTlrUfsmkfGaQUMQHTirZEf9BI8hbI6u/pFpqFXY0BSEppLYxDy3PzY p301PT7aXJdeTMrLum8gwJ4eEwSn4IiAVjCAlvfhW3DliOZqiNLaqCeXvU6abn3d04 ZC4/ms3tkKfNsCOIQNYdRku25iFD/Vizprgkz3S0= Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:32:04 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, April 10, 2012 4:20 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Meaning of SPF and domain authentication in general= , was #12 >=20 > There are certainly similarities, but I think the false positive > concern is a lot greater with ADSP. It certainly is for me. From my > POV, ADSP is only suitable for a few high profile phishing targets > while SPF -all is something that has general utility if one is willing > to accept some noise level breakage in fringe cases. I'm still not seeing the difference. If you publish "-all" then you're cla= iming you have very tight control over the path your email takes to get fro= m you to wherever. Doesn't that also mean DKIM failures are pretty much al= so under your control, or at least your influence? (I think this is interesting, but we may be straying a bit afield for this = WG list. Feel free to drag this to ietf-dkim or spf-discuss if the chairs = slap our wrists.) -MSK From spf2@kitterman.com Tue Apr 10 16:47: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 6A3F221F851E for ; Tue, 10 Apr 2012 16:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ3S+orH7IXq for ; Tue, 10 Apr 2012 16:47:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7663621F84F9 for ; Tue, 10 Apr 2012 16:47:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C0EE320E4099; Tue, 10 Apr 2012 19:47:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334101671; bh=UJiOmKQM/EGbL0Bq3qPiZDBNmkJCbnjItjoz81fiKZU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Bju3kJiqjl3JEQKN/ozMy16UexdAi0pdidsWcvrTMgoKZhH7VpIzAbow0DWtSZPtj voYU7IybouffIz6YC5XMR+tyMcMgcuaYFqRNAzDFjD+293gAtNicinTjgrJGWd5sIG WMO3FHV9KMs8degDjNIdt0HhGgGNyXBgX88+x5qs= Received: from scott-latitude-e6320.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 ESMTPSA id A27F020E4064; Tue, 10 Apr 2012 19:47:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Apr 2012 19:47:51 -0400 Message-ID: <1494108.a5MQrbFgDA@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-22-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280D28B8@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <1740601.l8OcLQSMQM@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280D28B8@exch-mbx901.corp.cloudmark.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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:47:53 -0000 On Tuesday, April 10, 2012 11:32:02 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Tuesday, April 10, 2012 4:20 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, > > was #12 > > > > There are certainly similarities, but I think the false positive > > concern is a lot greater with ADSP. It certainly is for me. From my > > POV, ADSP is only suitable for a few high profile phishing targets > > while SPF -all is something that has general utility if one is willing > > to accept some noise level breakage in fringe cases. > > I'm still not seeing the difference. If you publish "-all" then you're > claiming you have very tight control over the path your email takes to get > from you to wherever. Doesn't that also mean DKIM failures are pretty much > also under your control, or at least your influence? > > (I think this is interesting, but we may be straying a bit afield for this > WG list. Feel free to drag this to ietf-dkim or spf-discuss if the chairs > slap our wrists.) Since our wrists are thus far unslapped ... The difference is the failure cases. For SPF it's a combination of forwarding and poorly considered SPF checking (when can argue in what proportion in the other thread) and some web based applications that spoof Mail From. Because of the effect of years of education there are relatively fewer web applications doing this kind of thing than there used to be. Here's a page of advice that's been around since at least 2004 if not before: http://www.openspf.org/Best_Practices/Webgenerated Comparing this to DKIM, there are similarities and differences. DKIM signatures should survive forwarding, so forwarding is not an issue for DKIM/ADSP, but mailing lists are and so are all the web apps that use the user's email address in the 5322.From (and many that use their own 5321.Mail >From use the user's 5322.From). As a result, a lot of normal use of email addresses ends up being unsigned (in the examples in the openspf.org link, one would be OK from a DKIM/ADSP point of view and one would be problematic). It's my contention that the cases that most users care about are much more likely to be a problem for DKIM/ADSP than SPF. That's consistent with data I've seen, but I can't give you hard numbers. Scott K From dotis@mail-abuse.org Tue Apr 10 17:31: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 C70F511E814A for ; Tue, 10 Apr 2012 17:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FvURVt7pWjK for ; Tue, 10 Apr 2012 17:31:20 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id B5E4511E8081 for ; Tue, 10 Apr 2012 17:31:20 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 191E91740440 for ; Wed, 11 Apr 2012 00:31:15 +0000 (UTC) Message-ID: <4F84D0CD.4090007@mail-abuse.org> Date: Tue, 10 Apr 2012 17:31:09 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> <4F84B5A6.2010100@mail-abuse.org> <6040139.OxyMbgc6SQ@scott-latitude-e6320> In-Reply-To: <6040139.OxyMbgc6SQ@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:31:25 -0000 On 4/10/12 4:06 PM, Scott Kitterman wrote: > On Tuesday, April 10, 2012 03:35:18 PM Douglas Otis wrote: > > Dear Murray, > > > > Agreed. However, when the "Mail From" identity references an SPF > > record, the result only offers an "authorization" not > > "authentication". Higher levels of assurance would require SPF > > records to be specifically referenced by the "HELO". Such > > specificity is simply not possible with SPF semantics. This is > > also why SPF may not allow domains to defend their reputation. > > > > Regards, Douglas Otis > > > > P.S. Lack of "Helo" specificity represents a basic departure from- > > http://tools.ietf.org/html/draft-ietf-marid-csv-csa-02 > > Your insistence on the distinction between authorized and > authenticated making a difference is, in any practical terms, wrong. > We shouldn't get wrapped up in it here. I think when RFC 5451 was > published the issue was pretty well put to bed and trying to rehash > it now is a waste of everyone's time. Dear Scott, This argument can be avoided by simply using correct and accurate terminology. http://tools.ietf.org/html/rfc5451#section-1.5.2 Clarifies SPF offers authorization and not authentication, as does the title for RFC4408. Why misuse clearly defined terminology? Why misrepresent two different functions providing significantly different outcomes? A difference that permits the following assertion "This may have been sent by your bank" when a source was authorized versus "This has been sent by your bank" when a source is authenticated. I think most see the practical difference in these two statements. There is a fairly high number of servers being compromised. Statements that SPF authenticates a source grossly overstates assurances SPF can offer. > it's a difference not a departure. SPF HELO checking is unrelated > to CSV. CSV is specifically referenced by "Helo" and precludes "Mail From" authorizations. The difference is authentication versus authorization. :^( Regards, Douglas Otis From spf2@kitterman.com Tue Apr 10 18:43: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 B6CE211E813A for ; Tue, 10 Apr 2012 18:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usy0WhVXZWVk for ; Tue, 10 Apr 2012 18:43:02 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81611E811A for ; Tue, 10 Apr 2012 18:43:02 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 864FC20E4099; Tue, 10 Apr 2012 21:43:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334108581; bh=R8IFAJEfdA34OKZnCMRjIwmgs1Q62YoSW9OmKgcJfs0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=N+bMdfOppGxG1KdeGxzOOgVTeAX3bscWXtUXWPhGUH5kraa8ixms/z/2lRTHVRdmu fFqyHRtyKzPOArSs+tEY6UEMiDCnC0+l2T/5/ZaOHBGVc5ZcupFi09puNgxVSfZ+gP bhMn+TFzWFHAGOFAyxgYdRkT9m+JI6pMsVGSUIBc= Received: from scott-latitude-e6320.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 ESMTPSA id 691AB20E4064; Tue, 10 Apr 2012 21:43:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Apr 2012 21:43 -0400 Message-ID: <2183407.C4QXyJ5reZ@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-22-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F84D0CD.4090007@mail-abuse.org> References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 01:43:03 -0000 On Tuesday, April 10, 2012 05:31:09 PM Douglas Otis wrote: > On 4/10/12 4:06 PM, Scott Kitterman wrote: > > On Tuesday, April 10, 2012 03:35:18 PM Douglas Otis wrote: > > > Dear Murray, > > > > > > Agreed. However, when the "Mail From" identity references an SPF > > > record, the result only offers an "authorization" not > > > "authentication". Higher levels of assurance would require SPF > > > records to be specifically referenced by the "HELO". Such > > > specificity is simply not possible with SPF semantics. This is > > > also why SPF may not allow domains to defend their reputation. > > > > > > Regards, Douglas Otis > > > > > > P.S. Lack of "Helo" specificity represents a basic departure from- > > > http://tools.ietf.org/html/draft-ietf-marid-csv-csa-02 > > > > Your insistence on the distinction between authorized and > > authenticated making a difference is, in any practical terms, wrong. > > We shouldn't get wrapped up in it here. I think when RFC 5451 was > > published the issue was pretty well put to bed and trying to rehash > > it now is a waste of everyone's time. > > Dear Scott, > > This argument can be avoided by simply using correct and accurate > terminology. > http://tools.ietf.org/html/rfc5451#section-1.5.2 > > Clarifies SPF offers authorization and not authentication, as does the > title for RFC4408. Why misuse clearly defined terminology? Why > misrepresent two different functions providing significantly different > outcomes? > > A difference that permits the following assertion "This may have been > sent by your bank" when a source was authorized versus "This has been > sent by your bank" when a source is authenticated. I think most see the > practical difference in these two statements. There is a fairly high > number of servers being compromised. Statements that SPF authenticates > a source grossly overstates assurances SPF can offer. > > > it's a difference not a departure. SPF HELO checking is unrelated > > to CSV. > > CSV is specifically referenced by "Helo" and precludes "Mail From" > authorizations. The difference is authentication versus authorization. :^( In real life these don't make any difference at all. If I can compromise a server that's configured to DKIM sign for a domain, then I can send arbitrary mail signed by that domain. If the same server is also listed in the domain's SPF record, they will also pass SPF. In real life both DKIM pass and SPF pass mean "passed through a server the domain had some positive opinion of". We'll say in SPFbis that SPF does authorization, don't worry, so we don't need to waste more of the working group's time on this, but it's of no consequence either way. Scott K From msk@cloudmark.com Tue Apr 10 19:43: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 D25A021F866B for ; Tue, 10 Apr 2012 19:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.732 X-Spam-Level: X-Spam-Status: No, score=-102.732 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXxZV+wMRu-G for ; Tue, 10 Apr 2012 19:43:21 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6446521F8669 for ; Tue, 10 Apr 2012 19:43:21 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id wSjL1i0010as01C01SjLsq; Tue, 10 Apr 2012 19:43:20 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=MpDQGhme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=khUQBtZODPMA90rQ4E8A:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=FwxUkg_GVPEQpbuR8UUA:9 a=gKO2Hq4RSVkA:10 a=hTZeC7Yk6K0A:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 19:43:20 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: More SUBMITTER data Thread-Index: Ac0XjNsOdZPdIjd7TneaNIszriW8ww== Date: Wed, 11 Apr 2012 02:43:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280D2BDCexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334112200; bh=Ja7pN7GqJ90fZVIUcCIOtLuWDqP8l+O26uT1A5/ld/E=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=js984AFLckL5EMNZ29nBDtZmENtVpQu7lOh/c5cl16kH367OWHIIMJBdqF8akIkGA HuAJNYY0MNuusGrtNVYJ1JRlcLtcA8QGA6c12EL2hNc9X+ojzMMgRhSYdk8pU9b5ka Acf4jc+p3/mRmEDxORoYIxdf26Btxf6XAAjZJ3gw= Subject: [spfbis] More SUBMITTER data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 02:43:21 -0000 --_000_9452079D1A51524AA5749AD23E0039280D2BDCexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I mentioned previously, the vast majority of the MTAs advertising the SU= BMITTER extension out there are actually instances of MxLogic providing clo= ud filtering services for some domain. A contact at McAfee has told me that recent logs show about 11% of clients,= all of whom are shown the SUBMITTER extension, actually make use of it. -MSK --_000_9452079D1A51524AA5749AD23E0039280D2BDCexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As I mentioned previously, the vast majority of the = MTAs advertising the SUBMITTER extension out there are actually instances o= f MxLogic providing cloud filtering services for some domain.

 

A contact at McAfee has told me that recent logs sho= w about 11% of clients, all of whom are shown the SUBMITTER extension, actu= ally make use of it.

 

-MSK

--_000_9452079D1A51524AA5749AD23E0039280D2BDCexchmbx901corpclo_-- From pmidge@microsoft.com Tue Apr 10 20:22: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 6075A11E8096 for ; Tue, 10 Apr 2012 20:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE7ySNJnuDHa for ; Tue, 10 Apr 2012 20:22:08 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id AAE7411E8081 for ; Tue, 10 Apr 2012 20:22:06 -0700 (PDT) Received: from mail55-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 03:22:05 +0000 Received: from mail55-db3 (localhost [127.0.0.1]) by mail55-db3-R.bigfish.com (Postfix) with ESMTP id 7A36D40300; Wed, 11 Apr 2012 03:22:05 +0000 (UTC) X-SpamScore: -21 X-BigFish: VS-21(zz9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail55-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=pmidge@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail55-db3 (localhost.localdomain [127.0.0.1]) by mail55-db3 (MessageSwitch) id 1334114522485346_15011; Wed, 11 Apr 2012 03:22:02 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.240]) by mail55-db3.bigfish.com (Postfix) with ESMTP id 73D344E006F; Wed, 11 Apr 2012 03:22:02 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 03:22:02 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.185]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0283.004; Wed, 11 Apr 2012 03:21:59 +0000 From: Paul Midgen To: "Murray S. Kucherawy" , "spfbis@ietf.org" Thread-Topic: More SUBMITTER data Thread-Index: Ac0XjNsOdZPdIjd7TneaNIszriW8wwABOlWA Date: Wed, 11 Apr 2012 03:21:58 +0000 Message-ID: <7F7F36E50398F84DBAF25C9D51732F1E20F80D9B@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_7F7F36E50398F84DBAF25C9D51732F1E20F80D9BTK5EX14MBXC293r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [spfbis] More SUBMITTER data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 03:22:09 -0000 --_000_7F7F36E50398F84DBAF25C9D51732F1E20F80D9BTK5EX14MBXC293r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 11% of a distinct count of agents or of some agent-agnostic number of inbou= nd connections? Can they say what % of non-spam internet email volume that = represents? From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Tuesday, April 10, 2012 7:43 PM To: spfbis@ietf.org Subject: [spfbis] More SUBMITTER data As I mentioned previously, the vast majority of the MTAs advertising the SU= BMITTER extension out there are actually instances of MxLogic providing clo= ud filtering services for some domain. A contact at McAfee has told me that recent logs show about 11% of clients,= all of whom are shown the SUBMITTER extension, actually make use of it. -MSK --_000_7F7F36E50398F84DBAF25C9D51732F1E20F80D9BTK5EX14MBXC293r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

11% of a distinct coun= t of agents or of some agent-agnostic number of inbound connections? Can th= ey say what % of non-spam internet email volume that represents?=

 

From: spfbis-b= ounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, April 10, 2012 7:43 PM
To: spfbis@ietf.org
Subject: [spfbis] More SUBMITTER data

 

As I mentioned previously, the vast majority of the = MTAs advertising the SUBMITTER extension out there are actually instances o= f MxLogic providing cloud filtering services for some domain.

 

A contact at McAfee has told me that recent logs sho= w about 11% of clients, all of whom are shown the SUBMITTER extension, actu= ally make use of it.

 

-MSK

--_000_7F7F36E50398F84DBAF25C9D51732F1E20F80D9BTK5EX14MBXC293r_-- From internet-drafts@ietf.org Tue Apr 10 21:19: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 59D2211E80F6; Tue, 10 Apr 2012 21:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuRAH3+aqrkD; Tue, 10 Apr 2012 21:19:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6A911E8079; Tue, 10 Apr 2012 21:19:39 -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.00 Message-ID: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 21:19:39 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:19:40 -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 : Resolution of The SPF/Sender-ID Experiment Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-01.txt Pages : 10 Date : 2012-04-10 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender-ID, two proposed email authentication protocols. Because of interoperability concerns created by simultaneous use of the two protocols by a receiver, and some concerns with Sender-ID and compatibility with existing standards, the IESG required them to have Experimental status and invited the community to observe their deployments for a period of time, hoping convergence would be possible later. After six years, sufficient experience and evidence have been collected that the experiment thus created can be considered concluded, and a single protocol can be advanced. This memo presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-01.txt From msk@cloudmark.com Tue Apr 10 21:28: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 11A8711E8079 for ; Tue, 10 Apr 2012 21:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.725 X-Spam-Level: X-Spam-Status: No, score=-102.725 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wvWRlcLTNW7 for ; Tue, 10 Apr 2012 21:28:17 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6699811E8096 for ; Tue, 10 Apr 2012 21:28:17 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id wUUW1i00B0ZaKgw01UUW5b; Tue, 10 Apr 2012 21:28:30 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=HuX06jvS c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=GSAhiqMDalSqhmuBPNAA:9 a=CjuIK1q_8ugA:10 a=VSf6PjqhF0QA:10 a=lZB815dzVvQA:10 a=8AxldCkKEZH8czTf:21 a=hfXhjoIONlN7d9Nf:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=0uFQvZgm8b5_KG5GJ1EA:7 a=gKO2Hq4RSVkA:10 a=hTZeC7Yk6K0A:10 a=EAFaW3EP02kIHmF_:21 a=HKepfsJWppk09QWY:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 21:28:16 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: More SUBMITTER data Thread-Index: Ac0XjNsOdZPdIjd7TneaNIszriW8wwABOlWAAAJUDLA= Date: Wed, 11 Apr 2012 04:28:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D2CE0@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> <7F7F36E50398F84DBAF25C9D51732F1E20F80D9B@TK5EX14MBXC293.redmond.corp.microsoft.com> In-Reply-To: <7F7F36E50398F84DBAF25C9D51732F1E20F80D9B@TK5EX14MBXC293.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280D2CE0exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334118510; bh=ncsMFKTCSbH9Cqd3A0j1jFuREfz08V5uWxIaAd4iNJA=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=hLxz9C1/Q4Qi8xfAIBv0ydznxS5tycjbtpNDNhiXunyCxiVX8OVYQXOPKjEhxn06E K4QNyIzQ0YnCUIS4k/xt17YxtsTjCNhVy/X39kxwV8IVrCu3EczrYboPxJdKqrJVWN XuLzKoq5lO8pEv27cvNialEcrqM84UClnc05ECPU= Subject: Re: [spfbis] More SUBMITTER data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:28:19 -0000 --_000_9452079D1A51524AA5749AD23E0039280D2CE0exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My understanding is that it's 11% of distinct agents make use of the SUBMIT= TER extension, even though it's offered to everyone. I don't have any data= on whether or not they're spammers or whether or not those same clients ar= e using domains that publish "spf2.0/pra" records (which would be necessary= for use of SUBMITTER to be meaningful), but I can ask them. I also suspect the spammer question, while interesting, will ultimately be = considered an invalid criterion for determining whether or not the extensio= n is "in use". -MSK From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Paul Midgen Sent: Tuesday, April 10, 2012 8:22 PM To: Murray S. Kucherawy; spfbis@ietf.org Subject: Re: [spfbis] More SUBMITTER data 11% of a distinct count of agents or of some agent-agnostic number of inbou= nd connections? Can they say what % of non-spam internet email volume that = represents? From: spfbis-bounces@ietf.org [mailto:spfbi= s-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Tuesday, April 10, 2012 7:43 PM To: spfbis@ietf.org Subject: [spfbis] More SUBMITTER data As I mentioned previously, the vast majority of the MTAs advertising the SU= BMITTER extension out there are actually instances of MxLogic providing clo= ud filtering services for some domain. A contact at McAfee has told me that recent logs show about 11% of clients,= all of whom are shown the SUBMITTER extension, actually make use of it. -MSK --_000_9452079D1A51524AA5749AD23E0039280D2CE0exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My understanding is th= at it’s 11% of distinct agents make use of the SUBMITTER extension, e= ven though it’s offered to everyone.  I don’t have any dat= a on whether or not they’re spammers or whether or not those same clients are using domains that publish “spf2.0/pra” recor= ds (which would be necessary for use of SUBMITTER to be meaningful), but I = can ask them.

 

I also suspect the spa= mmer question, while interesting, will ultimately be considered an invalid = criterion for determining whether or not the extension is “in useR= 21;.

 

-MSK=

 

From: spfbis-b= ounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Paul Midgen
Sent: Tuesday, April 10, 2012 8:22 PM
To: Murray S. Kucherawy; spfbis@ietf.org
Subject: Re: [spfbis] More SUBMITTER data

 

11% of a distinct coun= t of agents or of some agent-agnostic number of inbound connections? Can th= ey say what % of non-spam internet email volume that represents?=

 

From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, April 10, 2012 7:43 PM
To: spfbis@ietf.org
Subject: [spfbis] More SUBMITTER data

 

As I mentioned previously, the vast majority of the = MTAs advertising the SUBMITTER extension out there are actually instances o= f MxLogic providing cloud filtering services for some domain.

 

A contact at McAfee has told me that recent logs sho= w about 11% of clients, all of whom are shown the SUBMITTER extension, actu= ally make use of it.

 

-MSK

--_000_9452079D1A51524AA5749AD23E0039280D2CE0exchmbx901corpclo_-- From msk@cloudmark.com Tue Apr 10 21:32: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 D225A11E80F6 for ; Tue, 10 Apr 2012 21:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLyaEEshxlPu for ; Tue, 10 Apr 2012 21:32:37 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id A065E11E8096 for ; Tue, 10 Apr 2012 21:32:37 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id wUYq1i0010as01C01UYr6Y; Tue, 10 Apr 2012 21:32:51 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=HuX06jvS c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=Mf1AqxdU4v8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=rsbiYjKYGRf8emBIjOMA:9 a=giPStpiWNQgn8BZ6p3wA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 21:32:36 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt Thread-Index: AQHNF5pS6FtEiFz0HkyUGUpStNeC9ZaVBYvA Date: Wed, 11 Apr 2012 04:32:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D2CFC@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> In-Reply-To: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334118771; bh=unfKKe/iEElVeBVnyw6P+deARlviDo5Yb1pQdPfdKEw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EPQ1VG4v6tgimsQKfJHpypupJU9Kkrpru+x+jzjVCIdL966ik3Auqh2LuynSAoQxj Dyst3fKnu1lomECOsE1JXhLRaEuaOZFXX8k5CTfEe0r074TNBgeGUWl+VwOHal+p9W oVUPe3OhTwtYj4oH+IMSaMPA4uY707IX195UCu3I= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:32:39 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Tuesday, April 10, 2012 9:20 PM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt >=20 > 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. >=20 > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-01.txt > Pages : 10 > Date : 2012-04-10 >=20 > In 2006 the IETF published a suite of protocol documents comprising > SPF and Sender-ID, two proposed email authentication protocols. > Because of interoperability concerns created by simultaneous use of > the two protocols by a receiver, and some concerns with Sender-ID and > compatibility with existing standards, the IESG required them to have > Experimental status and invited the community to observe their > deployments for a period of time, hoping convergence would be > possible later. >=20 > After six years, sufficient experience and evidence have been > collected that the experiment thus created can be considered > concluded, and a single protocol can be advanced. This memo presents > those findings. The update includes a general update of recent data collections, including = a re-run of Philip's survey, the addition of one of Hotmail's surveys, and = an update to mine. I also added a snapshot of the SUBMITTER survey results= , and added some SUBMITTER use information from McAfee. At this point I'm expecting some data from Hotmail late this month, and I c= an keep checking on the SUBMITTER survey and my own SPF record survey, but = I don't anticipate any of the current text to change much as a result. So = unless there are other data sets that we should go get or that people want = to submit, I think we're close to done. Rather than simply waiting for all of those pending results to come in, I s= uggest we start talking about the text, i.e., people should review it and c= omment. Or have we done enough due diligence on both text and data to ask the co-ch= airs for a Working Group Last Call already? :-) -MSK From sm@elandsys.com Tue Apr 10 23:57: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 B65F521F8666 for ; Tue, 10 Apr 2012 23:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td5tMa1DmekD for ; Tue, 10 Apr 2012 23:57: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 75FCB11E8079 for ; Tue, 10 Apr 2012 23:57:46 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3B6vWO8018466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 23:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334127465; i=@elandsys.com; bh=VtWsyUJEivgmxNC/ST5nPCpS03E3VPtSrl2qsjwBNEc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fklTzJ+cF4NAKCVtybXIjOH7RyameUbzC9QKzFwBwvRaWhT5qIGSArClXm7Kjyuj7 TIcT6d9okq2ACncn2axkZZi2+KHGd3s0h19CLEyFEabZ+vVbTjmJ3Jr2S4gFZRGCcZ TnsLoJ2e1KhY0IbBhKQcmsmhQbh8ZaZA224FuLOU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334127465; i=@elandsys.com; bh=VtWsyUJEivgmxNC/ST5nPCpS03E3VPtSrl2qsjwBNEc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nZorOQXoHFo9T2uh493LV3jp2VlDuZ6zlr3Ez0ngcUo8r7GdHuIPxoI8tqxqz0pPW c8zOaw0lAFQqjD2FzlZuZEJ/0Y5S3sRsl4//tcmnsDNW6URsbXTiceHUzhsh+A0BGJ ALuDHBMVHu5jwasvzC//9xOW8osqeTSSl42aB2y4= Message-Id: <6.2.5.6.2.20120410232513.084d16e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 23:56:13 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E0039280D2CFC@exch-mbx901.corp.cl oudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280D2CFC@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 06:57:51 -0000 Hi Murray, At 21:32 10-04-2012, Murray S. Kucherawy wrote: >Or have we done enough due diligence on both text and data to ask >the co-chairs for a Working Group Last Call already? :-) There is a "SHOULD" and a "MUST" in Appendix A which got flagged because of RFC 2119. I ignored the nit in an unrelated draft. I'll discuss with Andrew about the Working Group Last Call. I'll leave it to the Responsible AD to determine whether this working group have done enough due diligence in producing the first deliverable. :-) Regards, S. Moonesamy From msk@cloudmark.com Wed Apr 11 00:04: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 5FB4421F8665 for ; Wed, 11 Apr 2012 00:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.713 X-Spam-Level: X-Spam-Status: No, score=-102.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pNqYI8nRbgH for ; Wed, 11 Apr 2012 00:04:29 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8D96221F8638 for ; Wed, 11 Apr 2012 00:04:29 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id wX4J1i0010as01C01X4JqM; Wed, 11 Apr 2012 00:04:18 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=MpDQGhme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=Mf1AqxdU4v8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=wPPvXI8NAAAA:8 a=48vgC7mUAAAA:8 a=CvQwOSZi0xjzqyxq0O4A:9 a=CjuIK1q_8ugA:10 a=pOcSzP0BEVkA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 00:04:18 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt Thread-Index: AQHNF5pS6FtEiFz0HkyUGUpStNeC9ZaVBYvAgAAsDmWAAAEr0A== Date: Wed, 11 Apr 2012 07:04:16 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D2E90@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280D2CFC@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120410232513.084d16e8@resistor.net> In-Reply-To: <6.2.5.6.2.20120410232513.084d16e8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334127858; bh=5fzGcEOjSYLK7spEYgEbU6hDQLgjix9VjK/MCsh2DU0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=p05ti+6lKWMoINeyVcWpaq1rF2uE7jYPkLxwUBoh8q9wUW7GPl0PREY0ysFhW/tIQ dHi1vxce9xZchzOQPwRlXDA+tnfAXolHLPzsEO+AQiakBb4Orpl/IPYWGOAzDrudtm 2I5CzXuz/1oXCW2O/KSiunRT0HlOKpCL/gjbNOUY= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:04:30 -0000 > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Tuesday, April 10, 2012 11:56 PM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt >=20 > There is a "SHOULD" and a "MUST" in Appendix A which got flagged > because of RFC 2119. I ignored the nit in an unrelated draft. The idnits check didn't throw an alarm. What was the flag? Or are you tal= king about your own review? It's a citation of other normative text, but is not itself normative. That= 's not something we can catch automatically, I imagine. -MSK From sm@elandsys.com Wed Apr 11 00:46: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 BE15B21F86BB for ; Wed, 11 Apr 2012 00:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1igaSL9dBOS for ; Wed, 11 Apr 2012 00:46:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE3921F8682 for ; Wed, 11 Apr 2012 00:46:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3B7jfgP016492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 00:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334130353; i=@elandsys.com; bh=G4JhX8lGjqewQdI2pgStDxExd6HfCw3+6clM9pEZ8lI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ns4HWzwglT1imqh38ltDQQ1YlXBY6ojfmUaCCe7JVqINbY8V2LOSQDkXnuCahtNz0 drwUb8LlzFXkwUEq7tvx5WAF0rCMje0O5BfLpzzehgtlKJyEPSSc5J7nz5BdMGvV62 kxFaceP330mYItJ76dcf33KkjR6FATpr7mxUJyYA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334130353; i=@elandsys.com; bh=G4JhX8lGjqewQdI2pgStDxExd6HfCw3+6clM9pEZ8lI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WKGzdq9myKLwc5J6xkV4y0yv2mNtj18ej3qpRK+Gm4nfKlfEiir+OMBpba1uhOmWA Yr5xVQuMaReEyLj82FdZ3OcIP6zdy1sMlL+DUTT6M/9Au+RXSl4pjCAxj/DsamwL1I O42rftUpvBpEI5DJDjYz20KUlYYxA/cd3+BPltPs= Message-Id: <6.2.5.6.2.20120411001424.08599168@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Apr 2012 00:30:44 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E0039280D2E90@exch-mbx901.corp.cl oudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280D2CFC@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120410232513.084d16e8@resistor.net> <9452079D1A51524AA5749AD23E0039280D2E90@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:46:07 -0000 Hi Murray, At 00:04 11-04-2012, Murray S. Kucherawy wrote: >The idnits check didn't throw an alarm. What was the flag? Or are >you talking about your own review? The following is from Id-nits [1]: "RFC 2119 keyword, line 358: '... SHOULD publish both types and M...'" >It's a citation of other normative text, but is not itself >normative. That's not something we can catch automatically, I imagine. Yes. I wouldn't worry about it. I mentioned it in case the question comes up. Regards, S. Moonesamy 1. http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-spfbis-experiment-01.txt From hsantos@isdg.net Wed Apr 11 01: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 808EF11E8195 for ; Wed, 11 Apr 2012 01:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lKancFN-Ose for ; Wed, 11 Apr 2012 01:54:47 -0700 (PDT) Received: from secure.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 554D111E8150 for ; Wed, 11 Apr 2012 01:54:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2578; t=1334134475; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=swJDeGISTG+eePnaSKnQODvHNFE=; b=kkrkcJYbMwiqQhhxcHuP FhceL/sfYJeT/JXt/94u6MzZneCOL6Xh+d+p7eawuHCDFnU4V6lcoP3P54UAGlq+ eIxfHKWEUhJZXr4GjCuY5sw+LAcTrr9oAOCXCz+Kuonys2TFo0/UDjsaDlJ41yiL GQzCBoGX6c5aMAwoH3hphLI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Apr 2012 04:54: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3041305266.24043.3600; Wed, 11 Apr 2012 04:54:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2578; t=1334134154; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ZrnvbFJ +/7us3lkeEv5uJ5E8kOEmsPmgNqbhQPbDIVQ=; b=cpPSiLd3NCxhfmjqyNGmcAm vSZgPPwg+nKOBb4hxl5XtgNs2LeuXgvQalg58Lif0hwDUlE4uoeqtQELYq8nbUWL kepk2jQ/kFud0yw2Dzovl9J7/6xYvVxRTHcxAAxQGDmpU5+A/wyq0rWB18IYNFgL Jkm/MA2Lw3nq1+n5ZTCA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Apr 2012 04:49:14 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3640210315.929.5932; Wed, 11 Apr 2012 04:49:14 -0400 Message-ID: <4F854699.2080309@isdg.net> Date: Wed, 11 Apr 2012 04:53:45 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Douglas Otis References: <20120324090349.15462.qmail@joyce.lan> <9452079D1A51524AA5749AD23E0039280D25E6@exch-mbx901.corp.cloudmark.com> <4F84B5A6.2010100@mail-abuse.org> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> In-Reply-To: <4F84D0CD.4090007@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:54:48 -0000 Douglas Otis wrote: >> > >> > P.S. Lack of "Helo" specificity represents a basic departure from- >> > http://tools.ietf.org/html/draft-ietf-marid-csv-csa-02 >> >> Your insistence on the distinction between authorized and >> authenticated making a difference is, in any practical terms, wrong. >> We shouldn't get wrapped up in it here. I think when RFC 5451 was >> published the issue was pretty well put to bed and trying to rehash >> it now is a waste of everyone's time. > > Dear Scott, > > This argument can be avoided by simply using correct and accurate > terminology. > http://tools.ietf.org/html/rfc5451#section-1.5.2 > > Clarifies SPF offers authorization and not authentication, as does the > title for RFC4408. Why misuse clearly defined terminology? Why > misrepresent two different functions providing significantly different > outcomes? Hi Doug, Hmmm, I don't wish to get into AA (Authentication and/or Authorization) semantic debates, but I agree with Scott. I view authentication defining who the client is and authorization defining what the client is allowed to do. There are legacy protocols that are based on this AA duality and we don't need to go much further than RADIUS which has its in its protocol title the term "Authentication" Remote Authentication Dial-In User Service (RADIUS) which is just login phase of the protocol. Phase two is the collection the dictionary tokens to established the line and/or user authorization levels and phase three is packet signaling to initiate and also end the accounting recording and protocol session. All protocols that inherently include a LOGIN concept offers the similar AA duality framework. > A difference that permits the following assertion "This may have been > sent by your bank" when a source was authorized versus "This has been > sent by your bank" when a source is authenticated. I think most see the > practical difference in these two statements. I don't and IMV, the latter is not a good example for authentication. I would suggest: "I am the BANK" is an example of authentication. Perhaps because it may not be a good example using banks with its high-value user/vendor communications needs because your example illustrates the promotion of the social engineering "Cry Wolf" syndrome - "This may have been sent by your bank" is not ideal for an authorization concept. Perhaps better "This bank service MAY not be available to you" works better. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Wed Apr 11 03:17: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 2356621F86F7 for ; Wed, 11 Apr 2012 03:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gQ2yVgi34JT for ; Wed, 11 Apr 2012 03:17:35 -0700 (PDT) Received: from mail.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E7CD321F86F3 for ; Wed, 11 Apr 2012 03:17:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1697; t=1334139451; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=RnRwiYdRtWqIQOmuzj1P4ZZM+V0=; b=bczINv4eQ+iJzTfowvCj rOEOaqPDdt3FZ2P1ExQ8Eeo9Y0QWpBK0LiAf1oeRg18o8zrZEipitv8Dc32z42eZ F7XvTdOEyMvmGRBaLie/AboPvNkVAmxq+p9JfeZnHlztFtiSGsRBz7ct+L/+8cSm Hohbj5bvhpDNJe82w65ZHgM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Apr 2012 06:17: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3046280387.24043.4536; Wed, 11 Apr 2012 06:17:30 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1697; t=1334139131; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=DWVnm1c U6zFyaIeIaS8DFbWHKON4DpaVLfWiiM/JmX8=; b=SDas93izRqciuuSgUGytSNp voM48Z7Gl6PRG7Ni1cvHNZDml4qjfoph/fcVXmpQIaTh+EtsSrNG37LlUqe/fmjk wxqaD2nhl1l9eFmVvXe4DbPXghnneBTo24BklO0QjG3rYdoOmLHqm+2iHXpIX74h qn9FKEnzZa25N6bKeKn0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Apr 2012 06:12:11 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3645186440.964.6892; Wed, 11 Apr 2012 06:12:10 -0400 Message-ID: <4F855A0B.5040309@isdg.net> Date: Wed, 11 Apr 2012 06:16:43 -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: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> In-Reply-To: <20120411041939.18506.10899.idtracker@ietfa.amsl.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: [spfbis] draft-ietf-spfbis-experiment-01 Issue: Section 2 Not Chartered X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:17:36 -0000 The entire section 2 of the Interop report, and specifically the last paragraph 2. The Need For Consensus These two protocols fall into a family of protocols that provide domain-level email authentication services. For reference, another prominent one is [DKIM]. Various efforts exist that use these as building blocks to increased abuse filtering capabilities, and indeed this sort of work has spawned another working group in the Applications area, with still more of these incubating in associations and trade groups outside of the IETF. There is thus some palpable interest in having a path authorization scheme, as well as a domain-level signing scheme, on the Standards Track so that these newer technologies can develop with confidence. This is, in part, why the community has decided to expend the effort to bring this experiment to a conclusion and document the results, and then advance a single path authorization technology. I believe this section 2 should be removed in its entirety. Reasons: Section 2 is *NOT* a SPFBIS charter consideration. DKIM is not a consideration for SPFBIS, nor was it the main interest of the SPFBIF group. While the editor admits it was his reason for starting the group, the editor neglects it was not one of the 2006 IETF considerations for initiating SPF, SENDERID experiment to explore the coexistence of both protocols. In fact, the proposed CSV/DNA, Domainkeys and IM, and DKIM by virtue of DKEYS/IM eventual merged protocols where specifically voted out and tossed out as MARID workgroup products to consider. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Wed Apr 11 03:50: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 5887321F8657 for ; Wed, 11 Apr 2012 03:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNDOWvlBXhUn for ; Wed, 11 Apr 2012 03:50:57 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4B91521F8658 for ; Wed, 11 Apr 2012 03:50:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1656; t=1334141445; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=hFYeFqFIHo4nMqWaANSk1+dr0e4=; b=BGH4KHCGpFIEgnsCfI3J vaMjWbugIU/i3HJKByloDnsaeEbcQfjnjhWn0y+zG5wZNfHXyiCTivfF+e+2q9gZ nx1oi/HydZMk2tTF0Jr1NiUiwy1TMbV9eSDtya2tp9qrSIMOwd+N4FFu2QQ7JJ1W M3YxuGnyFpykPKmGhEm3jJA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Apr 2012 06:50:45 -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 v6.4.454.1) with ESMTP id 3048275531.24043.5336; Wed, 11 Apr 2012 06:50:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1656; t=1334141129; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0kyuJOp 3vMxQew2d1YoDOrUb4La5CXSeFuByFkcV0GE=; b=Jc6Y7bdgDi9D3HxOJVlYoa+ 375SHIIJvnq9k8D4gBAyXAC5XL9XAyl68UTWR2huw2+nYUaca4c90DCxOgreKiAN A/E/GVTb2I8bWmY+wjZqKmdaZdO39tdzDl6RiZ6NQalOWVTRT7xwIEBZhjhDpp8R FkOLa6u1cGKftT1fQQfE= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Apr 2012 06:45:29 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3647183877.967.2552; Wed, 11 Apr 2012 06:45:27 -0400 Message-ID: <4F8561D8.4030208@isdg.net> Date: Wed, 11 Apr 2012 06:50:00 -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: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> In-Reply-To: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:50:58 -0000 Two comments; 1) In section 5.2, item 3 3. that the absence of significant adoption of the type 99 DNS resource record, the [SUBMITTER] extension, [SENDER-ID], and [PRA], indicates that they are de facto obsolete. More of a nit, I recommend the two itemized recommendations to be split as #3 and #4. The two stated recommendations are two completely different non-related recommendations where current implementations will most likely consider separated. 2) What does "de facto obsolete" mean? This is a slippery slope problem which quite honestly is not the main issue but rather it comes of the expense of a lack of understanding what the PRA presented and the data has always shown. In short, the PRA was not expected be dominant. It was not suppose to be an Alternative solution to SPF. The PRA simply presented an algorithm to reflect the possible use cases where a 3rd domain identity in RFC2822 may exist. It was NOT suppose to be the dominant use case and it was well established it would a offer a low percentage around. By my estimates ~15%. The RFC4407 PRA algorithm specifically has it so that the fallback domains would be the same SPF domains to evaluate. IOW, outside the specific use cases, over 80% of the time, the SPF domains in the 5321/5322 transaction would be the same: PRA === 5322.From Domain === 5322.Sender Domain === 5321.MAIL FROM domain So IMO, the Interop report would be in error to use expected measurements of a low ~15% to suggest it reflects lack of usage or "de fauto obsolete" usage. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From vesely@tana.it Wed Apr 11 04:03: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 336A711E8086 for ; Wed, 11 Apr 2012 04:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGtJe0ahepV1 for ; Wed, 11 Apr 2012 04:03:50 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DC52E11E8075 for ; Wed, 11 Apr 2012 04:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334142216; bh=5Km2OqBMFTqoD9TRx6bBZNrQ0x0ayL5XrkDmxPW++Ww=; l=626; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YMcDuG/zwwG4cRTrfhbVcU/UemHYsf5dq8suEwuqQCbXO+A6emhW10RXrq/z7GWwQ FTJu11jE67eKiEphRLy9yaCR/Mxzx0OdwiMe4Ome7XzUbBqdfM9sAsjMt+JytBMxpU HkibhMkfl3QF6X06CBGxqHijTwcrIfHbaiVmG0xo= 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, 11 Apr 2012 13:03:36 +0200 id 00000000005DC046.000000004F856508.00002E03 Message-ID: <4F856508.6080002@tana.it> Date: Wed, 11 Apr 2012 13:03:36 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> <7F7F36E50398F84DBAF25C9D51732F1E20F80D9B@TK5EX14MBXC293.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E0039280D2CE0@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280D2CE0@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] More SUBMITTER data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:03:51 -0000 On Wed 11/Apr/2012 11:27:18 +0200 Murray S. Kucherawy wrote: > > My understanding is that it’s 11% of distinct agents make use of the > SUBMITTER extension, even though it’s offered to everyone. I think they mean that in 11% of distinct sessions their clients made use of the SUBMITTER extension. Is that correct? I have further difficulties reading the long, last but one paragraph of Section 3 of the I-D. The last sentences in particular are not very clear ("one of these {three|two}", which "That instance", what is "vast majority".) Would it be worth to promote that paragraph to its own subsection? From hsantos@isdg.net Wed Apr 11 04:32: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 4110C21F85A7 for ; Wed, 11 Apr 2012 04:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy5sUuBZl1WX for ; Wed, 11 Apr 2012 04:32:33 -0700 (PDT) Received: from pop3.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C973F21F85A5 for ; Wed, 11 Apr 2012 04:32:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1658; t=1334143936; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zhkgFo3zcfvVnsftnyGxjFbmguo=; b=XOAFBPLdRt4nMHiCW8h5 +aWaujhk793/DtIwzuDGo7p3AqSJuoNB4+ISaWCm/THVjC6PTXQAVivFe0fi8O6i lOzhqS/keTL9eGuRCh70DzXxEyNMxPhCI92P9fysdOvvtxxLDM9Sh4Pf0nnZgmGI D8zfjlxNMBUFymaLNJL1Pqg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Apr 2012 07:32: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3050765759.24043.4508; Wed, 11 Apr 2012 07:32:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1658; t=1334143615; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=rH0gtFZ RxJZ16cFdRHEUTvcfs9rl8BS5LIxUAq7JcDo=; b=vAzpJLIlUm6HvY8D+poW3to ZIKvmNvhqmrjONpnnEpkkfHZ1dVVSBozlkz6DgMPyt6u0nnLsWPkkTmeiWl1hLwl IJ+350bJdJYGB1UExrSZ2ZMFgtrvl9Q3mVmpQFmxdZkJbWVaicSAQyUeJer67iaF iMqzNEMSscE6++8owjOw= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Apr 2012 07:26:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3649671455.972.4268; Wed, 11 Apr 2012 07:26:55 -0400 Message-ID: <4F856B8F.1020708@isdg.net> Date: Wed, 11 Apr 2012 07:31:27 -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: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> <7F7F36E50398F84DBAF25C9D51732F1E20F80D9B@TK5EX14MBXC293.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E0039280D2CE0@exch-mbx901.corp.cloudmark.com> <4F856508.6080002@tana.it> In-Reply-To: <4F856508.6080002@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org Subject: Re: [spfbis] More SUBMITTER data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:32:34 -0000 Alessandro Vesely wrote: > On Wed 11/Apr/2012 11:27:18 +0200 Murray S. Kucherawy wrote: >> My understanding is that it’s 11% of distinct agents make use of the >> SUBMITTER extension, even though it’s offered to everyone. > > I think they mean that in 11% of distinct sessions their clients made > use of the SUBMITTER extension. Is that correct? > > I have further difficulties reading the long, last but one paragraph > of Section 3 of the I-D. The last sentences in particular are not > very clear ("one of these {three|two}", which "That instance", what is > "vast majority".) > > Would it be worth to promote that paragraph to its own subsection? I suspect that it was 11% different CHANNELS of MTA/MUAs. It is very difficult without some deep pattern recognition to come close to a good SWAG (Scientific Wide Ass Guess) detection of different MTAs software. Then again, it could be a quick eyeball view to see that there are different clients based on that the patterns of their messages. It could of use the X-Mailer header, but thats not always used and it could be stripped and replaced. In my data, the definite majority are eMarketing vendors and even when their domains are different, you can see by their pattern of messages, they are the same vendors or use the same software and also templates. But that has nothing to do nor suggest whether they are disqualified as valid protocol users. In fact, it is expected that they behave properly and with compliancy otherwise regardless of type of sender, they are kicked out. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Wed Apr 11 09:35: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 313BF11E80A3 for ; Wed, 11 Apr 2012 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P01nF2Bk-KIz for ; Wed, 11 Apr 2012 09:35:21 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8468D21F84F3 for ; Wed, 11 Apr 2012 09:35:21 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id wgbL1i0030ZaKgw01gbMGB; Wed, 11 Apr 2012 09:35:21 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=JPe5Qr2b c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=sDOGsXO9HecA:10 a=zutiEJmiVI4A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=GhPi3U54EwZUToPE3QIA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 09:35:20 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] More SUBMITTER data Thread-Index: Ac0XjNsOdZPdIjd7TneaNIszriW8wwABOlWAAAJUDLAAHJVsAAADH/3A Date: Wed, 11 Apr 2012 16:35:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D36AA@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> <7F7F36E50398F84DBAF25C9D51732F1E20F80D9B@TK5EX14MBXC293.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E0039280D2CE0@exch-mbx901.corp.cloudmark.com> <4F856508.6080002@tana.it> In-Reply-To: <4F856508.6080002@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334162121; bh=PKkv28g3QjqeHJLIaMl3IAsgEoBK64s3nFIc/rDOmRc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bFqovgMhP9OUQ6RCuAUFQRZ35PDgPglU/nI/S2oQkcoYLd6dg6+Z3PCZYJckNuccw vV9oK7GGVVusLg3rEczJgPYKf978RHjU8fCIzGnIWcNTprz3+/gzRLkzUBcCbQjtU0 3mltfZHMJSXSuhnY+QsM4+E74qTDVpGQtuTHkg8U= Subject: Re: [spfbis] More SUBMITTER data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:35:22 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcGZiaXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxlc3Nh bmRybyBWZXNlbHkNCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAxMiA0OjA0IEFNDQo+ IFRvOiBzcGZiaXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzcGZiaXNdIE1vcmUgU1VCTUlU VEVSIGRhdGENCj4gDQo+ID4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl04oCZcyAxMSUgb2Yg ZGlzdGluY3QgYWdlbnRzIG1ha2UgdXNlIG9mIHRoZQ0KPiA+IFNVQk1JVFRFUiBleHRlbnNpb24s IGV2ZW4gdGhvdWdoIGl04oCZcyBvZmZlcmVkIHRvIGV2ZXJ5b25lLg0KPiANCj4gSSB0aGluayB0 aGV5IG1lYW4gdGhhdCBpbiAxMSUgb2YgZGlzdGluY3Qgc2Vzc2lvbnMgdGhlaXIgY2xpZW50cyBt YWRlDQo+IHVzZSBvZiB0aGUgU1VCTUlUVEVSIGV4dGVuc2lvbi4gIElzIHRoYXQgY29ycmVjdD8N Cg0KWWVzLg0KDQo+IEkgaGF2ZSBmdXJ0aGVyIGRpZmZpY3VsdGllcyByZWFkaW5nIHRoZSBsb25n LCBsYXN0IGJ1dCBvbmUgcGFyYWdyYXBoIG9mDQo+IFNlY3Rpb24gMyBvZiB0aGUgSS1ELiAgVGhl IGxhc3Qgc2VudGVuY2VzIGluIHBhcnRpY3VsYXIgYXJlIG5vdCB2ZXJ5DQo+IGNsZWFyICgib25l IG9mIHRoZXNlIHt0aHJlZXx0d299Iiwgd2hpY2ggIlRoYXQgaW5zdGFuY2UiLCB3aGF0IGlzICJ2 YXN0DQo+IG1ham9yaXR5Ii4pDQo+IA0KPiBXb3VsZCBpdCBiZSB3b3J0aCB0byBwcm9tb3RlIHRo YXQgcGFyYWdyYXBoIHRvIGl0cyBvd24gc3Vic2VjdGlvbj8NCg0KWW91J3JlIHJpZ2h0LCBJJ2xs IHJld29yayB0aGUgdGV4dC4gIEkgd2FzIHRoaW5raW5nIG9mIGJyZWFraW5nIHVwIHRoYXQgc2Vj dGlvbiBpbnRvIHN1YnNlY3Rpb25zIGFib3V0IGVhY2ggZ3JvdXAgb2Ygc3VydmV5cyBvciBzdWJ0 b3BpYywgdGhvdWdoIHRoYXQgbWVhbnMgc29tZSBzdWJzZWN0aW9ucyB3aWxsIG9ubHkgaW5jbHVk ZSBhIHNpbmdsZSBwYXJhZ3JhcGgsIGFuZCBJIGhhdGUgdGhhdC4gIDotKQ0KDQotTVNLDQo= From spf2@kitterman.com Wed Apr 11 10:00: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 05EF711E8094 for ; Wed, 11 Apr 2012 10:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2wfwKUO4bMf for ; Wed, 11 Apr 2012 10:00:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1DB11E808D for ; Wed, 11 Apr 2012 10:00:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5F32320E40A3; Wed, 11 Apr 2012 13:00:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334163627; bh=7MibwnpBcIa01KSyIrmpuDEtK8X3wXRcAHaig4VDdRQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=H6V3qbXzl9Q+1dNd/v9ibdYP9Pm+gpMNBTqBJQH2YQGCOz5oaldcfR9M6cNF/18tv b60QOvDw0L4w7VaMzwX/cRDn3aBMicPmpPD3OGesMi8xAiY0D34+IsxkwGnU9Hhs1o JnExmXo7qOlQZRXjzuvZPJ3s6RiklK91ZiKnVfcs= Received: from scott-latitude-e6320.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 ESMTPSA id 44FEB20E4099; Wed, 11 Apr 2012 13:00:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Apr 2012 13:00:27 -0400 Message-ID: <12243525.pEIPoWZrTq@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-22-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280D36AA@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> <4F856508.6080002@tana.it> <9452079D1A51524AA5749AD23E0039280D36AA@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] More SUBMITTER data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:00:29 -0000 On Wednesday, April 11, 2012 04:35:20 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On B= ehalf > > Of Alessandro Vesely Sent: Wednesday, April 11, 2012 4:04 AM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] More SUBMITTER data > >=20 > >=20 > > > My understanding is that it=E2=80=99s 11% of distinct agents make= use of the > > > SUBMITTER extension, even though it=E2=80=99s offered to everyone= . > >=20 > >=20 > > I think they mean that in 11% of distinct sessions their clients ma= de > > use of the SUBMITTER extension. Is that correct? >=20 >=20 > Yes. >=20 >=20 > > I have further difficulties reading the long, last but one paragrap= h of > > Section 3 of the I-D. The last sentences in particular are not ver= y > > clear ("one of these {three|two}", which "That instance", what is "= vast > > majority".) > >=20 > > Would it be worth to promote that paragraph to its own subsection? >=20 >=20 > You're right, I'll rework the text. I was thinking of breaking up th= at > section into subsections about each group of surveys or subtopic, tho= ugh > that means some subsections will only include a single paragraph, and= I > hate that. :-) =20 It is still not clear to me why SUBMITTER is a standalone item for disc= ussion. =20 Since the SUBMITTER is supposed to the the PRA, the two are inextricabl= y=20 linked. You can't do SUBMITTER without doing PRA calculations. Scott K From msk@cloudmark.com Wed Apr 11 10:12: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 6666B11E8094 for ; Wed, 11 Apr 2012 10:12:50 -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.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCw-rIvmhLkT for ; Wed, 11 Apr 2012 10:12:49 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id E6EF611E808D for ; Wed, 11 Apr 2012 10:12:49 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id whCp1i0010as01C01hCpVP; Wed, 11 Apr 2012 10:12:49 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=JPe5Qr2b c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=sDOGsXO9HecA:10 a=zutiEJmiVI4A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 10:12:49 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] More SUBMITTER data Thread-Index: Ac0XjNsOdZPdIjd7TneaNIszriW8wwABOlWAAAJUDLAAHJVsAAADH/3AAAlWf4AADkOAsA== Date: Wed, 11 Apr 2012 17:12:48 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D3735@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280D2BDC@exch-mbx901.corp.cloudmark.com> <4F856508.6080002@tana.it> <9452079D1A51524AA5749AD23E0039280D36AA@exch-mbx901.corp.cloudmark.com> <12243525.pEIPoWZrTq@scott-latitude-e6320> In-Reply-To: <12243525.pEIPoWZrTq@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334164369; bh=pT49IQiDEpu/MAvRLaQ2S3TBDyXIYbnJyVyC/xOm1xI=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TpENkOHhVgaInLIw2B1CkB8LexGgtQ3TBH8l0rtBilDPfKTFXaA55ELCU6cnpmuK1 /0cLNZY7FobwLdC5wgspu5X3kpObrYYHDrYPPmdhz9aESYUFsYIuIdzAve37uEZ/GL vqHtmnNWCAuSfucgrZmO5TudvtloGz4+oCnQJcZw= Subject: Re: [spfbis] More SUBMITTER data X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:12:50 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcGZiaXMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNwZmJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2NvdHQg S2l0dGVybWFuDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMTIgMTA6MDAgQU0NCj4g VG86IHNwZmJpc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NwZmJpc10gTW9yZSBTVUJNSVRU RVIgZGF0YQ0KPiANCj4gSXQgaXMgc3RpbGwgbm90IGNsZWFyIHRvIG1lIHdoeSBTVUJNSVRURVIg aXMgYSBzdGFuZGFsb25lIGl0ZW0gZm9yDQo+IGRpc2N1c3Npb24uDQo+IFNpbmNlIHRoZSBTVUJN SVRURVIgaXMgc3VwcG9zZWQgdG8gdGhlIHRoZSBQUkEsIHRoZSB0d28gYXJlDQo+IGluZXh0cmlj YWJseSBsaW5rZWQuICBZb3UgY2FuJ3QgZG8gU1VCTUlUVEVSIHdpdGhvdXQgZG9pbmcgUFJBDQo+ IGNhbGN1bGF0aW9ucy4NCg0KVGhleSdyZSBub3QgaW4gdGVybXMgb2YgdGhlIGNvbmNsdXNpb25z LCBidXQgdGhleSBhcmUgaW4gdGVybXMgb2YgcHJlc2VudGluZyB0aGUgZGF0YSBzaW5jZSB0aGUg c3VydmV5cyB3ZXJlIHJ1biBzZXBhcmF0ZWx5Lg0KDQotTVNLDQo= From dotis@mail-abuse.org Wed Apr 11 10:18: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 A03A411E8098 for ; Wed, 11 Apr 2012 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qoL84cq3O8E for ; Wed, 11 Apr 2012 10:18:09 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id ED31711E808D for ; Wed, 11 Apr 2012 10:18:08 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 77F541740241 for ; Wed, 11 Apr 2012 17:18:08 +0000 (UTC) Message-ID: <4F85BCD0.1040403@mail-abuse.org> Date: Wed, 11 Apr 2012 10:18:08 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> In-Reply-To: <2183407.C4QXyJ5reZ@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:18:09 -0000 On 4/10/12 6:43 PM, Scott Kitterman wrote: > On Tuesday, April 10, 2012 05:31:09 PM Douglas Otis wrote: >> Dear Scott, This argument can be avoided by simply using correct and >> accurate terminology. >> http://tools.ietf.org/html/rfc5451#section-1.5.2 Clarifies SPF offers >> authorization and not authentication, as does the title for RFC4408. >> Why misuse clearly defined terminology? Why misrepresent two >> different functions providing significantly different outcomes? A >> difference that permits the following assertion "This may have been >> sent by your bank" when a source was authorized versus "This has been >> sent by your bank" when a source is authenticated. I think most see >> the practical difference in these two statements. There is a fairly >> high number of servers being compromised. Statements that SPF >> authenticates a source grossly overstates assurances SPF can offer. >>> it's a difference not a departure. SPF HELO checking is unrelated >>> to CSV. >> CSV is specifically referenced by "Helo" and precludes "Mail From" >> authorizations. The difference is authentication versus authorization. :^( > In real life these don't make any difference at all. > > If I can compromise a server that's configured to DKIM sign for a domain, then > I can send arbitrary mail signed by that domain. If the same server is also > listed in the domain's SPF record, they will also pass SPF. In real life both > DKIM pass and SPF pass mean "passed through a server the domain had some > positive opinion of". > > We'll say in SPFbis that SPF does authorization, don't worry, so we don't need > to waste more of the working group's time on this, but it's of no consequence > either way. Dear Scott, Thank you for that assurance, but I still strongly disagree with your assessment of significance simply because it has become increasingly routine to find compromised servers. :^( The growing rate of compromised systems leads to a significant difference between authentication and authorization in the overall numbers of individuals and domains affected. This becomes significant in how SPF is to be used and whether it should supplant authentication schemes. Muddled use of these two terms often justifies misleading hyperbole about assurances offered. It is possible to implement prefix semantics like "_helo." to constrain which SMTP parameters reference records for example, but this would require recognition of a losing battle. Clarifying these terms better highlights value found in the SPF results headers (in a write-up that is still owed). Regards, Douglas Otis From internet-drafts@ietf.org Wed Apr 11 10:33: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 9CC8F21F8547; Wed, 11 Apr 2012 10:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23+t158QBsZZ; Wed, 11 Apr 2012 10:33:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311FF21F8535; Wed, 11 Apr 2012 10:33:06 -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.00 Message-ID: <20120411173306.22655.47104.idtracker@ietfa.amsl.com> Date: Wed, 11 Apr 2012 10:33:06 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-02.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:33:07 -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 : Resolution of The SPF/Sender-ID Experiment Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-02.txt Pages : 10 Date : 2012-04-11 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender-ID, two proposed email authentication protocols. Because of interoperability concerns created by simultaneous use of the two protocols by a receiver, and some concerns with Sender-ID and compatibility with existing standards, the IESG required them to have Experimental status and invited the community to observe their deployments for a period of time, hoping convergence would be possible later. After six years, sufficient experience and evidence have been collected that the experiment thus created can be considered concluded, and a single protocol can be advanced. This memo presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-02.txt From msk@cloudmark.com Wed Apr 11 10:36: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 EA99421F854B for ; Wed, 11 Apr 2012 10:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTzMtZsLtOIp for ; Wed, 11 Apr 2012 10:36:22 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1E20D21F853D for ; Wed, 11 Apr 2012 10:36:22 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id whcR1i0010ZaKgw01hcRip; Wed, 11 Apr 2012 10:36:25 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=HuX06jvS c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=X0BHMAxozCIA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=z5ZeRi2EqO7TzbJGLWIA:9 a=CFRc6cg6ZUKU5qM-3mQA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 10:36:10 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: I-D Action: draft-ietf-spfbis-experiment-02.txt Thread-Index: AQHNGAkvJvXP16+CHUWtraIFynlujpaV4lGw Date: Wed, 11 Apr 2012 17:36:09 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D37FB@exch-mbx901.corp.cloudmark.com> References: <20120411173306.22655.47104.idtracker@ietfa.amsl.com> In-Reply-To: <20120411173306.22655.47104.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334165785; bh=82/cQoi6HcVk3JhpVCjsK92F6pxD/afnjGz0y68gmm8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=W4mlLJZcWbWwnZqIzFf8iXsIzoxrgXj4i2qp+Eh4UQLJd0AuQ08NnLZTaKjbe90Lb rgftguQO9VRHuxcHLCyx0Babaf57raJDaDdMrtVbAaT3K4LSHP+S0v/0UFmQaEr9Sn izNzfSL35Uv+eiuIPevjO14mMWIN+hLqxwiFxmv8= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-02.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:36:23 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, April 11, 2012 10:33 AM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: I-D Action: draft-ietf-spfbis-experiment-02.txt >=20 > 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. >=20 > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-02.txt > Pages : 10 > Date : 2012-04-11 >=20 > [...] Since version numbers are free... :-) This version breaks apart Section 3 as Alessandro suggested, and I think he= 's right that it's much more readable now. Some minor wordsmith work was a= lso done, but no data changed. So again, if someone has more data to present, please do. If you feel the = conclusions are not supported by the evidence presented, please elaborate. = If someone feels we have more data to collect, please specify. Or if you'= ve read it and you think we're done and ready to move on to our next delive= rable, please say so. -MSK From hsantos@isdg.net Thu Apr 12 15:01: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 CB2D521F8731 for ; Thu, 12 Apr 2012 15:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51GWut4tQG-t for ; Thu, 12 Apr 2012 15:01:27 -0700 (PDT) Received: from winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 74C4121F8723 for ; Thu, 12 Apr 2012 15:01:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4731; t=1334268078; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ExdOx2Jh9rjpnM7MdOmFQEPAMcI=; b=oJ2orNaY/joqX6jJtnBX QLhkByVpRPMjjbSayD5QaDqxACIva/KjNcOrJSfkQJtiXA0jqb6QpzT/M4+1qwGO 8nRoLZSnMfjTn/+UrAnbGcDsgrBu2lzAWH1hL0qMMn0IP2XI8vNBamofuHW7Bb2h ZSNBc0TCtA0QlYHA11DpuAQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Apr 2012 18:01:18 -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 v6.4.454.1) with ESMTP id 3174906721.24931.3300; Thu, 12 Apr 2012 18:01:17 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4731; t=1334267757; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fJTnCXH JeO1EuFz9J5kh4Jd/PW4upTky6P7H7KHNBEA=; b=DomcRibr1ff2QL7H0KPuQTZ ABcHgFxLpwu5eUKQ7Ocy71gckGSLhdUAep6pxqEq3MUT4GdHBqjF0e5ftH+it5Tn US/WJU8VtRQVvnk3f1LkYZJLki2bSJgAuYUUWspeobsM1kso4Gp5Wecac+nxcxLC LBZHb7d/LKq99dKYbcng= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Apr 2012 17:55:57 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3773812393.1164.5848; Thu, 12 Apr 2012 17:55:56 -0400 Message-ID: <4F875085.1060702@isdg.net> Date: Thu, 12 Apr 2012 18:00:37 -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: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> In-Reply-To: <4F85BCD0.1040403@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 22:01:29 -0000 Douglas Otis wrote: > On 4/10/12 6:43 PM, Scott Kitterman wrote: > Dear Scott, > > Thank you for that assurance, but I still strongly disagree with your > assessment of significance simply because it has become increasingly > routine to find compromised servers. :^( Are you describing a technical problem or a policy problem? > The growing rate of compromised systems leads to a significant > difference between authentication and authorization in the overall > numbers of individuals and domains affected. This becomes significant > in how SPF is to be used and whether it should supplant authentication > schemes. > > Muddled use of these two terms often justifies misleading hyperbole > about assurances offered. It is possible to implement prefix semantics > like "_helo." to constrain which SMTP parameters reference records for > example, but this would require recognition of a losing battle. > Clarifying these terms better highlights value found in the SPF results > headers (in a write-up that is still owed). Doug, One of the key problems has always been that the EHLO/HELO validity can not be enforced for long time legacy reasons and even with updated MTAs, its not always reliable to provide a valid and correct public domain name or IP literal. However, when there is clear intent to "FAKE" a spoof, this is a zero-false positive detectable rejection case. Part of the robust principle is that a RECEIVER knows how it can handle its own local information and knows less how to handle remote information. For example, these are examples of client intent to fake information: Invalid HELO [208.247.131.9] - client address [58.216.241.6] Invalid HELO mail.winserver.com - client address [118.114.245.48] The first is our IP and its an easy non-SPF IP literal syntax check, and the 2nd is SPF protected. So the first highest benefit is achieved by protecting your own property. However, the efficacy goes does down when its remote information. This is where the high DNS waste begins with helo SPF checking. But another key issue is understanding when the basic LMAP methodology and applicability for IP::HELO or the IP::MAILFROM authentication assertions. Note, I can't the ietf.org archive of the LMAP draft I-D, but I still have a copy here: http://isdg.net/Public/ietf/drafts/draft-irtf-asrg-lmap-discussion-00.txt I think this could be good review/reading to understand some of the SPF insights. See the summary which begins a clear fundamental understanding of what all the LMAP protocols were designed to offer. 1.1 Summary of the Protocol LMAP is based on two concepts: publication of policy by a domain, and application of that policy by a recipient MTA. The combination of these concepts permits SMTP originators and recipients to reach more informed consent when exchanging messages. The policy published by a domain includes statements as to which IP's are permitted to claim association with the domain in SMTP EHLO/HELO and MAIL FROM. That policy can request certain decisions to be made by a recipient on behalf of the domain. For example, "mail from example.com originates solely from the machine mail.example.com. Please reject mail allegedly from example.com which originates elsewhere." For implementations of LMAP protocols, it became prudent to understand the critical importance for optimized deployment in order to justify the blind application of these new DNS-based concepts knowing there is was going to be a very high NXDOMAIN yield of queries, especially during the short term. This is why I did the LMAP analysis: http://isdg.net/public/antispam/lmap/draft-smtp-lmap-santos-02.htm My main point in all this is that we should keep a perspective of how and when SPF is applied within the end to end transport path. helo checking ideas is not always applicable in the same way Mail From checking is not always applicable. Ideally, we should perhaps consider SPFBIS having semantic describing the basic applicability framework of: o 5321.MAILFROM checking recommended for MUA to MDA paths. - 5321.HELO checking expected to have a failure factor with MUAs o 5321.HELO checking recommended for MTA to MTA paths. - 531.MAILFROM checking expected to have a failure factor after initial HOP The problem is that in the anonymous world, the SMTP receiver will not know if the client is a MUA or MTA, when 5321.HELO or 5321.MAILFROM checking should be done and in what order and how much confidence weight should be considered to each or when one should override the other. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From vesely@tana.it Fri Apr 13 02:38: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 5E7E321F87D2 for ; Fri, 13 Apr 2012 02:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfcQ7c0Uw+Ua for ; Fri, 13 Apr 2012 02:38:28 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C41DA21F863D for ; Fri, 13 Apr 2012 02:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334309873; bh=G2I3pnRewPT4Ut1VV4ZWX+6MZmhghnG82CLmUSpil6c=; l=979; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=JnEllabwpWopkJoUXaT07WJ6bk5RAerR63BFZ06o2/Zc0d3h4NDlXA4G85TsMFeAt 3BRQlB6/BPTvwzHtLBfLrofW+H+aPFvki8Eo6eRoXlSTfDvxOIe5PGYVQ6K+1R5PAG ukAuzn1qAE6w3DGhLVsg1F8MteC+bsDx+OfBzCxU= 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, 13 Apr 2012 11:37:53 +0200 id 00000000005DC035.000000004F87F3F1.00004013 Message-ID: <4F87F3F1.7050503@tana.it> Date: Fri, 13 Apr 2012 11:37:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> In-Reply-To: <4F875085.1060702@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 09:38:29 -0000 On Fri 13/Apr/2012 11:04:51 +0200 Hector Santos wrote: > > Ideally, we should perhaps consider SPFBIS having semantic > describing the basic applicability framework of: > > o 5321.MAILFROM checking recommended for MUA to MDA paths. > - 5321.HELO checking expected to have a failure factor with MUAs > > o 5321.HELO checking recommended for MTA to MTA paths. > - 531.MAILFROM checking expected to have a failure factor after > initial HOP RFC 4408 seems to assume that there's no use in checking SPF on a submission server or during an authenticated SMTP session. This might be better clarified in SPFBIS. > The problem is that in the anonymous world, the SMTP receiver will not > know if the client is a MUA or MTA SUBMIT servers do know. Curiously, RFC 4405 claims to be appropriate for the submission protocol too. The examples it gives of mobile and guest users look rather archaic to me. Are there still people who pick submission servers casually? From spf2@kitterman.com Fri Apr 13 07:24: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 CC5F521F86E5 for ; Fri, 13 Apr 2012 07:24: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADut6i98wVqg for ; Fri, 13 Apr 2012 07:24:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 18C6821F86D0 for ; Fri, 13 Apr 2012 07:24:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 045F620E40A3; Fri, 13 Apr 2012 10:24:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334327058; bh=BKiWq2A/8/LxbcEPZuaBqqrhwm+6gUBnppVO2otHQ08=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=D11E5sZFUbXusZmyBUm2zafNXVANFyEEjSX1JmCTrMrtRnxlIATiXdxbDRc9F+s5c VqBhBrgM9T7x0foQkMTpwvvmRazexGQo7MSBof8DA7KGKmLrlgIqK/PBmrZwYOTLtS PK1DKIat6LtQDaRUsXpBWPOib/rfI7aQSm5SuwDE= Received: from scott-latitude-e6320.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 ESMTPSA id EB9EF20E4083; Fri, 13 Apr 2012 10:24:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Apr 2012 10:24:17 -0400 Message-ID: <3719298.HRTXbQIGjb@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F87F3F1.7050503@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Alessandro Vesely Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 14:24:20 -0000 On Friday, April 13, 2012 11:37:53 AM Alessandro Vesely wrote: > On Fri 13/Apr/2012 11:04:51 +0200 Hector Santos wrote: > > Ideally, we should perhaps consider SPFBIS having semantic > > > > describing the basic applicability framework of: > > o 5321.MAILFROM checking recommended for MUA to MDA paths. > > > > - 5321.HELO checking expected to have a failure factor with MUAs > > > > o 5321.HELO checking recommended for MTA to MTA paths. > > > > - 531.MAILFROM checking expected to have a failure factor after > > > > initial HOP > > RFC 4408 seems to assume that there's no use in checking SPF on a > submission server or during an authenticated SMTP session. This might > be better clarified in SPFBIS. What needs to be clarified? That checking to see if a non-MTA is an authorized MTA is not a good idea? Scott K From vesely@tana.it Fri Apr 13 08:59: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 D819C21F87EC for ; Fri, 13 Apr 2012 08:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.584 X-Spam-Level: X-Spam-Status: No, score=-4.584 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30K-l+x0cYMr for ; Fri, 13 Apr 2012 08:59:14 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 20E2B21F87E9 for ; Fri, 13 Apr 2012 08:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334332752; bh=1ytHCAlbeE9GulcG5s5ol1rINteIjVpddxu0FoCVKvs=; l=755; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=jiZU/Az54EcyduM8uOSUJ8aAkNPG7+hBag5E55fBC6YP4uI4uDVdQ7RAKzzJr0nUZ +8q4pnK/biKEcHUrbQoDjngigIlCrc/Y9v9dXkIeHfuT6HRnLg9/hjdjL2yR7ApDuM NO1QpcKKSclMA8g5hkDRMd0AiWzPJjGkwZyMsB6I= 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, 13 Apr 2012 17:59:12 +0200 id 00000000005DC039.000000004F884D50.00001C12 Message-ID: <4F884D50.8070705@tana.it> Date: Fri, 13 Apr 2012 17:59:12 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> <3719298.HRTXbQIGjb@scott-latitude-e6320> In-Reply-To: <3719298.HRTXbQIGjb@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:59:14 -0000 On Fri 13/Apr/2012 17:49:18 +0200 Scott Kitterman wrote: > On Friday, April 13, 2012 11:37:53 AM Alessandro Vesely wrote: >> On Fri 13/Apr/2012 11:04:51 +0200 Hector Santos wrote: >> >>> - 5321.HELO checking expected to have a failure factor with MUAs >> >> RFC 4408 seems to assume that there's no use in checking SPF on a >> submission server or during an authenticated SMTP session. This might >> be better clarified in SPFBIS. > > What needs to be clarified? That checking to see if a non-MTA is an authorized > MTA is not a good idea? That SPF is not designed to recognize affiliated MUAs. If it were an SMTP extension I'd expect it not to be appropriate for the submission protocol. I'm surprised this is not the case for RFC 4405. From spf2@kitterman.com Fri Apr 13 09:05: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 B228021F87F5 for ; Fri, 13 Apr 2012 09:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfClmjXCH7qj for ; Fri, 13 Apr 2012 09:05:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DBBF621F87F3 for ; Fri, 13 Apr 2012 09:05:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 17E2D20E40A3; Fri, 13 Apr 2012 12:05:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334333111; bh=W0Ff7Im/NvRu7ztfy+KehvwxzoWDP46zpB6IUuLTtZQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=EfCzHDGjF2ATgRFgKqAoyVZRKo/kl81hVBZEHRdYVHmkWRvaKZ0HtMq+ycKxXenCQ MAyM7iaBBUAwQTAg0mnPI6C7xI1iCwmbFyG69BUA1hr0IyGC8DSd/nlWMTYN49wCG2 Fc2WI8MXuKcIj4I9GwfIsNUNwjDHPszL4FVdUEW4= Received: from scott-latitude-e6320.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 ESMTPSA id F2FFA20E4083; Fri, 13 Apr 2012 12:05:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Apr 2012 12:05:09 -0400 Message-ID: <2230111.fUdp390bGt@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F884D50.8070705@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:05:13 -0000 On Friday, April 13, 2012 05:59:12 PM Alessandro Vesely wrote: > On Fri 13/Apr/2012 17:49:18 +0200 Scott Kitterman wrote: > > On Friday, April 13, 2012 11:37:53 AM Alessandro Vesely wrote: > >> On Fri 13/Apr/2012 11:04:51 +0200 Hector Santos wrote: > >>> - 5321.HELO checking expected to have a failure factor with MUAs > >> > >> RFC 4408 seems to assume that there's no use in checking SPF on a > >> submission server or during an authenticated SMTP session. This might > >> be better clarified in SPFBIS. > > > > What needs to be clarified? That checking to see if a non-MTA is an > > authorized MTA is not a good idea? > > That SPF is not designed to recognize affiliated MUAs. If it were an > SMTP extension I'd expect it not to be appropriate for the submission > protocol. I'm surprised this is not the case for RFC 4405. I don't think it's reasonable in an RFC to enumerate all the things a protocol does not do. RFC 4405 is just PRA selection. Anytime you have a message body you can do that selection. What you can't do is apply it to Sender ID from an MUA (just as you can't SPF). The one submission related practice that I have seen is a prospective check to determine if the message were to be sent from the submission server would it pass SPF. I think that can be useful, but I don't think it needs to be standardized. Scott K From johnl@iecc.com Fri Apr 13 09:38: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 97AAC11E8073 for ; Fri, 13 Apr 2012 09:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.992 X-Spam-Level: X-Spam-Status: No, score=-109.992 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr8Xv6Qad4UZ for ; Fri, 13 Apr 2012 09:38:30 -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 64C9311E8072 for ; Fri, 13 Apr 2012 09:38:29 -0700 (PDT) Received: (qmail 80684 invoked from network); 13 Apr 2012 16:38:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Apr 2012 16:38:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f885682.xn--hew.k1204; i=johnl@user.iecc.com; bh=d46X78RHEKeELT0UBdfkZ9cKFHtbcyDjvmRvBmk+noM=; b=SzgX7kWqFSgBiPQNQQlakBSkFilThFO5tZH7DOZavxbsUTyYr4fEiOzMidxaBhAw6MZsDRRYSDAVNj6FAIcZsiuEbZT4TE1GhXVQAtwh4uKDjDvRqZRBXV6vBm7FMxjg7eXWGSbQzajYFuLF8UAT0AYrKEs9thYPsIm7oI9RKzQ= 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=4f885682.xn--hew.k1204; olt=johnl@user.iecc.com; bh=d46X78RHEKeELT0UBdfkZ9cKFHtbcyDjvmRvBmk+noM=; b=HBaI8c9VrV7Gm6wMNnIxZYzU9U/yfdsNlCgM1rrO+vOFRl8mDT4ylvVLuwohA+Cw4piJi27CQJzpbabIwMX5cSwzIq54aZrEQv1BV/DB/CKNwVpCSW8zCy8ZexGc6zlo3Jd1vaMHln+e6Yg52qFtM7tadE7kZzwc6tnpdATlHis= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Apr 2012 16:38:03 -0000 Message-ID: <20120413163803.37501.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F846FE9.6040402@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:38:30 -0000 Hi there, catching up on mail after being mostly offline in a cottage in a sheep pasture in Iceland. The final version of EAI got rid of the two-address stuff, so the only issue I'm aware of is that the bounce address or EHLO in an EAI transaction can have the domain name coded in UTF-8 rather than as an A-label. The obvious fix is for 4408bis to say that if the domain being looked up is UTF-8, turn it into an A-label before doing the rest of the SPF processing. This transformation will always work for any valid message. R's, John From vesely@tana.it Fri Apr 13 10:34: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 42E5011E809D for ; Fri, 13 Apr 2012 10:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDewpKtfV6Sm for ; Fri, 13 Apr 2012 10:34:06 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6C93511E809C for ; Fri, 13 Apr 2012 10:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334338445; bh=vuGkYjsUjMcxzAZY6kpIjnLb8phFtBz3f/ks7xaF3gM=; l=1282; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=l+o96BE5qtD4EozgkhMMUhcf2BkzecJeKZ8R4tSjNdPvsU12Y1iMFlrygcA5cuNmm Sl68Mpj0wzcJha83eRbGqHWk56Zzd20+UKPgrb7rzp+Ql+m+dF3AhT71LqbpAnY3Jo 61Sy+Jj7oOBeAu26b/3hx+q6hiK91VJgdU0iiImo= 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, 13 Apr 2012 19:34:05 +0200 id 00000000005DC033.000000004F88638D.0000323B Message-ID: <4F88638D.9000401@tana.it> Date: Fri, 13 Apr 2012 19:34:05 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> <2230111.fUdp390bGt@scott-latitude-e6320> In-Reply-To: <2230111.fUdp390bGt@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:34:08 -0000 On Fri 13/Apr/2012 19:18:23 +0200 Scott Kitterman wrote: > On Friday, April 13, 2012 05:59:12 PM Alessandro Vesely wrote: > >> SPF is not designed to recognize affiliated MUAs. If it were an >> SMTP extension I'd expect it not to be appropriate for the >> submission protocol. I'm surprised this is not the case for RFC >> 4405. > > I don't think it's reasonable in an RFC to enumerate all the things > a protocol does not do. SUBMIT mentions IP address restrictions as a way to authorize submission. That's usually done by configuring (internal) valid IP addresses directly, rather than taking recourse to an "internal" SPF record. > RFC 4405 is just PRA selection. I meant the SMTP extension. > The one submission related practice that I have seen is a prospective check to > determine if the message were to be sent from the submission server would it > pass SPF. I think that can be useful, but I don't think it needs to be > standardized. Just to make that clear, you mean a submission server could apply SPF checks against its mailout's IP address in order to verify the Return-Path that the user configured? Such kind of action is described in http://tools.ietf.org/html/rfc6409#section-6.1 but without explicitly mentioning SPF as a tool. From hsantos@isdg.net Fri Apr 13 10:39: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 D776D11E8086 for ; Fri, 13 Apr 2012 10:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF6dQivcVEEK for ; Fri, 13 Apr 2012 10:39:09 -0700 (PDT) Received: from ntbbs.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2E17911E80AC for ; Fri, 13 Apr 2012 10:39:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7281; t=1334338740; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=vlZkiF4xD3BTEno/quQQjqpeS1k=; b=LsEnqMeZeVWWNv+6eUbo ONseMCSiBoQIfoX2pt28tSf816CYsjI+3ZRayjlp4aWOVt3n80um5IcTc0sVtX/T YFtMdftCmRSONaNbspVs65JZfMgg7MOFOhoXSHdiLOI6FmG102e5ZoNN2TW7tXi5 VN2zMg/TXXNQkD9DpbUqooQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 13:39:00 -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 v6.4.454.1) with ESMTP id 3245567421.25587.4784; Fri, 13 Apr 2012 13:38:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7281; t=1334338418; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=mBwdZ/O 95eIXj4QC3XTipMkuv7aa7KUVQ6GVdhQgTx8=; b=SZlF4KXIm5QMzlsh0tP7e1u ORHpH96BthZLjk4rR5FcC8VTJAj4eBAs2x+/Pawf6uQMCOt2j7nMoOlZXUOf5mx7 5Afyo7wPNAs5nfkQJ3WWxZWzMZPa3HcGhvTBTctRdeXaWMb/cuxo3xBkdBm4kaWm WWwaqeV5du/zQWfDMD94= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 13:33:38 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3844473315.1248.4880; Fri, 13 Apr 2012 13:33:37 -0400 Message-ID: <4F88648C.4020809@isdg.net> Date: Fri, 13 Apr 2012 13:38:20 -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: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> In-Reply-To: <4F87F3F1.7050503@tana.it> 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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:39:11 -0000 Alessandro Vesely wrote: > On Fri 13/Apr/2012 11:04:51 +0200 Hector Santos wrote: >> Ideally, we should perhaps consider SPFBIS having semantic >> describing the basic applicability framework of: >> >> o 5321.MAILFROM checking recommended for MUA to MDA paths. >> - 5321.HELO checking expected to have a failure factor with MUAs >> >> o 5321.HELO checking recommended for MTA to MTA paths. >> - 531.MAILFROM checking expected to have a failure factor after >> initial HOP > > RFC 4408 seems to assume that there's no use in checking SPF on a > submission server or during an authenticated SMTP session. This might > be better clarified in SPFBIS. +1. We can probably add to the above: o SPF is not required when the user or client is authenticated using current IETF standards and practices for SMTP. It has been a long time practice ISP/SMTP public port receiver to follow: - authentication is not required for local mail or locally hosted domain mail acceptance. - authentication is required for relaying mail. I alway had the mindset that all this extra JUNK was a waste, but it did begin to offer a problem resolving solution to address the high abuse of non-authenticated local mail reception we could no longer ignore and pass off to the sysop. But if the user was authenticated using the traditional methods, all the extra new stuff was really just big overhead with low payoff waste of time. The exception was the possible applicability to deal with the "Compromised Users" problem but IMV, that was a different problem with a different set of solutions which may include pattern recognition and excessive transaction monitoring. IP authentication was the first method ISP used with user's dialup PPP connections and eventually full time connectivity. It is still used as the only authentication necessary to relay mail and for the most part, with no restrictions on the addresses you use or even what RFC822/2822/5322 contained. Its was really none of our business! :) The real problem was the advent of the Roaming User which came in many forms and now the low cost, low overhead, automated User PC connectivity to the ISP network with IP authentication method was not reliable. The user was still allowed to send mail to local users anonymously, but you could not relay. With the "invention" of original Extended SMTP (RFC1993) and its extended service extensions with ESMTP AUTH (RFC2554) and SUBMIT (RFC2476), it began to offer a solution to the Roaming User problem, but there was still a dearth of supported MUAs. It was not a guarantee the user had a updated MUA and it was often a major support cost to document and train users to switch and/or configure MUA for ESMTP AUTH. If the user had an MUA that was not part of the top brand illustrations, he was SOOL! In fact, I recall long ago with my home ISP account, the ISP sending an email mandating a pending July cutoff date to force users switch to ESMTP AUTH ready MUAs. I recall their reasons were stupid - to address the spam problem. So it was predictable they would have a support problem. Within a month, a follow up email basically said "Never mind!" The ISP was experiencing a huge major help desk support cost problem when the practical reality was it wasn't necessary for most users who were IP authenticated via their connection and ESMTP AUTH was still new. Not every MUA supported it. There were other solutions available for the Roaming User issue too, like POP3 B4 SMTP which drastically help reduce the training cost associated with helping users setup ESMTP AUTH. >> The problem is that in the anonymous world, the SMTP receiver will not >> know if the client is a MUA or MTA > > SUBMIT servers do know. Why do you think that? Do you mean the idea of enforcement allowed by 4409 suggest the EHLO will be or MUST be valid and known? The modern problem is that the MUA still may not present a proper public domain name and with the advent of NATs, the fallback to using the domain IP literal could be incorrect. Users behind the NAT may present the private IP literal in their EHLO/HELO field which doesn't match the NAT connecting public IP address. So this is an example where EHLO/HELO can not be enforced via 4409. > Curiously, RFC 4405 claims to be appropriate for the submission > protocol too. The examples it gives of mobile and guest users look > rather archaic to me. I consider it overhead and waste of time to worry about all these SMTP augmented technology when user authentication is active or expected via 4409. > Are there still people who pick submission servers casually? Well, isn't prearrangement a basic presumption with a protocol or any client/server negotiation expecting authentication? Perhaps the question is do people pick ESP host casually? Either as one's default email account, an additional secondary account, like with gmail.com? Isn't all prearranged in some form? What would be interesting is how gmail.com allows for secondary accounts with for: 1) allowing gmail MTAs to send mail, or 2) allowing your own host to send the mail. I was interested in testing this for both SPF and DKIM so I had prepared a secondary account gmail.sant9442@winserver.com to see what needed to be done. When you choose #1, gmail.com is the primary source where the mail is created so it just sends mail out to the MDA (non-authenticated). But if you choose #2, it will ask for: SMTP Server: mail.winserver.com User Name: xxxxxxxxxxx Password: xxxxxxxxxxxxxxxxx In the first case, ESMTP AUTH is not active and gmail will use its MTA to MDA: IP <-- 209.85.212.178 5321.EHLO <-- public domain, mail-wi0-f178.google.com 5321.MAILFROM <-- your primary address, sant9442@gmail.com 5322.SENDER <-- your primary address, sant9442@gmail.com 5322.FROM <-- your secondary account, gmail.sant9442@winserver.com The only protection I have against any potential spoofing of my winserver.com property is to use ADSP/ATPS where I authorize the 3rd party gmail.com DKIM signing of my 5322.From Author Domain winserver.com. No ADSP/ATPS support. No protection. In the 2nd case, where ESMTP AUTH on port 587 is active with its MTA to MSA: IP <-- 209.85.212.178 5321.EHLO <-- public domain, mail-wi0-f178.google.com 5321.AUTH <-- local user account/pwd 5321.MAILFROM <-- secondary address, gmail.sant9442@winserver.com 5322.SENDER <-- NONE 5322.FROM <-- secondary account, gmail.sant9442@winserver.com With ESMTP AUTH authentication, SPF is skipped. But if SPF was to be applied, well, first gmail.com has no SPF record for the EHLO domain and for 5321.MAILFROM I would have to have a local white list filter rule like: ACCEPT IF %CIP% is "209.85.212.178" and %RDP% is "winserver.com" Of course, my MSA would not know what IPs are used by gmail, but since the session was authenticated, all this junk is now unnecessary. It should be noted GMAIL did not sign the MTA to MSA submitted message which I believe is proper to allow the MSA to do necessary signing if the message was going to be relayed. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From R.E.Sonneveld@sonnection.nl Fri Apr 13 10:52: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 E53CB21F8779 for ; Fri, 13 Apr 2012 10:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ3AQIw5Ecg0 for ; Fri, 13 Apr 2012 10:52:25 -0700 (PDT) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9FC21F85D6 for ; Fri, 13 Apr 2012 10:52:24 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M2F00600IZALQ00@hydrogen.mailtransaction.com>; Fri, 13 Apr 2012 19:52:22 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M2F00E2SIZ5OE00@hydrogen.mailtransaction.com>; Fri, 13 Apr 2012 19:52:22 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M2F00O4FIZ3YQ00@lion.sonnection.nl> for spfbis@ietf.org; Fri, 13 Apr 2012 19:52:15 +0200 (CEST) Message-id: <4F886976.7080800@sonnection.nl> Date: Fri, 13 Apr 2012 19:59:18 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: Alessandro Vesely References: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> In-reply-to: <4F884D50.8070705@tana.it> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1334339542; bh=ZZkZiPRNYQAClbgQtuu0Oh7ulOkqK8i3ru7tcnNZgaI=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=c7BK0EARCI/HxXbB5dEEG+WyfwUpWl2xWMUCw5S6LWm7Ye0SKJRy96rkZ8JadhtQb 3AvKrZ21fx/4sbOJ4c0A0H3T+fJXiT5RIExOeGH38O5Gb0godcfAx3uOfDP5bpSBJE OfquzZSpUfCcqNdkcun/v3+nC4ZXGSJvgpI8it6E= X-DKIM: OpenDKIM Filter v2.4.3 hydrogen.mailtransaction.com 0M2F00600IZALQ00 Cc: spfbis@ietf.org Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:52:26 -0000 On 4/13/12 5:59 PM, Alessandro Vesely wrote: > On Fri 13/Apr/2012 17:49:18 +0200 Scott Kitterman wrote: >> On Friday, April 13, 2012 11:37:53 AM Alessandro Vesely wrote: >>> On Fri 13/Apr/2012 11:04:51 +0200 Hector Santos wrote: >>> >>>> - 5321.HELO checking expected to have a failure factor with MUAs >>> RFC 4408 seems to assume that there's no use in checking SPF on a >>> submission server or during an authenticated SMTP session. This might >>> be better clarified in SPFBIS. >> What needs to be clarified? That checking to see if a non-MTA is an authorized >> MTA is not a good idea? > That SPF is not designed to recognize affiliated MUAs. If it were an > SMTP extension I'd expect it not to be appropriate for the submission > protocol. I'm surprised this is not the case for RFC 4405. I have to agree with Scott here. There are many many other situations where SPF is not designed for. I have several customers using hosted AS/AV services like Postini and MessageLabs and it makes no sense whatsoever performing SPF checks on any intermediate internal MSA's/MTA's between an internal mail client and the exterior AV/AS service. We're not going to document that either. /rolf From msk@cloudmark.com Fri Apr 13 10:55: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 9E69021F87FD for ; Fri, 13 Apr 2012 10:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBiRpHsA9lyv for ; Fri, 13 Apr 2012 10:55:16 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8866221F87F5 for ; Fri, 13 Apr 2012 10:55:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id xVvF1i0010ZaKgw01VvFKM; Fri, 13 Apr 2012 10:55:15 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=H85ZMpki c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=bq0z3-o-wY0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=xnbfpeM31JdxXCkbypUA:9 a=WR8HA7BqRZBQOxNyILsA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 10:55:14 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Meaning of SPF and domain authentication in general, was #12 Thread-Index: AQHNGY5hKzEj9N/ilUmurtc/fC62lJaZgIYA//+JE0A= Date: Fri, 13 Apr 2012 17:55:14 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280EFF1A@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> <4F886976.7080800@sonnection.nl> In-Reply-To: <4F886976.7080800@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334339715; bh=+iiQ+vis7Oei2wJxBMN79i9aSeotBZwxdHTOxtDFRQE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=T0hjq3Fz3hHhyy8sWL4O0tLaQeRJSWLyi7VVJ4OnLHBH2ngU3GpRpg7qhmMZiZRtq UANjdCgB78100r6WjwrYZyENgdaI6YV7v8d9vSRzJEDtOInZCmWHX747VZM9Z1duNB tLcuwdDueoO1jAwlwkzgOq42QLLMmCHHVKHmgDmM= Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:55:16 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Rolf E. Sonneveld > Sent: Friday, April 13, 2012 10:59 AM > To: Alessandro Vesely > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Meaning of SPF and domain authentication in general= , was #12 >=20 > On 4/13/12 5:59 PM, Alessandro Vesely wrote: > >>> RFC 4408 seems to assume that there's no use in checking SPF on a > >>> submission server or during an authenticated SMTP session. This > >>> might be better clarified in SPFBIS. > >> > >> What needs to be clarified? That checking to see if a non-MTA is an > >> authorized MTA is not a good idea? > > > > That SPF is not designed to recognize affiliated MUAs. If it were an > > SMTP extension I'd expect it not to be appropriate for the submission > > protocol. I'm surprised this is not the case for RFC 4405. >=20 > I have to agree with Scott here. There are many many other situations > where SPF is not designed for. I have several customers using hosted > AS/AV services like Postini and MessageLabs and it makes no sense > whatsoever performing SPF checks on any intermediate internal > MSA's/MTA's between an internal mail client and the exterior AV/AS > service. We're not going to document that either. +1, and also +1 to the point that we don't want to start down the path of d= ocumenting everything SPF isn't. -MSK From hsantos@isdg.net Fri Apr 13 12:35: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 DCC0111E80E0 for ; Fri, 13 Apr 2012 12:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrN6E4iUjNZr for ; Fri, 13 Apr 2012 12:35:02 -0700 (PDT) Received: from news.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DD98A11E80DB for ; Fri, 13 Apr 2012 12:35:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1309; t=1334345695; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gdWiatPkB3ur3GvtYihNSmizhNQ=; b=tlHDBeKOJF+502zuCT+9 3LITXWw7aUSWkDP9uqkRF0FRdj7EdFUpTkfwD/Di2WYsMk7GCQ/xCXmcqNx/sJz3 36ao9ooGKlJ8GSd4HK2YjPx1YtoFv5KKUTFuyLQ+ytaRLRx/l5vtf0+xX6mNdnWI e+HNZq5gRAL1RGXHAdp1RgI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 15:34: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 v6.4.454.1) with ESMTP id 3252522585.25587.5856; Fri, 13 Apr 2012 15:34:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1309; t=1334345370; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=eG8d6Fm EOym1jLyR2XhDt4n2ZPyzuAMP/78jGSs3F6M=; b=VAgtbD0thiSN+4LAPIKeTvY e5OtmcrRThutH30/TzNf9hDg1oL0QZZ4d3MdBAhyR9BPIitKYN/RThmuaA0dgUCj XLUVb+n9IJpqwzGRIqQOrXGgD69+TUNRdns3CMR876jRwdpFr3QXw6dbgJ0m2UWX 9/XZHNiH0wka+yDOy1uQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 15:29:30 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3851425862.1281.4536; Fri, 13 Apr 2012 15:29:29 -0400 Message-ID: <4F887FB4.2090605@isdg.net> Date: Fri, 13 Apr 2012 15:34: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: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> <4F886976.7080800@sonnection.nl> In-Reply-To: <4F886976.7080800@sonnection.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:35:03 -0000 Rolf E. Sonneveld wrote: > I have to agree with Scott here. There are many many other situations > where SPF is not designed for. I have several customers using hosted > AS/AV services like Postini and MessageLabs and it makes no sense > whatsoever performing SPF checks on any intermediate internal > MSA's/MTA's between an internal mail client and the exterior AV/AS > service. We're not going to document that either. I believe it should be documented to HELP minimize unnecessary overhead on the network where it is not required. SPF is one of those heavy DNS-based protocols where its PRUDENT to be aware of network optimization insights simply because it has a low payoff with a high NXDOMAIN yield in blind application. Is it really so obvious that it doesn't need to be stated? It might be obvious to the active WG participants and next editors of the spec, but I suggest it may not be obvious to the general future reader and implementor. Besides the specs is already filled with what we believe to be obvious, such as Parallel Queries concepts with the obvious and natural expectation, that your favorite API already supports it and therefore its obvious that all others do as well. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Fri Apr 13 12:40: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 86AEB11E80F1 for ; Fri, 13 Apr 2012 12:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwbHxer2C6LM for ; Fri, 13 Apr 2012 12:40:52 -0700 (PDT) Received: from news.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AF80511E80E5 for ; Fri, 13 Apr 2012 12:40:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=673; t=1334346050; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VJBQCBydXygqKlWGIePgoq0lIr0=; b=VElxsJTLdDl4vTjBl2qo tFNagkzSwL7gG4kmFtBk8ZbAYKXy4hMHFM2QbiyvipCCHOBMVaqhwJ6GsgHnG4eL zPD5Uls4mtpOFi/kNIyGsKnD1IK5yRlKzaD644jNfVUAH+MxElBpzwx/bG8Hwmg6 MqomwexN7xMbpHUFPS9gwt4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 15:40:50 -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 v6.4.454.1) with ESMTP id 3252877659.25587.3680; Fri, 13 Apr 2012 15:40:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=673; t=1334345728; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RIMlHdE ge9xYeSnkCOkY0sGKJ6j4RmKVADIIUpvQjR0=; b=ocfgA5+ARA9eIS2LmyhJiDN BIeAL9haj6RkXox1GSwxv6ZUK4OzhJ5GO5KwMYFm1mhRx++NPcD4gwORbpaoGDbA vdlNRkW9nGjo2a0nHFs9OA+RnNOC/Mv4IOZvAEXcDu9hGTICkG7bVcXTLGUsnMRs gX/6CjRhi/z+8kY1inE0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 15:35:28 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3851783518.1284.5152; Fri, 13 Apr 2012 15:35:27 -0400 Message-ID: <4F88811A.1080600@isdg.net> Date: Fri, 13 Apr 2012 15:40:10 -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: <20120413163803.37501.qmail@joyce.lan> In-Reply-To: <20120413163803.37501.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:40:52 -0000 John Levine wrote: > Hi there, catching up on mail after being mostly offline in a cottage > in a sheep pasture in Iceland. > > The final version of EAI got rid of the two-address stuff, so the only > issue I'm aware of is that the bounce address or EHLO in an EAI > transaction can have the domain name coded in UTF-8 rather than as an > A-label. > > The obvious fix is for 4408bis to say that if the domain being looked > up is UTF-8, turn it into an A-label before doing the rest of > the SPF processing. This transformation will always work for > any valid message. +1 -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From ajs@anvilwalrusden.com Fri Apr 13 12:48: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 D612021F880B for ; Fri, 13 Apr 2012 12:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvsMA70j3KfE for ; Fri, 13 Apr 2012 12:48:00 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2A521F880D for ; Fri, 13 Apr 2012 12:48:00 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id E51B51ECB41C for ; Fri, 13 Apr 2012 19:47:58 +0000 (UTC) Date: Fri, 13 Apr 2012 15:47:57 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120413194751.GF46538@mail.yitter.info> References: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> <4F886976.7080800@sonnection.nl> <4F887FB4.2090605@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F887FB4.2090605@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:48:01 -0000 No hat. On Fri, Apr 13, 2012 at 03:34:12PM -0400, Hector Santos wrote: > Is it really so obvious that it doesn't need to be stated? If we used this standard for everything about the DNS that isn't so obvious, every RFC that uses the DNS would be 500 pages long. Those who are arguing for inclusion: What is the reason this _does_ need to be stated? As various people are rumoured to have said[1], "Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away." Best, A [1]I believe the rumour about Saint-Exupery, myself. -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Fri Apr 13 12:56: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 D1BB511E80F6 for ; Fri, 13 Apr 2012 12:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsdxbdVvIcfK for ; Fri, 13 Apr 2012 12:56:04 -0700 (PDT) Received: from news.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B3C2611E80EF for ; Fri, 13 Apr 2012 12:56:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2100; t=1334346960; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=RCrpqY4FDZDfK4NLaFTzKKgYwvg=; b=aKSEJM1xkd4a5F6gU0qq SvQ2FBbnj6UINErIpsfe3JYrnR56zoJyFye1544ytcV5xZ0FQdKuJskCWyo92W6J wxqYtuVSaWqNOeJJfctsRp/aVDCn13ukR3PBmrQQOpHqGBMsIaTrhjG4KzVm4y3j JpWvKB8M0x4ncwUKO24z4TI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 15:56:00 -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 v6.4.454.1) with ESMTP id 3253787769.25587.2476; Fri, 13 Apr 2012 15:55:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2100; t=1334346637; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=dzpt49i Maj5WtrGwJgaFZntucXHHDKQmIPEena5/nCo=; b=BYrW6aT4ltmxeSC0JbaJcrc tSeQl5aA8NWbHB9AlY1yCEw9UMmBjLqRTf7TLPR05sb4y25339rh0AG4I9eS20CL s91c5+cS9jyGpcZTdx36KYiKFggHh79U7ECrQMsSuwp1jQHJTQqHcchQgXIXhxyw 0WxAEm8act7paQyL3jsE= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 15:50:37 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3852692721.1288.6280; Fri, 13 Apr 2012 15:50:36 -0400 Message-ID: <4F8884A7.6080404@isdg.net> Date: Fri, 13 Apr 2012 15:55:19 -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: <20120324090349.15462.qmail@joyce.lan> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> <2230111.fUdp390bGt@scott-latitude-e6320> In-Reply-To: <2230111.fUdp390bGt@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:56:05 -0000 Scott Kitterman wrote: >> Alessandro stated: >> That SPF is not designed to recognize affiliated MUAs. If it were an >> SMTP extension I'd expect it not to be appropriate for the submission >> protocol. I'm surprised this is not the case for RFC 4405. > > I don't think it's reasonable in an RFC to enumerate all the things a protocol > does not do. Why not? After all, if its not written, you (speaking in general) will mostly likely remind people when the do begin to do things the protocol did not expect in unwritten terms. Thats half the problem now. no? > RFC 4405 is just PRA selection. Anytime you have a message body you can do > that selection. What you can't do is apply it to Sender ID from an MUA (just > as you can't SPF). Not following. Can you elaborate it? My view, 4405 is not complex. Its just the exposure of the PRA at the SMTP level to help preempt the payload download. I think what is forgotten when all this was being put together the idea of a SMTP receiver doing DATA level shimming and call outs was still in its infancy. The larger scale you were, the less odds you were today dynamic DATA level processing. So it was important to optimize the SPF/SIDF protocol with the SUBMITTER extended SMTP option. It was documented and patented as an necessary OPTIMIZATION to help avoid payload overheads when in FACT over 80% of the transactions the PRA was the same as the 5321.MAILFROM and it was NOT desirable to find out that wasted fact by accepting the message first. Get it? > The one submission related practice that I have seen is a prospective check to > determine if the message were to be sent from the submission server would it > pass SPF. I think that can be useful, but I don't think it needs to be > standardized. +1, but I don't view it as a standardization, but rather providing engineering design insights. Perhaps as an possible answer to the "Compromised User" question. Can it help this particular real potential problem? -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Fri Apr 13 12: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 6D04121F84CD for ; Fri, 13 Apr 2012 12:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJg6eXzeTxSK for ; Fri, 13 Apr 2012 12:57:01 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9734E11E80EF for ; Fri, 13 Apr 2012 12:56:48 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id xXwo1i0010as01C01XwouF; Fri, 13 Apr 2012 12:56:48 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=H85ZMpki c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=bq0z3-o-wY0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=m36Xy8ywlLei8KPz1-UA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 12:56:47 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Meaning of SPF and domain authentication in general, was #12 Thread-Index: AQHNGY5hKzEj9N/ilUmurtc/fC62lJaZgIYAgAAahACAAAPXgP//jQdQ Date: Fri, 13 Apr 2012 19:56:46 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F0A59@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> <4F886976.7080800@sonnection.nl> <4F887FB4.2090605@isdg.net> <20120413194751.GF46538@mail.yitter.info> In-Reply-To: <20120413194751.GF46538@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334347008; bh=ZaYxMc97VuS7v3pYwMD8Naq6uS3CYVQHiVOgqqeOMts=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=s4rlXH9l/yVnFkRjgNgCI1it+AU9qE4T0VmZDLjaNSCgZYoT5mKQnSDK8MPJyXwGe FQUHSLbAfws77KAUFBMWIN+42SKoOKt+EVthPpB7WE5WJTXInrMGGDlev9vIAG5uzO ck6WrRwUkT1nDEvdUklcyaEfar9Gv8zAFVnWh1M0= Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:57:02 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Friday, April 13, 2012 12:48 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Meaning of SPF and domain authentication in general= , was #12 >=20 > [1]I believe the rumour about Saint-Exupery, myself. The one about public suffix being his idea? From hsantos@isdg.net Fri Apr 13 13:13: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 4DB4821F85F0 for ; Fri, 13 Apr 2012 13:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVqTaUU5DZLw for ; Fri, 13 Apr 2012 13:13:15 -0700 (PDT) Received: from news.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 87F0821F85DF for ; Fri, 13 Apr 2012 13:13:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1783; t=1334347990; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=dZqOKNnHGCWIYX/asZsKiS+IkWY=; b=HpdNHiTwbb3VGFeKLoDS BbGRyYdxpGLA7x/2LvyJwDb3z1DPD21RctdxQ9icXdt/hDW1MGtXFgOMyMLymT30 IfLOXXq+oejqcoFD3qiHYMo2WYhWeRhOBKasRePSUDlrY5DEo6OZvGZP5Q843f15 V0nqWvZr5u2JYiDgci13eSE= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 16:13: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 v6.4.454.1) with ESMTP id 3254817984.25587.3512; Fri, 13 Apr 2012 16:13:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1783; t=1334347668; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qQNP1Ec /jbJmaks/IIOJTEcN5Tk+TDQu1uJ4xQRgB44=; b=W59YW1dNInlmQFqRw40N6EQ o+pAto9SOZes1XmM32z2is6DGFyOjF+u0VHtAt/qYpBimDiBr+zGaR05sfjevKXt IEItqvKSp5J0otmns1r3xSGrW1DC3xELevnpPKqSffeyCzSpK0QdXkSQ6PwR2dl8 q8WsrlGzbBBcaSBjRCCo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 16:07:48 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3853724221.1290.3240; Fri, 13 Apr 2012 16:07:48 -0400 Message-ID: <4F8888AF.3020503@isdg.net> Date: Fri, 13 Apr 2012 16:12:31 -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: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> <4F886976.7080800@sonnection.nl> <4F887FB4.2090605@isdg.net> <20120413194751.GF46538@mail.yitter.info> In-Reply-To: <20120413194751.GF46538@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:13:16 -0000 Sure, I can see your point Andrew, but IME, I believe rhetorical philosophy as a general application isn't always applicable across the board. As you are well tuned to the fact, it may apply as a general principle but there are cases where the motto "Being Specific is Terrific" does offers a faster grasp in understanding. Background: I view the RFC as a blend of two phases of the software engineering process with a functional and technical specification reaching a wider audience of multiple disciplines. Hence therefore, I suggest catering to the non-technical layman (i.e. management, tech sales, suppport) per se, in areas that less understood and only more obviously understood by the singular audience of technical people is all important. I personally find RFC having too much investment in presumed understanding of all its writes about. PS: I spent 10 years in the corporate (Westinghouse Electric) and federal documentation world making sure engineers, management and politicians understood what was presented. Andrew Sullivan wrote: > No hat. > > On Fri, Apr 13, 2012 at 03:34:12PM -0400, Hector Santos wrote: > >> Is it really so obvious that it doesn't need to be stated? > > If we used this standard for everything about the DNS that isn't so > obvious, every RFC that uses the DNS would be 500 pages long. > > Those who are arguing for inclusion: What is the reason this _does_ need > to be stated? As various people are rumoured to have said[1], > "Perfection is achieved not when there is nothing left to add, but > when there is nothing left to take away." > > Best, > > A > > [1]I believe the rumour about Saint-Exupery, myself. > > -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From spf2@kitterman.com Fri Apr 13 13:37: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 548C021F8484 for ; Fri, 13 Apr 2012 13:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WALi010ja1Rk for ; Fri, 13 Apr 2012 13:37:02 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9C96E21F8534 for ; Fri, 13 Apr 2012 13:37:02 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0182220E40A3; Fri, 13 Apr 2012 16:37:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334349422; bh=6ma90I/chNwmDrb0wcoByWuAWWSQEC5g8NYae/n547g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=B+QS+Gm1As5/PO9zfXRtO7nkLDVaW83BFfSRo0Ev0ysWsEImIxwkECmpjH+iZSvYG cBzBNMtlduiQO5j1rAY/ORQjmTSjYsMpi1917yQUzWNVzoE+tgpUWYqqhdV5+4mwcy nE5wQdbiTHnxopSJkhTtWqPRB8xq+qCw3/yEG8WU= Received: from scott-latitude-e6320.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 ESMTPSA id D8AC620E4083; Fri, 13 Apr 2012 16:37:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Apr 2012 16:37:01 -0400 Message-ID: <1592914.fLmzuDM8PQ@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F88638D.9000401@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <2230111.fUdp390bGt@scott-latitude-e6320> <4F88638D.9000401@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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:37:03 -0000 On Friday, April 13, 2012 07:34:05 PM Alessandro Vesely wrote: > On Fri 13/Apr/2012 19:18:23 +0200 Scott Kitterman wrote: > > On Friday, April 13, 2012 05:59:12 PM Alessandro Vesely wrote: > >> SPF is not designed to recognize affiliated MUAs. If it were an > >> SMTP extension I'd expect it not to be appropriate for the > >> submission protocol. I'm surprised this is not the case for RFC > >> 4405. > > > > I don't think it's reasonable in an RFC to enumerate all the things > > a protocol does not do. > > SUBMIT mentions IP address restrictions as a way to authorize > submission. That's usually done by configuring (internal) valid IP > addresses directly, rather than taking recourse to an "internal" SPF > record. > > > RFC 4405 is just PRA selection. > > I meant the SMTP extension. It does say it's not relevant to submission. I don't agree it's necessary to say that for SPF. > > The one submission related practice that I have seen is a prospective > > check to determine if the message were to be sent from the submission > > server would it pass SPF. I think that can be useful, but I don't think > > it needs to be standardized. > > Just to make that clear, you mean a submission server could apply SPF > checks against its mailout's IP address in order to verify the > Return-Path that the user configured? Such kind of action is > described in http://tools.ietf.org/html/rfc6409#section-6.1 but > without explicitly mentioning SPF as a tool. Yes. that's what I mean. I'd say 6409 6.1 is describing what should be done. What I mention is is one method for how to go about it. It has no interoperability or protocol implicaitons, so I don't think it needs standardization. Scott K From spf2@kitterman.com Fri Apr 13 13:51: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 C512921F871D for ; Fri, 13 Apr 2012 13:51: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ccxf+-OjvXYY for ; Fri, 13 Apr 2012 13:51:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3E321F86EF for ; Fri, 13 Apr 2012 13:51:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D559F20E40A3; Fri, 13 Apr 2012 16:51:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334350289; bh=60XATcT+mucH3vNofqaDHJ2PAApnVP786zR98bMdSMA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=T9Zu0Q3Dbk2fjXpfuvnNRVGZiTFtdm5BIkAwm7Pv7MRYNq3KImKf2Z1yf/Nlqqh3Q C6Bprvd8iTuSF+WLf6+BdYPuAQBEiWYD7nrRxAGlhExUip/OZslYM+UeuJuDaToZyL dIQ6D6yHaLQ99w2VHjF92glJuGRfIjlxHtcBIdFY= Received: from scott-latitude-e6320.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 ESMTPSA id BB4D620E4083; Fri, 13 Apr 2012 16:51:29 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Apr 2012 16:51:29 -0400 Message-ID: <10035218.VxSKd6zvrx@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8884A7.6080404@isdg.net> References: <20120324090349.15462.qmail@joyce.lan> <2230111.fUdp390bGt@scott-latitude-e6320> <4F8884A7.6080404@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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:51:42 -0000 On Friday, April 13, 2012 03:55:19 PM Hector Santos wrote: > Scott Kitterman wrote: > >> Alessandro stated: > >> That SPF is not designed to recognize affiliated MUAs. If it were an > >> SMTP extension I'd expect it not to be appropriate for the submission > >> protocol. I'm surprised this is not the case for RFC 4405. > > > > I don't think it's reasonable in an RFC to enumerate all the things a > > protocol does not do. > > Why not? After all, if its not written, you (speaking in general) > will mostly likely remind people when the do begin to do things the > protocol did not expect in unwritten terms. Thats half the problem > now. no? > > > RFC 4405 is just PRA selection. Anytime you have a message body you can > > do > > that selection. What you can't do is apply it to Sender ID from an MUA > > (just as you can't SPF). > > Not following. Can you elaborate it? I had 4405 and 4407 reversed in my head when I wrote that. > My view, 4405 is not complex. Its just the exposure of the PRA at the > SMTP level to help preempt the payload download. I think what is > forgotten when all this was being put together the idea of a SMTP > receiver doing DATA level shimming and call outs was still in its > infancy. The larger scale you were, the less odds you were today > dynamic DATA level processing. So it was important to optimize the > SPF/SIDF protocol with the SUBMITTER extended SMTP option. It was > documented and patented as an necessary OPTIMIZATION to help avoid > payload overheads when in FACT over 80% of the transactions the PRA > was the same as the 5321.MAILFROM and it was NOT desirable to find out > that wasted fact by accepting the message first. Get it? There is no such thing as the SPF/SIDF protocol. They are separate things. The only technical relationship they have is the unfortunate design decision by Microsoft to re-purpose SPF records for SIDF. > > The one submission related practice that I have seen is a prospective > > check to determine if the message were to be sent from the submission > > server would it pass SPF. I think that can be useful, but I don't think > > it needs to be standardized. > > +1, but I don't view it as a standardization, but rather providing > engineering design insights. Perhaps as an possible answer to the > "Compromised User" question. > > Can it help this particular real potential problem? It can, but I don't think it's related to the work of this group. Scott K From msk@cloudmark.com Fri Apr 13 14:35: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 D995F11E8135 for ; Fri, 13 Apr 2012 14:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33nk61M1+h4v for ; Fri, 13 Apr 2012 14:35:42 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0680C11E8134 for ; Fri, 13 Apr 2012 14:35:42 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id xZbl1i0010ZaKgw01Zbmip; Fri, 13 Apr 2012 14:35:46 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=SOLApZTH c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=nDqy8gWoOMMW8rBso-sA:9 a=kb5X5y3nGYdYM2tEIOgA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 14:35:30 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: Deployment guide Thread-Index: AQHNGb1Yxdn9ZzJMIkCy/LlPa+vGiA== Date: Fri, 13 Apr 2012 21:35:29 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F1346@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <2230111.fUdp390bGt@scott-latitude-e6320> <4F8884A7.6080404@isdg.net> <10035218.VxSKd6zvrx@scott-latitude-e6320> In-Reply-To: <10035218.VxSKd6zvrx@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334352946; bh=Zl4Jm8PRAm/eLNIejUc9hplYs24Wzd837SyMZQV9WJk=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bGMXkkj3muCmnsD5Y7pkdpRmgu05HW9btZ3U7A93e/i5Dxcp/sqUHmidsgueAc2Ek frrarIrjx+VUGy66veee4m++az9TjTW7lVbkocRgN1h4JgcVstfnhYkB+p78zithmt x59sZ8LCOTnxDMbUw7RGwr9FkW6OdtBxsZpuCPQw= Subject: [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: Fri, 13 Apr 2012 21:35:43 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Scott Kitterman > Sent: Friday, April 13, 2012 1:51 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Meaning of SPF and domain authentication in=20 > general, was #12 >=20 > > > The one submission related practice that I have seen is a=20 > > > prospective check to determine if the message were to be sent from=20 > > > the submission server would it pass SPF. I think that can be=20 > > > useful, but I don't think it needs to be standardized. > > > > +1, but I don't view it as a standardization, but rather providing > > engineering design insights. Perhaps as an possible answer to the=20 > > "Compromised User" question. > > > > Can it help this particular real potential problem? >=20 > It can, but I don't think it's related to the work of this group. Once again, I think a deployment document might ultimately help. This is w= here stuff that isn't part of the protocol definition itself would go. If there's some small amount of pedagogy, that can probably go in an append= ix of RFC4408bis. If the working group actually has quite a lot to say, on= more than one or two topics, we should consider a separate document. I know that's not in our current charter, but I'd like to do some investiga= tion into whether or not we could/should do this after 4408bis is done, as = part of a re-charter. So if the chairs don't mind: Please reply to this (n= ew) thread if you have any topics you'd like to see us discuss somewhere th= at would qualify not as protocol specification, but as implementation and/o= r deployment advice. Based on the volume and content, we can decide whethe= r or not this is something we should do, and where. Either way, this is not work we should actually plan on starting until afte= r RFC4408bis is basically done. But I think asking this question now and c= ollecting ideas will help decide (a) what goes into RFC4408bis, and (b) whe= ther or not we should seek to add this as a deliverable when/if we re-chart= er. -MSK From johnl@taugh.com Fri Apr 13 14:58: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 C566A11E814C for ; Fri, 13 Apr 2012 14:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2fUkVYVO+OL for ; Fri, 13 Apr 2012 14:58:33 -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 D02FA11E80C4 for ; Fri, 13 Apr 2012 14:58:27 -0700 (PDT) Received: (qmail 34119 invoked from network); 13 Apr 2012 21:58:26 -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=8546.4f88a182.k1204; bh=oKKN10bDGtQGynqCpwzoduJfo5sJToezfjkQ1tqTNRs=; b=lqbAx6RjYBFV4gva5Jqqc6Ukad/meX3ibcEmS3mTllEHS6wkzbuv85vQ6MJix2T4B7v4bk8Zpr/vb+k7kxb7Jdxkn9y3Q69RScLdxFeExPWVVPkVvFoxQM086/SWXLh5zEoxRfDkz6HtYz7sWNgKt0jmWU2ovR9KcMTmLdyZuxw= 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=8546.4f88a182.k1204; bh=oKKN10bDGtQGynqCpwzoduJfo5sJToezfjkQ1tqTNRs=; b=HEh2NrcEF4GTQZ543tITYxMQhy/TM7M3N6T0RTqwC0TqLHpn3b/2hr4cXvlt6ejVtEOtwKMLH5AFYiZvK/jGTwiNwIOrwjz+z3csV/ef+eGLMAeSo5iY68XBemi8gSIRL/uGwsL96mdv1Au5Bi04ChcL+a8BAmkmBc1Wr31cCP8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 13 Apr 2012 21:58:04 -0000 Date: 13 Apr 2012 21:58:23 +0000 Message-ID: From: "John R Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFF59@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280EFF59@exch-mbx901.corp.cloudmark.com> 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] draft-ietf-spfbis-experiment-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:58:33 -0000 A few minor points: In section 4, probably worth mentioning that SPF can be applied before DATA, which is the main reason it can be cheaper to use than S-ID. In 5.1 item 6, in the second sentence I'd say "Further, few if any web-based DNS configuration tools support type 99 records." which is the truth. The most popular is Godaddy whose SPF wizard creates a type 16 record. Appendix A, beginning of 2nd pp: "At the time SPF was developed, ... " otherwise sounds like you mean at the time it was brought to the IETF. In the penultimate paragraph of Appendix A, also say something about making it easier to add new types to provisioning tools. Personally, I think that's a bigger hurdle than fixing the firewalls, since there's no incentive to fix the firewalls if nobody is using the types they mishandle. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From dotis@mail-abuse.org Fri Apr 13 15:24: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 46D6D21F8740 for ; Fri, 13 Apr 2012 15:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjrx9hbm505g for ; Fri, 13 Apr 2012 15:24:46 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id A187821F873A for ; Fri, 13 Apr 2012 15:24:46 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 2EC901740491 for ; Fri, 13 Apr 2012 22:24:46 +0000 (UTC) Message-ID: <4F88A7AD.1010902@mail-abuse.org> Date: Fri, 13 Apr 2012 15:24:45 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120413163803.37501.qmail@joyce.lan> In-Reply-To: <20120413163803.37501.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:24:47 -0000 On 4/13/12 9:38 AM, John Levine wrote: > Hi there, catching up on mail after being mostly offline in a cottage > in a sheep pasture in Iceland. > > The final version of EAI got rid of the two-address stuff, so the > only issue I'm aware of is that the bounce address or EHLO in an EAI > transaction can have the domain name coded in UTF-8 rather than as an > A-label. > > The obvious fix is for 4408bis to say that if the domain being looked > up is UTF-8, turn it into an A-label before doing the rest of the SPF > processing. This transformation will always work for any valid > message. Dear John, This is a common mistake clarified in Section 3.7.1 of RFC6531. http://tools.ietf.org/html/rfc6531#section-3.7.1 The EAI concern only affects bounce addresses and not EHLO/HELO. It is not clear how a change in processing or EAI awareness is signaled. Clearly when the EHLO/HELO identity is identified as a basis for a check, the EAI issue can be ignored. But when the bounce address results in a failure that might occur as a result of previously unspecified A-label conversions being omitted, how is EAI awareness (A-label conversion) indicated? Secondly, it seems important to also indicate SPF Pass results conveyed to users may also expose them to various look-alike phishing vulnerabilities. When this issue was raised in the DKIM WG, it was also pointed out that DNS operates with any UTF-8 query string and that A-label conversion without additional checks will not prevent some exploitation methods. Regards, Douglas Otis From hsantos@isdg.net Fri Apr 13 16:12: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 1CDE111E80C2 for ; Fri, 13 Apr 2012 16:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRTK-rKjTNEc for ; Fri, 13 Apr 2012 16:12:20 -0700 (PDT) Received: from mail.catinthebox.net (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0413921F863D for ; Fri, 13 Apr 2012 16:12:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1070; t=1334358730; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Y7tGpDTU5dbj3Ew8/6ZIdzs1icM=; b=ssv6W9Fk4H92FJw/Ux2g PN0L+WFtYn0RLx2cyAE862lDvw9JfAFkrkBJcmen32PSsa6tw7B7bdLE7NnPZC4W iDwn1H3STYl0mto0w3+mGc/yf/7ZT6o0P7U8MtFIz9sjQdbUSfSXGspvQRpbJ7nU zkSeE8eUxshWKWaogbSGwqo= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 19:12:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3265558247.25587.1776; Fri, 13 Apr 2012 19:12:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1070; t=1334358405; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ZFmbbUp clV0afk7bQqjMKbx9qRpkoawDU5i7urE1bJ0=; b=RY6aKWNWoadd1rSXyvd5yNq Qjq2+JVgh5ayIxLPKEHqxeixfttuHZ5Ql14srS3zRYKJQt0WRPqo3wjNAbyuPiuS uwXx34pVxyODQNwz+VL09VFBmlTGFGvT+34qN/27wAKrHD1OSQ7A0+t6/yhxr8qN xHknifsgfneGmpDqp/e0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 19:06:45 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3864460846.1309.5636; Fri, 13 Apr 2012 19:06:44 -0400 Message-ID: <4F88B2A2.1@isdg.net> Date: Fri, 13 Apr 2012 19:11:30 -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: <20120324090349.15462.qmail@joyce.lan> <2230111.fUdp390bGt@scott-latitude-e6320> <4F8884A7.6080404@isdg.net> <10035218.VxSKd6zvrx@scott-latitude-e6320> In-Reply-To: <10035218.VxSKd6zvrx@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 23:12:21 -0000 Scott Kitterman wrote: > > There is no such thing as the SPF/SIDF protocol. They are separate things. Well Scott, I understand the sentiment but it was the genesis, purpose and reason why there was a 2006 IETF conclusion to explore the integrated co-existence of the multiple protocols. > The only technical relationship they have is the unfortunate design decision > by Microsoft to re-purpose SPF records for SIDF. Ok good, thats a start. There is conflict with it. Spell it out. Honestly, I would like to know why 4407 was a bad idea. >> +1, but I don't view it as a standardization, but rather providing >> engineering design insights. Perhaps as an possible answer to the >> "Compromised User" question. >> >> Can it help this particular real potential problem? > > It can, but I don't think it's related to the work of this group. I think it is perhaps from the standpoint to point out that it MAY NOT solve the Compromised User Problem. Or could it? -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From johnl@iecc.com Fri Apr 13 16:26: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 8AAD621F86A6 for ; Fri, 13 Apr 2012 16:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.048 X-Spam-Level: X-Spam-Status: No, score=-111.048 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULU2XOIuMZLA for ; Fri, 13 Apr 2012 16:25: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 6FD6C21F86A4 for ; Fri, 13 Apr 2012 16:25:59 -0700 (PDT) Received: (qmail 47653 invoked from network); 13 Apr 2012 23:25:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Apr 2012 23:25:58 -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=4f88b605.xn--3zv.k1204; i=johnl@user.iecc.com; bh=Hn8BPC94JN1yebTzMRUNfcl9CbuI9ZBTVQiYh1famGw=; b=HZ23UPAPhaP4Hau+7y+s2rbTPuj2VebPcMJqC38bcdVbS5T8mgcOZpTv+ISm9dsXEQpkhOBqBnIN+0QT13ddE71JCyoaQr58dnI94WktVfrEnEzmZxUnbcKXQ6VKToWaPKoBkuMmWBSsaOiUN3jbCaQ+ya3p6gznh9fb0XbNyWg= 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=4f88b605.xn--3zv.k1204; olt=johnl@user.iecc.com; bh=Hn8BPC94JN1yebTzMRUNfcl9CbuI9ZBTVQiYh1famGw=; b=WnLrMofz3JUDhjerfGOKPx+Njci70lXS9mHqkma+DHLtO6H0MElCnpY6bY6Il4tT2CnIcxOmGYg0Bi1pu1rq+HroM3iKAMG9RCzklXfdfR54EI7ghUfCa8Ugt6KRCA4tI9vbBr3DF0s/9YAjPl2UNChNTB9444Ncnrju3Ss/QIE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Apr 2012 23:25:35 -0000 Message-ID: <20120413232535.48205.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F88A7AD.1010902@mail-abuse.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dotis@mail-abuse.org Subject: Re: [spfbis] New old issue: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 23:26:00 -0000 >> The obvious fix is for 4408bis to say that if the domain being looked >> up is UTF-8, turn it into an A-label before doing the rest of the SPF >> processing. This transformation will always work for any valid >> message. >Dear John, > >This is a common mistake clarified in Section 3.7.1 of RFC6531. >http://tools.ietf.org/html/rfc6531#section-3.7.1 > >The EAI concern only affects bounce addresses and not EHLO/HELO. Oh, of course. You can't use UTF-8 until you've checked the response to EHLO and seen if the server supports EAI. Nonetheless, the fix is still right, turn UTF-8 domains into A-labels. Any UTF-8 that can't be turned into an A-label isn't a valid domain, so you can do whatever SPF does with invalid domains now. R's, John From dotis@mail-abuse.org Fri Apr 13 16:49: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 3C31111E814C for ; Fri, 13 Apr 2012 16:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e0wwlojks6j for ; Fri, 13 Apr 2012 16:49:04 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id BE32111E814A for ; Fri, 13 Apr 2012 16:49:04 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id AA8471740485 for ; Fri, 13 Apr 2012 23:49:04 +0000 (UTC) Message-ID: <4F88BB70.3040307@mail-abuse.org> Date: Fri, 13 Apr 2012 16:49:04 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> In-Reply-To: <4F875085.1060702@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 23:49:05 -0000 On 4/12/12 3:00 PM, Hector Santos wrote: > My main point in all this is that we should keep a perspective of how > and when SPF is applied within the end to end transport path. helo > checking ideas is not always applicable in the same way Mail From > checking is not always applicable. Ideally, we should perhaps > consider SPFBIS having semantic describing the basic applicability > framework of: > > o 5321.MAILFROM checking recommended for MUA to MDA paths. > - 5321.HELO checking expected to have a failure factor with MUAs > > o 5321.HELO checking recommended for MTA to MTA paths. > - 531.MAILFROM checking expected to have a failure factor after > initial HOP > > The problem is that in the anonymous world, the SMTP receiver will not > know if the client is a MUA or MTA, when 5321.HELO or 5321.MAILFROM > checking should be done and in what order and how much confidence > weight should be considered to each or when one should override the > other. Dear Hector, This concerns MSAs where your network, your rules apply. IMHO, the role most have for SPF is for unauthenticated (port 25) traffic between different ADMDs. The RFC5321 is not bound to a specific ADMD which is where SPF framework fails. SPF does not permit valid operations of http://tools.ietf.org/html/rfc5321#section-6.1 and http://tools.ietf.org/html/rfc1123#section-5.2.6 which is why many ignore "-all" and this represents a serious conflict that must be resolved. It is reasonable to reject failures based upon HELO/EHLO identities as this avoids the issues with RFC1123 and RFC5321. ADMDs unable to properly configure their greeting or define their sources with a protocol that permits more than 100 DNS transactions is absurd when checking EHLO/HELO identities. However, it is not reasonable to expect even this number of DNS transactions will be able to accommodate the entirety of all possible reverse-paths as email is currently defined. Regards, Douglas Otis From hsantos@isdg.net Fri Apr 13 19:13: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 7646E11E8094 for ; Fri, 13 Apr 2012 19:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WOX5a7ClMES for ; Fri, 13 Apr 2012 19:13:37 -0700 (PDT) Received: from mail.catinthebox.net (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA4611E809A for ; Fri, 13 Apr 2012 19:13:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1976; t=1334369606; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=DP9nC8/PDFr0zMjONxREXcmtjiw=; b=GJh7Y3C66gXwbJYJXKU6 8tvks5yHg508U1Fn1ryDKjrV86sSX1PCs0I25zVRDGVJ/neDeA532QoVCnN+bmQ+ ZHXvTnofnSaltRVfPzaDNdWwi9hs67d1SBkwR/wlRDYyYVy3dt9eEtt3mbmxloUj abW4ihDxkIClQkLWvCIyK94= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 22:13:26 -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 v6.4.454.1) with ESMTP id 3276433389.25587.3188; Fri, 13 Apr 2012 22:13:25 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1976; t=1334369284; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0sJk13T tvZtprWnIFeRVWmfSYPPIpcSg2eZh193OLsk=; b=iB0w5hOI2ZexITTXMMjldNX y+3/tjFzvRc8AT043QVZ6zqp13sx53SA0m3unYNQR8d2WSBhDyl4OXxGn/+RSo1F sJB31P7lzyEHwLwuyqovg/cQKXNrvVoP5SGnISfeqNwn31oTzG6qcJyfy+MyPe2V ikXBzsIsndxicrGEop9o= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 22:08:04 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3875339877.1323.5480; Fri, 13 Apr 2012 22:08:03 -0400 Message-ID: <4F88DD22.2020303@isdg.net> Date: Fri, 13 Apr 2012 22:12:50 -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: <20120324090349.15462.qmail@joyce.lan> <2230111.fUdp390bGt@scott-latitude-e6320> <4F8884A7.6080404@isdg.net> <10035218.VxSKd6zvrx@scott-latitude-e6320> In-Reply-To: <10035218.VxSKd6zvrx@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 02:13:38 -0000 Scott Kitterman wrote: > There is no such thing as the SPF/SIDF protocol. They are separate things. Scott, to the integrator it was a clear TOTAL SOLUTION SPF framework. The 2006 IETF experiment of the integrated coexistence of these multiple protocols was the principle reason for its exploration. While I am clearly sympathetic to the SPF1.0 only crowd and its cited conflicts with SPF2.0, the reality was such is that a proposed PAYLOAD based 3rd identity domain called the PRA was considered to be part of the use cases and one the SMTP only SPF1.0 protocol did not cover. All together, I hate to repeat it: - 5321.EHLO/HELO - 5321.MAILFROM - 5322.PRA I think we forget why SPF had a allure to it as a ACCEPT/BOUNCE mitigating solution. The 5322.PRA defeated that purpose and during this time frame, lets note large scale systems were not global BCP position to apply it at the DATA level. The mail had to be accepted. Again, that payload acceptance concern led to the RFC4405 SMTP level exposure of the PRA keeping it all at 5321: - 5321.EHLO/HELO - 5321.MAILFROM - 5321.SUBMITTER > The only technical relationship they have is the unfortunate design decision > by Microsoft to re-purpose SPF records for SIDF. While I never did quite get the "AH HA" behind the PRA value, I recognized it was an option that needed to be supported in the integrated protocol. But overall, I had always failed to see your and similar cited concerns because to the Integrator the two TXT records were clearly separated. I never disputed there was a concern. I just didn't quite see it, and I would think the effort to look at the experiment results could FOCUS on the value of the PRA and/or resolving the so called SPF1.0/2.0 policy conflicts that is stated to exist. What exactly is the conflict? Can it be resolved? Or is still a dead horse? -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From spf2@kitterman.com Fri Apr 13 19:31: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 1F33521F86A4 for ; Fri, 13 Apr 2012 19:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYGdCNybVabk for ; Fri, 13 Apr 2012 19:31:48 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7340521F86A3 for ; Fri, 13 Apr 2012 19:31:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A782820E40A3; Fri, 13 Apr 2012 22:31:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334370707; bh=h3HuGO7d1kMYU7R0FmoKsoq5fxbxVSqqbUdyfme7p8s=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=naQfC3nwXuvnbRaXYcpbTaEYzjTxVG67OZbWZWXKYvHfZex1DDqgKV5oTXTThqXYl AFmNx6Wh2OGBlP0npwHbQhatmqX7aHaT6joOyX1flIktjGL/YhL/DhaoOnVWKWe5xD tc4Akjw+EYez/JYt1sOJs9M9BIjMnjqNlzlPDkOo= Received: from scott-latitude-e6320.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 ESMTPSA id 89DC720E4083; Fri, 13 Apr 2012 22:31:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Apr 2012 22:31:43 -0400 Message-ID: <3049024.WW88nJb152@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F88DD22.2020303@isdg.net> References: <20120324090349.15462.qmail@joyce.lan> <10035218.VxSKd6zvrx@scott-latitude-e6320> <4F88DD22.2020303@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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 02:31:51 -0000 On Friday, April 13, 2012 10:12:50 PM Hector Santos wrote: > Scott Kitterman wrote: > > There is no such thing as the SPF/SIDF protocol. They are separate > > things. > > Scott, to the integrator it was a clear TOTAL SOLUTION SPF framework. > > The 2006 IETF experiment of the integrated coexistence of these > multiple protocols was the principle reason for its exploration. > While I am clearly sympathetic to the SPF1.0 only crowd and its cited > conflicts with SPF2.0, the reality was such is that a proposed PAYLOAD > based 3rd identity domain called the PRA was considered to be part of > the use cases and one the SMTP only SPF1.0 protocol did not cover. > All together, I hate to repeat it: > > - 5321.EHLO/HELO > - 5321.MAILFROM > - 5322.PRA > > I think we forget why SPF had a allure to it as a ACCEPT/BOUNCE > mitigating solution. The 5322.PRA defeated that purpose and during > this time frame, lets note large scale systems were not global BCP > position to apply it at the DATA level. The mail had to be accepted. > Again, that payload acceptance concern led to the RFC4405 SMTP level > exposure of the PRA keeping it all at 5321: > > - 5321.EHLO/HELO > - 5321.MAILFROM > - 5321.SUBMITTER Such a total protocol solution doesn't exist. It was the goal of MARID to produce such a protocol, but it was concluded for non-technical reasons and revisiting all this history is specifically off topic for the working group. Personally, I don't see any value in 5321.SUBMITTER. Unless the bad guys are being idiots, it won't save you from going to DATA anyway. > > The only technical relationship they have is the unfortunate design > > decision by Microsoft to re-purpose SPF records for SIDF. > > While I never did quite get the "AH HA" behind the PRA value, I > recognized it was an option that needed to be supported in the > integrated protocol. But overall, I had always failed to see your and > similar cited concerns because to the Integrator the two TXT records > were clearly separated. > > I never disputed there was a concern. I just didn't quite see it, and > I would think the effort to look at the experiment results could FOCUS > on the value of the PRA and/or resolving the so called SPF1.0/2.0 > policy conflicts that is stated to exist. > > What exactly is the conflict? Can it be resolved? Or is still a dead > horse? It's dead IMO. Even if it weren't dead, the non-technical barriers to completing MARID still exist so there's no point in spending a lot of time on figuring out the technical points. All off topic and we should probably stop. Scott K From hsantos@isdg.net Fri Apr 13 19:38: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 8B6C021F8610 for ; Fri, 13 Apr 2012 19:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pREiefvPG1BL for ; Fri, 13 Apr 2012 19:38:38 -0700 (PDT) Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 78E0A21F84E7 for ; Fri, 13 Apr 2012 19:38:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1314; t=1334371111; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=HzXqmzMU9MISJtNFxe75FpHwqZk=; b=BeNOGY5pvxaYKxZqsDHv 5X83rcilk1EAxOLEmvD3Ej1FmHER1QWd3Mh0UX6uNrA+j1cBUHaXpRFDjQG1GPov 5xGQY6X7+ep8Lez/FQsH5DrpMRpoRWdhmmqp5U51OuqOseyveWdG6e9YEzJ8f2dV Z1hCeudiHurVdTcURv0rIiI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 22:38: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3277938565.25587.5644; Fri, 13 Apr 2012 22:38:30 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1314; t=1334370788; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=k428wc4 H2+trOulXhw9vSBFkQdFrAwhaBfq36qUv30s=; b=VWj0bDmu0v1o4JMw02Vl0HI EiIjQWtqKYMVpPvQ6cM4KZ5quThPAxqQIaVzQS9Zw37SUVMRxwGjvDwB3a0cSaZV QfQRECe/51gEqAmFF6LRpcAyy+u/gNkOgT+6DzTXS9H019TAJyxMAV6PAzwJdN1A B8YhFfCC38olAjIzQ7jY= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 22:33:08 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3876844033.1331.4848; Fri, 13 Apr 2012 22:33:07 -0400 Message-ID: <4F88E302.2010203@isdg.net> Date: Fri, 13 Apr 2012 22:37:54 -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: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> In-Reply-To: <4F88BB70.3040307@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 02:38:39 -0000 Douglas Otis wrote: > Dear Hector, > > This concerns MSAs where your network, your rules apply. IMHO, the role > most have for SPF is for unauthenticated (port 25) traffic between > different ADMDs. Wasn't this already stated? > The RFC5321 is not bound to a specific > ADMD which is where SPF framework fails. SPF does not permit valid > operations of http://tools.ietf.org/html/rfc5321#section-6.1 and > http://tools.ietf.org/html/rfc1123#section-5.2.6 which is why many > ignore "-all" and this represents a serious conflict that must be resolved. Many? like who? anyone who is ignoring the -ALL policy is violating RFC4408 and worst, assuming product liability that was possibly repudiated by the domain policy. I would be one to advise the chief council of such operations where this intentional neglect to follow standard practice risk malpractice product liability claims. It would best to just not do any SPF, drop support, rather than pretend and make up your own rules that negates and conflicts with the standard explicit domain policies. If a domain says THIS IS BAD and you say I DON"T BELIEVE YOU, then you take on all product and consumer liability - automatically. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Fri Apr 13 20:01: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 53BCA21F8463 for ; Fri, 13 Apr 2012 20:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqQHNDnFf19J for ; Fri, 13 Apr 2012 20:01:26 -0700 (PDT) Received: from mail.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 34BBC21F844D for ; Fri, 13 Apr 2012 20:01:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1503; t=1334372471; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=slGBuBF8f3pI632Kw5/6FnqP/3I=; b=O/ZFN4IfoFa3RLqEnp13 5KXub3AdDIX00xQLSYcRWpJGmvU+cSo4TP3s0mf/WsVVTBugUsBRO9SmxjfcXh1o ViuRyCbn1t/Hp0+IuTt7pg4V71bYqexk1gr3Ik32AZYWkbpOdMGWqdLSnQCGqk8R w2SASmjuADKrtVOEZbIcFyw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 23:01: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3279298612.25587.4788; Fri, 13 Apr 2012 23:01:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1503; t=1334372147; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jrYJwu2 TKMjJOSc2UbE/liDH09cGSaFcoyfu7ATgY3Y=; b=EoQBgQYsrCLv+7DJzHbgzjz 0/R/8RsGyycosw8GiaevixtgIQzHquKVf4yvXDpzTpeuc0PKYv5Xx47SER4nbdVX gvVuSdgjEe7u20hNl4yBq7JB8BGiqhgnK5RJs7lR3A75e8jCg8aQ99JM4jCKYDJE nKQMCazfaa9EmST3RJ40= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Apr 2012 22:55:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3878203362.1333.1832; Fri, 13 Apr 2012 22:55:47 -0400 Message-ID: <4F88E852.6010607@isdg.net> Date: Fri, 13 Apr 2012 23:00:34 -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: <20120324090349.15462.qmail@joyce.lan> <10035218.VxSKd6zvrx@scott-latitude-e6320> <4F88DD22.2020303@isdg.net> <3049024.WW88nJb152@scott-latitude-e6320> In-Reply-To: <3049024.WW88nJb152@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 03:01:27 -0000 Scott Kitterman wrote: > Such a total protocol solution doesn't exist. How can state this when any SMTP-SPF server that supports SUBMITTER and all the clients that also leverage it clearly exist? Just because you never support it, doesn't mean the integrated 2006 IETF consideration was a fallacy. > It was the goal of MARID to produce such a protocol, but it was concluded > for non-technical reasons and revisiting all this history is specifically > off topic for the working group. Huh? You admit that it was a goal but blab without any evidence that it was concluded to be unintentional and to try to kill it as off topic? > Personally, I don't see any value in 5321.SUBMITTER. Ok, tell us why? > Unless the bad guys are being idiots, it won't save you from going > to DATA anyway. Thats like saying the BAD GUY can also be SPF 1.0 compliant too! I think since you never implemented 4405, you lack insight into it possible value or usage. In essence what you were suggesting there was no valid PRA use case. Thats not a technical opinion, but a policy mandate. Should I believe you or claims by others that the PRA works great with RESENT-FROM headers? > It's dead IMO. Even if it weren't dead, the non-technical barriers to > completing MARID still exist so there's no point in spending a lot of time on > figuring out the technical points. Moving hand over head. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Fri Apr 13 23:55: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 8627F21F86DF for ; Fri, 13 Apr 2012 23:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWp7-uzEimvm for ; Fri, 13 Apr 2012 23:55:51 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id DE21121F85A2 for ; Fri, 13 Apr 2012 23:55:50 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id xivk1i0010ZaKgw01ivkqN; Fri, 13 Apr 2012 23:55:44 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=NYRkJh/4 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=3Oi21VZ3JeAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=cVQ2Lxvel49cwuGPElYA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 23:55:28 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 Thread-Index: AQHNGcCai4FkTeymQEGmbWrF0MI1vJaZ4nQw Date: Sat, 14 Apr 2012 06:55:28 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F17E8@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280EFF59@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334386544; bh=xZG77X8Z90VzWphLDMmfAvZLhWcuf7roz+C3S5EUcgk=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ew6ekYTmnOTO6Zgv51P8i06CVVijPigwCAjWmaTbXPZ1aEUVbDBqUyTAdwgwCaPGT kBEeHwqV0HvpjgXGCgihMQIIrZW8ZbLqPQ7AypLc4HZGBewsqYDlthGlscOJ7WQpGb K7yIdxwxJa+ntSHlDJ0qlTDfnhDPfdJrhn1a6rag= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 06:55:51 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John R Levine > Sent: Friday, April 13, 2012 2:58 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 >=20 > A few minor points: > [...] Thanks, all incorporated for the next version. -MSK From vesely@tana.it Sat Apr 14 07:40: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 EB03121F8618 for ; Sat, 14 Apr 2012 07:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld3kCTAgM0CF for ; Sat, 14 Apr 2012 07:40:57 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F150821F8606 for ; Sat, 14 Apr 2012 07:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334414455; bh=0Vhr9rjJE5Js4VAqZvHKlPuHPA4riCmFLi2BMmhqask=; l=1630; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gn+jNFT0Us4FCNZ8XwX38ryMMbfn6Mgg01Y/G+34D6ePV/4Z1bfEWRRaGSnyImGs5 bcb/tzgxSJEjoG2E/F0m7L8eHncFh8HV4gB22YQ1oHMTYaKPdUQUtT4wbXN3D9vzZs 5X5Srw30za73jLCa3lwAK+xiGWkHqE4oa59/1fzU= 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, 14 Apr 2012 16:40:55 +0200 id 00000000005DC039.000000004F898C77.00004CFB Message-ID: <4F898C76.1090508@tana.it> Date: Sat, 14 Apr 2012 16:40:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <2230111.fUdp390bGt@scott-latitude-e6320> <4F88638D.9000401@tana.it> <1592914.fLmzuDM8PQ@scott-latitude-e6320> In-Reply-To: <1592914.fLmzuDM8PQ@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:40:59 -0000 On Sat 14/Apr/2012 15:21:33 +0200 Scott Kitterman wrote: > On Friday, April 13, 2012 07:34:05 PM Alessandro Vesely wrote: >> On Fri 13/Apr/2012 19:18:23 +0200 Scott Kitterman wrote: >> >>> RFC 4405 is just PRA selection. >> >> I meant the SMTP extension. > > It does say it's not relevant to submission. It says it is "appropriate", see point (6) of http://tools.ietf.org/html/rfc4405#section-2 Irrespectively of the possible merits of RFC 4405, that point might generate confusion, since the protocols are somewhat similar. That's why I proposed to state the opposite. > I don't agree it's necessary to say that for SPF. No, it's not necessary. However, if we add a paragraph about submission and the verification quoted below, then it would take just one extra sentence. >>> The one submission related practice that I have seen is a >>> prospective check to determine if the message were to be sent >>> from the submission server would it pass SPF. I think that can >>> be useful, but I don't think it needs to be standardized. >> >> Just to make that clear, you mean a submission server could apply >> SPF checks against its mailout's IP address in order to verify >> the Return-Path that the user configured? Such kind of action >> is described in http://tools.ietf.org/html/rfc6409#section-6.1 >> but without explicitly mentioning SPF as a tool. > > Yes. that's what I mean. I'd say 6409 6.1 is describing what > should be done. What I mention is one method for how to go about > it. It has no interoperability or protocol implications, so I > don't think it needs standardization. From vesely@tana.it Sat Apr 14 07: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 609A021F8606 for ; Sat, 14 Apr 2012 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kLzx2qW6eBw for ; Sat, 14 Apr 2012 07:45:25 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A677021F85F7 for ; Sat, 14 Apr 2012 07:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334414724; bh=bKe+dKhNoR/kEv/3qlGr9u30RHG8ik/GK9irYjpCmw0=; l=1174; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QuMQaRRir0oV6zg5djFdKUEU72qolF0ol80K4QCm6x6NVH0OWL5m08GW4Gd/8AiTK 65m2LSgGavWSJUFslouyP13Z1CaFPva4Ny9W1JG3s2H1wR1CrHSZvh1K27z/CshzDy GYUmNRgqESa57K3+E7v7EdbgLd+wm0NvbVd1jn0Q= 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, 14 Apr 2012 16:45:24 +0200 id 00000000005DC039.000000004F898D84.00004DFC Message-ID: <4F898D84.3050300@tana.it> Date: Sat, 14 Apr 2012 16:45:24 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> In-Reply-To: <4F88E302.2010203@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:45:26 -0000 On Sat 14/Apr/2012 16:12:56 +0200 Hector Santos wrote: > Douglas Otis wrote: > >> The RFC5321 is not bound to a specific ADMD which is >> where SPF framework fails. SPF does not permit valid operations of >> http://tools.ietf.org/html/rfc5321#section-6.1 and >> http://tools.ietf.org/html/rfc1123#section-5.2.6 which is why many >> ignore "-all" and this represents a serious conflict that must be >> resolved. > > Many? like who? Gmail, for one. They register the failure, don't check the helo identity, and deliver the message regularly. That's fine, IMHO. > anyone who is ignoring the -ALL policy is violating RFC4408 and > worst, assuming product liability that was possibly repudiated by > the domain policy. SPF cannot guarantee that publishing -ALL ensures rejection. There will always be SPF-ignorant servers, and servers like gmail that check but don't reject. Actually, it seems to me that those who reject can be accused of breaking those SMTP features. To resolve the conflict we must devise a safe way of rejecting, such that servers can adhere to it with no risks. Our task is not to mandate it, but to enable it. From spf2@kitterman.com Sat Apr 14 07:51: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 90F5E21F8629 for ; Sat, 14 Apr 2012 07:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWkyQoBlfb4f for ; Sat, 14 Apr 2012 07:51:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F93D21F8609 for ; Sat, 14 Apr 2012 07:51:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7F6C620E40A6; Sat, 14 Apr 2012 10:51:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334415099; bh=Xm87YmcHYBZZbS9MMEiPvU5F1hHrqgrsEFeqRUZOWew=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=IjRyfdfA6lLW2nYy43Be663GQZ9igOT589Soq2wnmcsuGPFySlJV/RHCvbfRY33O1 RmGiAkfUKiheSmsZE1K/h04uq1puqlFgt2jVsAOpmbfZunVPpyuaOIWOqWEYnzxqtc s2PtQXC2a713jHmV23hnI8X2wQmqNTln2ztXNoaU= Received: from scott-latitude-e6320.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 ESMTPSA id 6625C20E40A3; Sat, 14 Apr 2012 10:51:39 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 14 Apr 2012 10:51:38 -0400 Message-ID: <3210244.RmhkGdxx1C@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F898C76.1090508@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <1592914.fLmzuDM8PQ@scott-latitude-e6320> <4F898C76.1090508@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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:51:41 -0000 On Saturday, April 14, 2012 04:40:54 PM Alessandro Vesely wrote: > >>> RFC 4405 is just PRA selection. > >> > >> > >> > >> I meant the SMTP extension. > > > > > > > > It does say it's not relevant to submission. > > It says it is "appropriate", see point (6) of > http://tools.ietf.org/html/rfc4405#section-2 > > Irrespectively of the possible merits of RFC 4405, that point might > generate confusion, since the protocols are somewhat similar. That's > why I proposed to state the opposite. Never mind that. I had 4405 and 4407 switched when I wrote that. Scott K From spf2@kitterman.com Sat Apr 14 07:59: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 BB5F821F863F for ; Sat, 14 Apr 2012 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrDCn1G4Yqo1 for ; Sat, 14 Apr 2012 07:59:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC921F8629 for ; Sat, 14 Apr 2012 07:59:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 98DDB20E40A6; Sat, 14 Apr 2012 10:59:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334415553; bh=pJU4SWQ2QTMSu88RFq6v4O4BKF+ZC1QTrtuqdAHkQGs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=YeLaHsgOzd4xMBKr8ysDpCPuSdvPDswRv+E+hK0fFZOcsQlcsw9SP1jnduQrZ8SZz 24YYoaQmpEIQet2KIqrVoSOKDC28Lxk/2hMS/yNmd0cIS78beKgSBIGLGCf5sVFoOT nn53WtfWp379QoOtOTB8Ynl94L0W6LQVopoXqIu8= Received: from scott-latitude-e6320.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 ESMTPSA id 7A81720E40A3; Sat, 14 Apr 2012 10:59:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 14 Apr 2012 10:59:13 -0400 Message-ID: <2544259.KoaNgMjTDF@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F88E852.6010607@isdg.net> References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:59:14 -0000 On Friday, April 13, 2012 11:00:34 PM Hector Santos wrote: > Scott Kitterman wrote: > > Such a total protocol solution doesn't exist. > > How can state this when any SMTP-SPF server that supports SUBMITTER > and all the clients that also leverage it clearly exist? > > Just because you never support it, doesn't mean the integrated 2006 > IETF consideration was a fallacy. What was considered in 2006 was not an integrated protocol. It was two independent submissions, one of which used aspects of the other. > > It was the goal of MARID to produce such a protocol, but it was concluded > > for non-technical reasons and revisiting all this history is specifically > > off topic for the working group. > > Huh? You admit that it was a goal but blab without any evidence that > it was concluded to be unintentional and to try to kill it as off topic? It was a goal, but it failed. Specifics of why are specifically off topic, but it is indisputable that no RFCs came out of the MARID working group. > > Personally, I don't see any value in 5321.SUBMITTER. > > Ok, tell us why? At the envelop layer SUBMITTER is a made up ID that carries a promise that later, if you go to DATA, you'll discover has some relevance to a header in the body. It could be anything. I don't see any value in knowing before DATA that resent-sender is some particular domain. > > Unless the bad guys are being idiots, it won't save you from going > > to DATA anyway. > > Thats like saying the BAD GUY can also be SPF 1.0 compliant too! I > think since you never implemented 4405, you lack insight into it > possible value or usage. > > In essence what you were suggesting there was no valid PRA use case. > Thats not a technical opinion, but a policy mandate. Should I > believe you or claims by others that the PRA works great with > RESENT-FROM headers? It depends on what you mean by great. PRA is useful if you are worried about resent-sender forgery. I am not. Other than that, it just gives you a domain to use as an input to a reputation system and as such is a "batteries needed" protocol and not particularly useful in itself. > > It's dead IMO. Even if it weren't dead, the non-technical barriers to > > completing MARID still exist so there's no point in spending a lot of time > > on figuring out the technical points. > > Moving hand over head. I have no idea what that means, but that's probably OK. Scott K From dotzero@gmail.com Sat Apr 14 17:07: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 A06BC21F853E for ; Sat, 14 Apr 2012 17:07: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvttGh-KdigC for ; Sat, 14 Apr 2012 17:07:50 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9A97421F8534 for ; Sat, 14 Apr 2012 17:07:50 -0700 (PDT) Received: by dady13 with SMTP id y13so7397974dad.27 for ; Sat, 14 Apr 2012 17:07: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:content-transfer-encoding; bh=87HptZa0+Wnt7/VJqd+pU2BuF1MmJ0Abki7vuyG7+eE=; b=t1U2+o02lNucLrdelGvGxVaeThqOpfPyKVHtaq63hMMWRv6BF86H4yozkyCBKpWjwn ecIWFbLeyLLssHxaEnVJCFzFMv3VAmtfDJV2+0L4TfO2rJZ+DotwELbeRGxZrFkpQVbJ kbtNsg1kGeICZtdVgenPfk2rUMc0SktztQkdMQPadywYoMrOsfUAt/vAsej5F4s0wd8/ 3KuyOwqLZdpjRJleMenMNyWHMqyaVgIJDQRE8p2ZVvzi6RSF5NsKija08lujDM+OngV6 bW2ypYN+wpzRb2s7gRlpqxf7EG/qq1aHY2GZh82VKlgkE/z2JpgM/p5B9Zplm6mKan2+ nj3Q== MIME-Version: 1.0 Received: by 10.68.217.199 with SMTP id pa7mr2568146pbc.18.1334448470287; Sat, 14 Apr 2012 17:07:50 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Sat, 14 Apr 2012 17:07:50 -0700 (PDT) In-Reply-To: <2544259.KoaNgMjTDF@scott-latitude-e6320> References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> Date: Sat, 14 Apr 2012 20:07:50 -0400 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 00:07:51 -0000 On Sat, Apr 14, 2012 at 10:59 AM, Scott Kitterman wrot= e: > On Friday, April 13, 2012 11:00:34 PM Hector Santos wrote: >> Scott Kitterman wrote: >> > Such a total protocol solution doesn't exist. >> >> How can state this when any SMTP-SPF server that supports SUBMITTER >> and all the clients that also leverage it clearly exist? >> >> Just because you never support it, doesn't mean the integrated 2006 >> IETF consideration was a fallacy. > > What was considered in 2006 was not an integrated protocol. =A0It was two > independent submissions, one of which used aspects of the other. > >> > It was the goal of MARID to produce such a protocol, but it was conclu= ded >> > for non-technical reasons and revisiting all this history is specifica= lly >> > off topic for the working group. >> >> Huh? =A0You admit that it was a goal but blab without any evidence that >> it was concluded to be unintentional and to try to kill it as off topic? > > It was a goal, but it failed. =A0Specifics of why are specifically off to= pic, but > it is indisputable that no RFCs came out of the MARID working group. > >> > Personally, I don't see any value in 5321.SUBMITTER. >> >> Ok, tell us why? > > At the envelop layer SUBMITTER is a made up ID that carries a promise tha= t > later, if you go to DATA, you'll discover has some relevance to a header = in > the body. =A0It could be anything. =A0I don't see any value in knowing be= fore DATA > that resent-sender is some particular domain. > >> > Unless the bad guys are being idiots, it won't save you from going >> > to DATA anyway. >> >> Thats like saying the BAD GUY can also be SPF 1.0 compliant too! I >> think since you never implemented 4405, you lack insight into it >> possible value or usage. >> >> In essence what you were suggesting there was no valid PRA use case. >> Thats not a technical =A0opinion, but a policy mandate. =A0Should I >> believe you or claims by others that the PRA works great with >> RESENT-FROM headers? > > It depends on what you mean by great. =A0PRA is useful if you are worried= about > resent-sender forgery. =A0I am not. =A0Other than that, it just gives you= a domain > to use as an input to a reputation system and as such is a "batteries nee= ded" > protocol and not particularly useful in itself. > I'm getting tired of repeating this, but PRA is BROKEN. Pick a domain that has a naked "-all" - ibm.com for example. Create a message with a Mail From and From purporting to be from ibm.com. Now add a Sender field from a random domain that does not publish an SPF record (of any sort). The PRA will be the random domain. What this means is that a bad guy can consistently game PRA to get a neutral result by using random non publishing domains. BROKEN! >> > It's dead IMO. =A0Even if it weren't dead, the non-technical barriers = to >> > completing MARID still exist so there's no point in spending a lot of = time >> > on figuring out the technical points. >> >> Moving hand over head. > > I have no idea what that means, but that's probably OK. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Sat Apr 14 21:29: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 C6DC521F86AD for ; Sat, 14 Apr 2012 21:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBFKyd9xKCaX for ; Sat, 14 Apr 2012 21:29:52 -0700 (PDT) Received: from secure.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC4B21F8665 for ; Sat, 14 Apr 2012 21:29:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2607; t=1334464188; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=tVyrNXzy//gsYHBUdc3/KUZhfWk=; b=woZVW+TCXsIvjXq55Dn/ +VNIM/bAuBHXq1we+/Fx5L/8Td91v47NAUBGLfsK3gL/RYbQM4hhoJY+n+b5yHWw DUBLsCrmtErtW+jtLgOekNwANBX4/dESRJbtsLVmw0L8Y+jFLrhSA2MrnPUcvlvH d162E+ZuPpin9yVZuCOQrhM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 15 Apr 2012 00:29: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 v6.4.454.1) with ESMTP id 3371014549.27366.4252; Sun, 15 Apr 2012 00:29:48 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2607; t=1334463865; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=EIqlowU r64kO4TeYlDesObhqqmE9evrfypMi/exvVW0=; b=ErnoxB2WwItewmiWocv1bfC 9SmW/iPJilXos+YMlNobZLYdTVIZhTAp8z0264h5cf6ZAGZha+YRQcP4XIoSiNCT tz0qnKdhAE0RkgH22+IUnSHCUdlTJOof6hhw3GbxS/AOzh+Cp8COVgxgsXeLZnM4 RpxhwUJOEOrHhMm4hN74= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 15 Apr 2012 00:24:25 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3969920315.1518.352; Sun, 15 Apr 2012 00:24:24 -0400 Message-ID: <4F8A4EAC.6020402@isdg.net> Date: Sun, 15 Apr 2012 00:29:32 -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: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 04:29:53 -0000 Dotzero wrote: >>> Hector: >>> In essence what you were suggesting there was no valid PRA use case. >>> Thats not a technical �opinion, but a policy mandate. �Should I >>> believe you or claims by others that the PRA works great with >>> RESENT-FROM headers? >> Scott: >> It depends on what you mean by great. �PRA is useful if you are worried about >> resent-sender forgery. �I am not. �Other than that, it just gives you a domain >> to use as an input to a reputation system and as such is a "batteries needed" >> protocol and not particularly useful in itself. > I'm getting tired of repeating this, but PRA is BROKEN. Pick a domain > that has a naked "-all" - ibm.com for example. Create a message with a > Mail From and From purporting to be from ibm.com. Now add a Sender > field from a random domain that does not publish an SPF record (of any > sort). The PRA will be the random domain. What this means is that a > bad guy can consistently game PRA to get a neutral result by using > random non publishing domains. BROKEN! You should be tired because this is not the premise for getting rid of it. However, it should be because that was the original 2006 issue with the integration of SPF with the PRA concept introduced by Microsoft. No one has every stated, now these protocol say it is perfect or that it covers all cases. Yet, there are those who stated with technical experience, there are PRA use cases where it works great. I believe it is when Resent-Sender is involved, and now that we have 6+ years of field testing, we should see what the actual payoff is or not and review the conflicts in detail, if any. BTW, it should be noted the example with IBM.COM is probably not good because it has a SPF v1.0 policy statement and the PRA does not apply. "v=spf1 -all" This basically states a corporate policy: NO EMAIL EXPECTED USING THE IBM.COM DOMAIN. It is a clear legal corporate mandate statement that no one nor anything is expected use the IBM.COM domain for sending email, from anywhere and from anyone - No Exceptions. Overall, the PRA does not apply here because any original submission SHOULD NOT ever exist with a IBM.COM in 5321.EHLO or 5321.MAILFROM or 5322.FROM. The 5322.Sender would not exist until a submission takes place and that submission should never happen. A legacy spoofer (unintentional/random usage of IBM) and SPF faker (intentional facsimile to spoof) would never get entry when RFC4408 is 100% followed. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Sat Apr 14 21:47: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 7483521F8720 for ; Sat, 14 Apr 2012 21:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agYK-aGNYsJY for ; Sat, 14 Apr 2012 21:47:44 -0700 (PDT) Received: from secure.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 182B221F86EB for ; Sat, 14 Apr 2012 21:47:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2488; t=1334465258; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=ovKx6KtrAkKzBx9kNhUXckOXAuI=; b=uJfUY/EpTD9LGXvnnC8H 8OKeeBU/PqP2tSt1lsXTOC21KCXPk/r3yIkmO1MOBfyqLzIZ6bRYhGJTknsIc5gb E1bo4zhmom6U/iKTKFPzwIRqDJ8pTDp0ZrnHtcfyRZ0kYMSv1By9XlhAHlgfiZYb 3SiVL6SoMnV/DO7vWnSfxhc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 15 Apr 2012 00:47: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3372084700.27366.4624; Sun, 15 Apr 2012 00:47:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2488; t=1334464934; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=icTc17p 7oKS0vzW+vdmBjBx+K6ne4j0i/v/Hv0XnswE=; b=VpipBfIEo4QZF4IwPK4uW2G 1CBnUgLHtkKc1UV3OB9kfjkPBGHwaGbKpCiavwdQhXn5DRGd3IaTSsUnsqQLqShG psrHR+bfbjoXT3A006K9Vfpdhyk7UtScbAODczPFpIEsJm+9bKgO0vFdgQ3+LnDC bsyXdZZOSooJTK283OkM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 15 Apr 2012 00:42:14 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3970989393.1521.3736; Sun, 15 Apr 2012 00:42:13 -0400 Message-ID: <4F8A52D9.10304@isdg.net> Date: Sun, 15 Apr 2012 00:47:21 -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: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> In-Reply-To: <4F898D84.3050300@tana.it> 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] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 04:47:45 -0000 Alessandro Vesely wrote: > On Sat 14/Apr/2012 16:12:56 +0200 Hector Santos wrote: >> Douglas Otis wrote: >> >>> The RFC5321 is not bound to a specific ADMD which is >>> where SPF framework fails. SPF does not permit valid operations of >>> http://tools.ietf.org/html/rfc5321#section-6.1 and >>> http://tools.ietf.org/html/rfc1123#section-5.2.6 which is why many >>> ignore "-all" and this represents a serious conflict that must be >>> resolved. >> Many? like who? > > Gmail, for one. They register the failure, don't check the helo > identity, and deliver the message regularly. That's fine, IMHO. > >> anyone who is ignoring the -ALL policy is violating RFC4408 and >> worst, assuming product liability that was possibly repudiated by >> the domain policy. > > SPF cannot guarantee that publishing -ALL ensures rejection. There > will always be SPF-ignorant servers, and servers like gmail that check > but don't reject. > > Actually, it seems to me that those who reject can be accused of > breaking those SMTP features. To resolve the conflict we must devise > a safe way of rejecting, such that servers can adhere to it with no > risks. Our task is not to mandate it, but to enable it. I think what is not understood is that companies that use a strong -ALL are also making legal disclaimers for tort claims. Good examples are IBM.COM and ALTAVISTA.COM IBM.COM has Non-authoritative answer: ibm.com text = "v=spf1 -all" and ALTAVISTA.COM has even more explicit policy disclaimer and couldn't be even more clear what its corporate intent is with this domain: Non-authoritative answer: altavista.com text = "All mail claiming to be from altavista.com is forged" altavista.com text = "v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all" altavista.com text = "This domain sends no email" altavista.com text = "Null SPF is for tracking purposes only" If a system claims SPF compliance and its IGNORES the strong exclusive hard fail policies, and especially those that state a NO MAIL policy, is 10000% putting the system at legal risk. Both IBM.COM and ALTAVISTA.COM would be exempt and indemnified from any tort or user harm claims stemming from an irresponsible SPF receiver continuing to pass on the user what is 100% known to a violation of the domain policy and potentially harmful mail. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Sun Apr 15 01:05: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 8D2F721F875A for ; Sun, 15 Apr 2012 01:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFePR-khsZ-C for ; Sun, 15 Apr 2012 01:05:23 -0700 (PDT) Received: from mail.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 59D7C21F8754 for ; Sun, 15 Apr 2012 01:05:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3079; t=1334477114; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=B4PDffssl54IOnKt8umyZ7YTD18=; b=r/c1yyPcEPly4FJ0OAMX dqfkyTboXop0fQSsCQ2Ln4xnQociOpK7mOcCRoWJ8qOMM+CHk3HS+I3qOd/stgJX CmjA0p2GR9i7Z5vXOxxjz0GlhTimQraIRTSdvm/8oweInsFl0I6tPAcfuT1Hha2B MaYUJmhofweX02nCqeoj6ic= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 15 Apr 2012 04:05:14 -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 v6.4.454.1) with ESMTP id 3383939871.27366.1836; Sun, 15 Apr 2012 04:05:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3079; t=1334476791; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RVZGkio VABDWul1rTJBkNu/JRyaCRVG76sgQOrTEnxQ=; b=LPfnJXojRWyfKR3utfdMKN4 Nwz+E1bNOyt31YHaULYHHsf4APl58rD3FswXNy74Iie3EYSznUWAgPByZUffmI9d yrTIuFmjIegU5aClt3O8aWHPT3tO5q7bILqOcHNj8vzTTNrgQDR/vOue3RSFwvs9 quyEv24XXZNIQZ3ufLIU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 15 Apr 2012 03:59:51 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3982846846.1539.5612; Sun, 15 Apr 2012 03:59:50 -0400 Message-ID: <4F8A812B.1030505@isdg.net> Date: Sun, 15 Apr 2012 04:04:59 -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: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> In-Reply-To: <2544259.KoaNgMjTDF@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 08:05:24 -0000 Scott Kitterman wrote: >>> Personally, I don't see any value in 5321.SUBMITTER. >> Ok, tell us why? > > At the envelop layer SUBMITTER is a made up ID that carries a promise that > later, if you go to DATA, you'll discover has some relevance to a header in > the body. It could be anything. I don't see any value in knowing before DATA > that resent-sender is some particular domain. Scott, by design, it is basically a sanity or double check when there is a pass because if the SUBMITTER SPF policy was violated at 5321, per spec, the receiver SHOULD reject the transaction and there would be no reaching of the DATA state in order to get the payload. Its a two step checking concept: http://tools.ietf.org/html/rfc4405#section-4.2 Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD select the domain part of the SUBMITTER address value as the purported responsible domain of the message, and SHOULD perform such tests, including those defined in [SENDER-ID], as are deemed necessary to determine whether the connecting SMTP client is authorized to transmit e-mail messages on behalf of that domain. [STEP 1 - ENVELOPE TEST, NO PAYLOAD] If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed." [STEP 2 - PAYLOAD "DOUBLE CHECK" TEST] If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [PRA]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server MUST reject the message and when rejecting MUST use "550 5.7.1 Submitter does not match header." The 2nd "double checking" step per se, is specifically encourage in this section and in the security section. But if the failure does occur at step 1, then there is no payload checking need. In addition, it should be noted that the the above 2nd check and action, presumes an advanced receiver with payload filtering hooks, shims and/or callouts before the DATA "End of Data" server response is issued. Just a reminder that acceptance is not desirable if there going to be a failure point. The only solution to that is a DISCARD concept when is hinted/described in SenderID (4406) intro: This document describes a mechanism such that receiving Mail Transfer Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents (MUAs) can recognize mail in the above category and take appropriate action. For example, an MTA might refuse to accept a message, an MDA might discard a message rather than placing it into a mailbox, and an MUA might render that message in some distinctive fashion. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From dotzero@gmail.com Sun Apr 15 08:49: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 70EA021F87DE for ; Sun, 15 Apr 2012 08:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbTx-tSN0mOK for ; Sun, 15 Apr 2012 08:49:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB4D621F8794 for ; Sun, 15 Apr 2012 08:49:04 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so3392341pbb.31 for ; Sun, 15 Apr 2012 08:49:04 -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=czgiJ5zNoHi6mmbpYGmOYprGOANsYm+LYfkeRSw6B9g=; b=wPeQuwusG5njBrrqLR/0G8NE+e1oiG9wZ3hlUXFTcfmhPtAFJkw6Q7c7XB1jSKHP/u smHvzes+LYsr0aUqmrTX8GWu52S1MjMumGW5GKjBnnc+sduRpO5+n0yfykznIN7PhrAF VKiyrUNVYd2dDP0+CHeYZgAwHQVjNvKfIYIQHYwq+my52X8myDaac0VZ+TctltPkCE49 Ck80AyblTm2iAcIJ7KV/kINf5KZrK7cbcr7dd7F+nJT+hpc83mbwjEe4ozHGPRARZDe6 rHmQOTzM1poYKr6B2PchUXTkQtC4Ko/+YlGPhXmVZaHCkZGCRcYKqkDaF/pV/bCvCRKw gl0Q== MIME-Version: 1.0 Received: by 10.68.217.199 with SMTP id pa7mr7342602pbc.18.1334504944683; Sun, 15 Apr 2012 08:49:04 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Sun, 15 Apr 2012 08:49:04 -0700 (PDT) In-Reply-To: <4F8A4EAC.6020402@isdg.net> References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> <4F8A4EAC.6020402@isdg.net> Date: Sun, 15 Apr 2012 11:49:04 -0400 Message-ID: From: Dotzero To: Hector Santos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 15:49:05 -0000 On Sun, Apr 15, 2012 at 12:29 AM, Hector Santos wrote: > Dotzero wrote: > >>>> Hector: >>>> >>>> In essence what you were suggesting there was no valid PRA use case. >>>> Thats not a technical =EF=BF=BDopinion, but a policy mandate. =EF=BF= =BDShould I >>>> believe you or claims by others that the PRA works great with >>>> RESENT-FROM headers? > > >>> Scott: >>> >>> It depends on what you mean by great. =EF=BF=BDPRA is useful if you are= worried >>> about >>> resent-sender forgery. =EF=BF=BDI am not. =EF=BF=BDOther than that, it = just gives you a >>> domain >>> to use as an input to a reputation system and as such is a "batteries >>> needed" >>> protocol and not particularly useful in itself. > > >> I'm getting tired of repeating this, but PRA is BROKEN. Pick a domain >> that has a naked "-all" - ibm.com for example. Create a message with a >> Mail From and From purporting to be from ibm.com. Now add a Sender >> field from a random domain that does not publish an SPF record (of any >> sort). The PRA will be the random domain. What this means is that a >> bad guy can consistently game PRA to get a neutral result by using >> random non publishing domains. BROKEN! > > > You should be tired because this is not the premise for getting rid of it= . > However, it should be because that was the original 2006 issue with the > integration of SPF with the PRA concept introduced by Microsoft. > > No one has every stated, now these protocol say it is perfect or that it > covers all cases. =C2=A0Yet, there are those who stated with technical > experience, there are PRA use cases where it works great. I believe it is > when Resent-Sender is involved, and now that we have 6+ years of field > testing, we should see what the actual payoff is or not and review the > conflicts in detail, if any. > > BTW, it should be noted the example with IBM.COM is probably not good > because it has a SPF v1.0 policy statement and the PRA does not apply. > You seem to forget the appropriation of spf1 records for the use of senderi= d. > =C2=A0 =C2=A0 =C2=A0 "v=3Dspf1 -all" > > This basically states a corporate policy: > > =C2=A0 =C2=A0 =C2=A0NO EMAIL EXPECTED USING THE IBM.COM DOMAIN. > > It is a clear legal corporate mandate statement that no one nor anything = is > expected use the IBM.COM domain for sending email, from anywhere and from > anyone - No Exceptions. > > Overall, the PRA does not apply here because any original submission SHOU= LD > NOT ever exist with IBM.COM in 5321.EHLO or 5321.MAILFROM or 5322.FROM. > The 5322.Sender would not exist until a submission takes place and that > submission should never happen. =C2=A0A legacy spoofer (unintentional/ran= dom > usage of IBM) and SPF faker (intentional facsimile to spoof) would never = get > entry when RFC4408 is 100% followed. > "SHOULD NOT" does not mean "WILL NEVER" - bad people do bad abusive things. I will also point out that I did not include EHLO or SUBMITTER in my example. And I point out to you that RFC 4408 has nothing to do with PRA. The operative section of RFC 4407 (which DOES have something to do with PRA= ) is: 3. Select all the non-empty Sender headers in the message. If there are no such headers, continue with step 4. If there is exactly one such header, proceed to step 5. If there is more than one such header, proceed to step 6. So if their is a single non-empty Sender header then that will ALWAYS be the PRA. This invites abuse when PRA can be set to any arbitrary domain unrelated to the Mail From domain. I From spf2@kitterman.com Sun Apr 15 10:51: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 6A86921F882C for ; Sun, 15 Apr 2012 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bXFSQb1ESaj for ; Sun, 15 Apr 2012 10:51:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7DE21F8839 for ; Sun, 15 Apr 2012 10:51:35 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 314BD20E40CC; Sun, 15 Apr 2012 13:51:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334512294; bh=8WwWUbT2G6SSbAe0HCzeJfsHC5ZKs85HduwbYyFTL/g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=UAUz78lfKZQy/nmGGBadxPl7IrCSbovDptwfMzrNa6cEPH8PTqQ+c7ZsQIb8Ou9Kg D/NJdwPFJGIdbGL5xUmPilCQonDmr5GG11l9cRoAxytx/tJkTeuNhtx4W6i2vBVe3h t7eszFMZbw24L25oF/3Nw8NxanRRnt1Ra5iO6tZE= Received: from scott-latitude-e6320.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 ESMTPSA id 180A020E40BD; Sun, 15 Apr 2012 13:51:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 15 Apr 2012 13:51:33 -0400 Message-ID: <3639456.f5VoNRbFlk@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8A812B.1030505@isdg.net> References: <20120324090349.15462.qmail@joyce.lan> <2544259.KoaNgMjTDF@scott-latitude-e6320> <4F8A812B.1030505@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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 17:51:36 -0000 On Sunday, April 15, 2012 04:04:59 AM Hector Santos wrote: > Scott Kitterman wrote: > >>> Personally, I don't see any value in 5321.SUBMITTER. > >> > >> Ok, tell us why? > > > > At the envelop layer SUBMITTER is a made up ID that carries a promise that > > later, if you go to DATA, you'll discover has some relevance to a header > > in > > the body. It could be anything. I don't see any value in knowing before > > DATA that resent-sender is some particular domain. > > Scott, by design, it is basically a sanity or double check when there > is a pass because if the SUBMITTER SPF policy was violated at 5321, > per spec, the receiver SHOULD reject the transaction and there would > be no reaching of the DATA state in order to get the payload. Its a > two step checking concept: > > http://tools.ietf.org/html/rfc4405#section-4.2 > > Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD > select the domain part of the SUBMITTER address value as the > purported responsible domain of the message, and SHOULD perform such > tests, including those defined in [SENDER-ID], as are deemed > necessary to determine whether the connecting SMTP client is > authorized to transmit e-mail messages on behalf of that domain. > > [STEP 1 - ENVELOPE TEST, NO PAYLOAD] > > If these tests indicate that the connecting SMTP client is not > authorized to transmit e-mail messages on behalf of the SUBMITTER > domain, the receiving SMTP server SHOULD reject the message and when > rejecting MUST use "550 5.7.1 Submitter not allowed." > > [STEP 2 - PAYLOAD "DOUBLE CHECK" TEST] > > If the receiving SMTP server allows the connecting SMTP client to > transmit message data, then the server SHOULD determine the purported > responsible address of the message by examining the RFC 2822 message > headers as described in [PRA]. If this purported responsible address > does not match the address appearing in the SUBMITTER parameter, the > receiving SMTP server MUST reject the message and when rejecting MUST > use "550 5.7.1 Submitter does not match header." > > The 2nd "double checking" step per se, is specifically encourage in > this section and in the security section. But if the failure does > occur at step 1, then there is no payload checking need. In addition, > it should be noted that the the above 2nd check and action, presumes > an advanced receiver with payload filtering hooks, shims and/or > callouts before the DATA "End of Data" server response is issued. Just > a reminder that acceptance is not desirable if there going to be a > failure point. The only solution to that is a DISCARD concept when is > hinted/described in SenderID (4406) intro: > > This document describes a mechanism such that receiving Mail Transfer > Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents > (MUAs) can recognize mail in the above category and take appropriate > action. For example, an MTA might refuse to accept a message, an MDA > might discard a message rather than placing it into a mailbox, and an > MUA might render that message in some distinctive fashion. Yes. I've read the relevant RFCs and understand the design. My feeling that they are pointless is not based on ignorance. Here's an example for you: 5321.Mail From: good.example.com 4405.Submitter: bad.example.net 5322.From: good.example.com 5322.Resent Sender: bad.example.net 4407.PRA: bad.example.net In this example the connecting IP address gets a pass result for bad.example.net and a fail result for good.example.com. As the receiver is preparing to decide if they want to go to DATA or not they have two conflicting facts to consider: 1. SPF (or SPF2.0/mfrom) fail result 2. SUBMITTER pass result How is this conflict to be resolved? Reading RFCs won't explicitly help as none of them will tell you (thus my earlier point that there is no integrated protocol). RFC 4405 says one should go to DATA and see if PRA and SUBMITTER match. The inferred design here is "If submitter passes, ignore SPF". If you support SUBMITTER, then you've handed everyone a chance to bypass SPF. For this example, let's say we follow the advice of 4405 and go to data. We can then determine that SUBMITTER and PRA match and the message gets a SenderID pass. Then what? You have a domain name from a header field that no one will see and isn't used for anything that was authorized. To do anything, you'd still need to decide if this is a good domain or a bad domain (i.e. reputation system and "batteries required") since it's a domain name that's not related to anything in the message that users or operators see/use. SPF and SenderID are by design incompatible. SenderID can only work by ignoring SPF. It is a happy coincidence that in the vast majority of cases they produce the same result, but that is not at all the same thing as having an integrated or interoperable design. Scott K From hsantos@isdg.net Mon Apr 16 02: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 4D60221F86FC for ; Mon, 16 Apr 2012 02:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MhBH5u+FBMY for ; Mon, 16 Apr 2012 02:44:20 -0700 (PDT) Received: from ftp.catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0E29521F86FA for ; Mon, 16 Apr 2012 02:44:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4025; t=1334569451; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=RY7g4F1X4TNSAxLSc65avbZ8QvI=; b=H6NnxdKyDadxsOe9qwpi LDB2Ds+XRnn6QM47DcDRi+Is46QVcCf3Ofp5wd59GiiS2HMnqYkcK7jBlxi+wDio sRJ+mrRzrB8yc2LNitdlJkU4yhGMuCeWafxlIQCUcpvWgdtMjcGgcHkURUXasq4w SimwkyEfVnLuRQMgXYzlMKM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 16 Apr 2012 05:44: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3476275958.28057.3420; Mon, 16 Apr 2012 05:44:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4025; t=1334569126; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QHrEh+c 3gOZN6dkrPT5Ff2valTIajZFfwwJPrGhStN8=; b=d6QZ7e+t4LWcz6igeDUF/Yz 5OvSxc57JnIloaiydxsZEixT7u4udEt/xEdhhZIh5ZDeQPaH3YWDWCMQ0/sj70zt PxZPmmJQpslaZCqxCMLfJq7U6dtZrRQ6+zxcjxO2QxCVrCf4YJanM2H9ir1Qkf/E cjeuyKu5lXLWWbCQjj0M= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 16 Apr 2012 05:38:46 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4075181205.1631.7276; Mon, 16 Apr 2012 05:38:45 -0400 Message-ID: <4F8BE9BE.8060908@isdg.net> Date: Mon, 16 Apr 2012 05:43:26 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dotzero References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> <4F8A4EAC.6020402@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:44:21 -0000 Hi, Thanks for your input. Question, do you believe the WG should review the concerns and propose protocol corrections learned from 6+ years of field testing? Thanks -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com Dotzero wrote: > On Sun, Apr 15, 2012 at 12:29 AM, Hector Santos wrote: >> Dotzero wrote: >> >>>>> Hector: >>>>> >>>>> In essence what you were suggesting there was no valid PRA use case. >>>>> Thats not a technical �opinion, but a policy mandate. �Should I >>>>> believe you or claims by others that the PRA works great with >>>>> RESENT-FROM headers? >> >>>> Scott: >>>> >>>> It depends on what you mean by great. �PRA is useful if you are worried >>>> about >>>> resent-sender forgery. �I am not. �Other than that, it just gives you a >>>> domain >>>> to use as an input to a reputation system and as such is a "batteries >>>> needed" >>>> protocol and not particularly useful in itself. >> >>> I'm getting tired of repeating this, but PRA is BROKEN. Pick a domain >>> that has a naked "-all" - ibm.com for example. Create a message with a >>> Mail From and From purporting to be from ibm.com. Now add a Sender >>> field from a random domain that does not publish an SPF record (of any >>> sort). The PRA will be the random domain. What this means is that a >>> bad guy can consistently game PRA to get a neutral result by using >>> random non publishing domains. BROKEN! >> >> You should be tired because this is not the premise for getting rid of it. >> However, it should be because that was the original 2006 issue with the >> integration of SPF with the PRA concept introduced by Microsoft. >> >> No one has every stated, now these protocol say it is perfect or that it >> covers all cases. Yet, there are those who stated with technical >> experience, there are PRA use cases where it works great. I believe it is >> when Resent-Sender is involved, and now that we have 6+ years of field >> testing, we should see what the actual payoff is or not and review the >> conflicts in detail, if any. >> >> BTW, it should be noted the example with IBM.COM is probably not good >> because it has a SPF v1.0 policy statement and the PRA does not apply. >> > > You seem to forget the appropriation of spf1 records for the use of senderid. > >> "v=spf1 -all" >> >> This basically states a corporate policy: >> >> NO EMAIL EXPECTED USING THE IBM.COM DOMAIN. >> >> It is a clear legal corporate mandate statement that no one nor anything is >> expected use the IBM.COM domain for sending email, from anywhere and from >> anyone - No Exceptions. >> >> Overall, the PRA does not apply here because any original submission SHOULD >> NOT ever exist with IBM.COM in 5321.EHLO or 5321.MAILFROM or 5322.FROM. >> The 5322.Sender would not exist until a submission takes place and that >> submission should never happen. A legacy spoofer (unintentional/random >> usage of IBM) and SPF faker (intentional facsimile to spoof) would never get >> entry when RFC4408 is 100% followed. >> > > "SHOULD NOT" does not mean "WILL NEVER" - bad people do bad abusive > things. I will also point out that I did not include EHLO or SUBMITTER > in my example. And I point out to you that RFC 4408 has nothing to do > with PRA. > > The operative section of RFC 4407 (which DOES have something to do with PRA) is: > > 3. Select all the non-empty Sender headers in the message. If there > are no such headers, continue with step 4. If there is exactly > one such header, proceed to step 5. If there is more than one > such header, proceed to step 6. > > So if their is a single non-empty Sender header then that will ALWAYS > be the PRA. This invites abuse when PRA can be set to any arbitrary > domain unrelated to the Mail From domain. > > I > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From dotzero@gmail.com Mon Apr 16 06:24: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 87C0421F863C for ; Mon, 16 Apr 2012 06:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmFs3ewIPvqV for ; Mon, 16 Apr 2012 06:24:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F39821F8639 for ; Mon, 16 Apr 2012 06:24:33 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so4302790pbb.31 for ; Mon, 16 Apr 2012 06:24: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:content-transfer-encoding; bh=MIS4PKDWqmRU1dUqdiBa9oq7B6D3l/PzFrIjO8ZbJAs=; b=k+XKMBpyzyow2ZRUd6FyzUTQ4nCV45AKxrvj0cbWbhgCS5sm5QhPs/A8EhNFF+cysc cmcgbt/CAWy4bIZC6FRV2PVd6B35uPjTutowDvU4szrbH7CqmHLZgbjQNlHHBq86E997 KP2p5Gy87Z49gYVm5iG7RKBLi9T34B1pmsuR8BaaTr8wME2cv52yTDNqQ4YIwIORSZlQ 72eaRtWQ3xUkwBV2Et2dlfTGLH106EDAJk4J0a32ZRf+OjYDrsnPw7VlLukq3U2ebhMz 1IjmqgIJ+8SUAVfEWJFeimg/pamoc8juux49e0pL20LAQiB8eBfiNKbJ7p4Pur+8sAAB qi1g== MIME-Version: 1.0 Received: by 10.68.217.199 with SMTP id pa7mr14240414pbc.18.1334582673159; Mon, 16 Apr 2012 06:24:33 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Mon, 16 Apr 2012 06:24:33 -0700 (PDT) In-Reply-To: <4F8BE9BE.8060908@isdg.net> References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> <4F8A4EAC.6020402@isdg.net> <4F8BE9BE.8060908@isdg.net> Date: Mon, 16 Apr 2012 09:24:33 -0400 Message-ID: From: Dotzero To: Hector Santos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 13:24:34 -0000 My understanding is that the WG focus is on updating 4408. If folks want to do an additional document detailing the "experiment(s)", I have no problem with that - but let's not confuse the two. Updating SenderID (including PRA) was not part of the charter for this working group (I will defer to the Chairs if they feel my statement is incorrect) so why you keep on trying to drag it in-scope without a re-charter is beyond me. Mike On Mon, Apr 16, 2012 at 5:43 AM, Hector Santos wrote: > Hi, > > Thanks for your input. =C2=A0Question, do you believe the WG should revie= w the > concerns and propose protocol corrections learned from 6+ years of field > testing? > > Thanks > > > -- > Hector Santos, CTO > http://www.santronics.com > http://hector.wildcatblog.com > > Dotzero wrote: >> >> On Sun, Apr 15, 2012 at 12:29 AM, Hector Santos wrote= : >>> >>> Dotzero wrote: >>> >>>>>> Hector: >>>>>> >>>>>> In essence what you were suggesting there was no valid PRA use case. >>>>>> Thats not a technical =EF=BF=BDopinion, but a policy mandate. =EF=BF= =BDShould I >>>>>> believe you or claims by others that the PRA works great with >>>>>> RESENT-FROM headers? >>> >>> >>>>> Scott: >>>>> >>>>> It depends on what you mean by great. =EF=BF=BDPRA is useful if you a= re worried >>>>> about >>>>> resent-sender forgery. =EF=BF=BDI am not. =EF=BF=BDOther than that, i= t just gives you a >>>>> domain >>>>> to use as an input to a reputation system and as such is a "batteries >>>>> needed" >>>>> protocol and not particularly useful in itself. >>> >>> >>>> I'm getting tired of repeating this, but PRA is BROKEN. Pick a domain >>>> that has a naked "-all" - ibm.com for example. Create a message with a >>>> Mail From and From purporting to be from ibm.com. Now add a Sender >>>> field from a random domain that does not publish an SPF record (of any >>>> sort). The PRA will be the random domain. What this means is that a >>>> bad guy can consistently game PRA to get a neutral result by using >>>> random non publishing domains. BROKEN! >>> >>> >>> You should be tired because this is not the premise for getting rid of >>> it. >>> However, it should be because that was the original 2006 issue with the >>> integration of SPF with the PRA concept introduced by Microsoft. >>> >>> No one has every stated, now these protocol say it is perfect or that i= t >>> covers all cases. =C2=A0Yet, there are those who stated with technical >>> experience, there are PRA use cases where it works great. I believe it = is >>> when Resent-Sender is involved, and now that we have 6+ years of field >>> testing, we should see what the actual payoff is or not and review the >>> conflicts in detail, if any. >>> >>> BTW, it should be noted the example with IBM.COM is probably not good >>> because it has a SPF v1.0 policy statement and the PRA does not apply. >>> >> >> You seem to forget the appropriation of spf1 records for the use of >> senderid. >> >>> =C2=A0 =C2=A0 =C2=A0"v=3Dspf1 -all" >>> >>> This basically states a corporate policy: >>> >>> =C2=A0 =C2=A0 NO EMAIL EXPECTED USING THE IBM.COM DOMAIN. >>> >>> It is a clear legal corporate mandate statement that no one nor anythin= g >>> is >>> expected use the IBM.COM domain for sending email, from anywhere and fr= om >>> anyone - No Exceptions. >>> >>> Overall, the PRA does not apply here because any original submission >>> SHOULD >>> NOT ever exist with IBM.COM in 5321.EHLO or 5321.MAILFROM or 5322.FROM. >>> The 5322.Sender would not exist until a submission takes place and that >>> submission should never happen. =C2=A0A legacy spoofer (unintentional/r= andom >>> usage of IBM) and SPF faker (intentional facsimile to spoof) would neve= r >>> get >>> entry when RFC4408 is 100% followed. >>> >> >> "SHOULD NOT" does not mean "WILL NEVER" - bad people do bad abusive >> things. I will also point out that I did not include EHLO or SUBMITTER >> in my example. And I point out to you that RFC 4408 has nothing to do >> with PRA. >> >> The operative section of RFC 4407 (which DOES have something to do with >> PRA) is: >> >> 3. Select all the non-empty Sender headers in the message. =C2=A0If ther= e >> =C2=A0 =C2=A0 =C2=A0are no such headers, continue with step 4. =C2=A0If = there is exactly >> =C2=A0 =C2=A0 =C2=A0one such header, proceed to step 5. =C2=A0If there i= s more than one >> =C2=A0 =C2=A0 =C2=A0such header, proceed to step 6. >> >> So if their is a single non-empty Sender header then that will ALWAYS >> be the PRA. This invites abuse when PRA can be set to any arbitrary >> domain unrelated to the Mail From domain. >> >> I >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > > > From dhc@dcrocker.net Mon Apr 16 06:50: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 7D44D21F86A3 for ; Mon, 16 Apr 2012 06:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRWnpUKI48ef for ; Mon, 16 Apr 2012 06:50:58 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4019421F86EC for ; Mon, 16 Apr 2012 06:50:58 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3GDogBc001516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2012 06:50:46 -0700 Message-ID: <4F8C23AF.6020005@dcrocker.net> Date: Mon, 16 Apr 2012 06:50:39 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120324090349.15462.qmail@joyce.lan> <13757064.SIaPQFyNoO@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280D27DC@exch-mbx901.corp.cloudmark.com> <2223291.Gx3ANL6thl@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280D284C@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280D284C@exch-mbx901.corp.cloudmark.com> 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]); Mon, 16 Apr 2012 06:50:46 -0700 (PDT) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 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, 16 Apr 2012 13:50:59 -0000 On 4/10/2012 4:15 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Scott Kitterman >> Sent: Tuesday, April 10, 2012 4:08 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 >> >> ADSP is not part of the core DKIM protocol. It's a after the fact >> bolt-on, so it's a bit different. > > Other than the fact that they're in separate documents, how are they different? It is a value-add protocol that sits on top of DKIM. As such, it counts as a separate mechanism. It deals with very different semantics than DKIM. You are presumably in a building right now. You rely on that building but you are not "part" of it nor are you "similar" to it. ADSP's relationship to DKIM is the same as your relationship to the building. In terms of "building upon", the Repute wg is "similar" to ADSP or DMARC, in that it builds upon the authentication work of DKIM and SPF, but it is separate work, not merely separate documentation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Apr 16 06: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 6275E21F862F for ; Mon, 16 Apr 2012 06:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4djLfWJvy2kQ for ; Mon, 16 Apr 2012 06:59:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA4BB21F862B for ; Mon, 16 Apr 2012 06:59:45 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3GDxgPD001758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2012 06:59:45 -0700 Message-ID: <4F8C25CD.2070901@dcrocker.net> Date: Mon, 16 Apr 2012 06:59:41 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120324090349.15462.qmail@joyce.lan> <1740601.l8OcLQSMQM@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280D28B8@exch-mbx901.corp.cloudmark.com> <1494108.a5MQrbFgDA@scott-latitude-e6320> In-Reply-To: <1494108.a5MQrbFgDA@scott-latitude-e6320> 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]); Mon, 16 Apr 2012 06:59:45 -0700 (PDT) Cc: spfbis@ietf.org Subject: [spfbis] forwarding vs. ... 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, 16 Apr 2012 13:59:46 -0000 On 4/10/2012 4:47 PM, Scott Kitterman wrote: > DKIM > signatures should survive forwarding, This being a technical discussion, please forgive my being picky about vocabulary, but precision and accuracy in the discussion matter. Per RFC 5598, "forwarding" is not the same as "relaying". Relaying is what MTAs do; they do not change the message. Forwarding is what MUAs sometimes do, which means re-posting a new message, usually with significant changes to the original message. DKIM is design to survive relaying. Whether it survives "forwarding" depends on what the MUA -- like a mailing list -- does in creating the new message. On the average, one should not expect a DKIM signature to survive forwarding. The rest of your note makes clear that you meant all of the above; I really am only being picky about the wording, not because your note seemed confused but because so many people who discuss this topic often confuse relaying with forwarding. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Apr 16 07:02: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 27B3B21F8710 for ; Mon, 16 Apr 2012 07:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wD89rZ02JMs for ; Mon, 16 Apr 2012 07:02:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0D21F870E for ; Mon, 16 Apr 2012 07:02:32 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3GE2Rf9001833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2012 07:02:31 -0700 Message-ID: <4F8C2673.9050001@dcrocker.net> Date: Mon, 16 Apr 2012 07:02:27 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dotzero References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> In-Reply-To: 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]); Mon, 16 Apr 2012 07:02:31 -0700 (PDT) Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 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, 16 Apr 2012 14:02:33 -0000 On 4/14/2012 5:07 PM, Dotzero wrote: > I'm getting tired of repeating this, but PRA is BROKEN. I'm not understanding why this is being discussed now. I thought this topic had been dispatched some time ago. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Apr 16 07:04: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 D329321F870E for ; Mon, 16 Apr 2012 07:04: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HDChly2I0Wq for ; Mon, 16 Apr 2012 07:04:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 66ABC21F862F for ; Mon, 16 Apr 2012 07:04:24 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3GE4KNH001893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Apr 2012 07:04:24 -0700 Message-ID: <4F8C26E4.1090401@dcrocker.net> Date: Mon, 16 Apr 2012 07:04:20 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120324090349.15462.qmail@joyce.lan> <4F875085.1060702@isdg.net> <4F87F3F1.7050503@tana.it> <3719298.HRTXbQIGjb@scott-latitude-e6320> <4F884D50.8070705@tana.it> <4F886976.7080800@sonnection.nl> <9452079D1A51524AA5749AD23E0039280EFF1A@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFF1A@exch-mbx901.corp.cloudmark.com> 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]); Mon, 16 Apr 2012 07:04:24 -0700 (PDT) Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 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, 16 Apr 2012 14:04:24 -0000 On 4/13/2012 10:55 AM, Murray S. Kucherawy wrote: >> I have to agree with Scott here. There are many many other situations >> > where SPF is not designed for. I have several customers using hosted >> > AS/AV services like Postini and MessageLabs and it makes no sense >> > whatsoever performing SPF checks on any intermediate internal >> > MSA's/MTA's between an internal mail client and the exterior AV/AS >> > service. We're not going to document that either. > +1, and also +1 to the point that we don't want to start down the path of documenting everything SPF isn't. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Mon Apr 16 08:10: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 2713411E808E for ; Mon, 16 Apr 2012 08:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP-AM4nBMLyd for ; Mon, 16 Apr 2012 08:10:31 -0700 (PDT) Received: from mail.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D663111E8081 for ; Mon, 16 Apr 2012 08:10:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2249; t=1334589026; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=YqBLDOPQbi8OYgLVw3vN5FDduFk=; b=FQib4jdFk/nnHAKTnCDE aNNVtC7fJbXVAKebu66WG71XlgQvv81/5RSqKADm/J2IDbG40n1RN2VCzihLMqUz Mg7Rwdkf07tAyj7Hk2G1yJmpuSAptH5KWf9DFAYASP7tpnwMeDV4vllaaGeng/NE ecFyuqMfANvkAU0ir6PQwYQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 16 Apr 2012 11:10:26 -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 v6.4.454.1) with ESMTP id 3495851338.28057.2004; Mon, 16 Apr 2012 11:10:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2249; t=1334588698; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=V+TmV3/ WJLPLFHIGbWU64K69OiwdU8CqL9xzzf+Ngmw=; b=0/PN3FdhYrUGjX3Cu0WU6NL fvBCL83fpBGGFdLo2isNiEfoTJ9tTxyTKFzH80fcgzVp7hfZ+LHXJiDVxMRxOBE+ z3yf+oYuz2kN8Qab5P5Bw3CxCAL571UCDcnofy0vy3/nZy1OxI2eS7erU5Ox+eVo 6RQPOsLImzCOlrh0Qg6M= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 16 Apr 2012 11:04:58 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4094753846.1678.236; Mon, 16 Apr 2012 11:04:57 -0400 Message-ID: <4F8C3634.6020707@isdg.net> Date: Mon, 16 Apr 2012 11:09:40 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dotzero References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> <4F8A4EAC.6020402@isdg.net> <4F8BE9BE.8060908@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:10:34 -0000 > On Mon, Apr 16, 2012 at 5:43 AM, Hector Santos wrote: >> Hi, >> >> Thanks for your input. Question, do you believe the WG should review the >> concerns and propose protocol corrections learned from 6+ years of field >> testing? >> >> Thanks Dotzero wrote: > My understanding is that the WG focus is on updating 4408. If folks > want to do an additional document detailing the "experiment(s)", I > have no problem with that - but let's not confuse the two. Updating > SenderID (including PRA) was not part of the charter for this working > group (I will defer to the Chairs if they feel my statement is > incorrect) so why you keep on trying to drag it in-scope without a > re-charter is beyond me. Because I don't agree and its doesn't make engineering sense to me that a charter with predetermined conclusions on a protocols fate where, as you suggest, is actually out of scope. You can't have it both ways because you are for all intent and purpose telling commercial vendors to DROP something and the reasons are not sound. Its OUT OF SCOPE, but BTW we decided to KILL it. That doesn't make sense to me. And what is beyond me that all the 6+ years of Corporate marketing is just all of sudden - puff- LOST. Can you tell me what will happen here? http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx http://www.microsoft.com/mscorp/safety/technologies/senderid/support.mspx We we saying all these companies no longer support SenderID? That is, quite frankly, is whats beyond me and quite frankly I serious think there is serious underestimating on the repercussions of the the desired abandonment without any real review as to why. At the very least I am trying to get a focus on the issue based on technical merits of the original proposal, the IETF interest on its co-existence and the 6+ years of field testing experiment conclusions, not a false fallacy, extremely bias situation that a) its not in use, b) the original use cases are indeed invalid and c) what appears is a lack of understanding on it works in an integrated, excuse me, in "TANDEM" fashion/ -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From spf2@kitterman.com Mon Apr 16 10:10: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 33E8C11E80EA for ; Mon, 16 Apr 2012 10:10: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnUv9dqpwqD8 for ; Mon, 16 Apr 2012 10:10:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 431EA21F85D0 for ; Mon, 16 Apr 2012 10:09:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 40F8120E40CC; Mon, 16 Apr 2012 13:09:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334596189; bh=GQe5oZlNJ62/BuYKzEp7IYMwjXnEKrHp6DQouZkxIo0=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=ndIBptltUBEEbKXKmFLceH0gj09AbpoFgXJ8REL3DeeBiZ518duZQFCX296B9ELrx 1XlDUq4BepEN263RIcMif6WL9arM40xBzDldvxPzO4aBPzIpKBRgf8pTRBh77rwj9l nK3xjeP4h21mE4TyKKxudYxsvY2tII9BqvXVCEpY= Received: from scott-latitude-e6320.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 ESMTPSA id 2386320E408E; Mon, 16 Apr 2012 13:09:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Apr 2012 13:09:47 -0400 Message-ID: <1369712.Mmu5T1SMRF@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Fwd: Expiration impending: X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:10:10 -0000 Since the working group hasn't expressed any interest in picking up this draft, my intent is to let it expire. FYI, Scott K ---------- Forwarded Message ---------- Subject: Expiration impending: Date: Monday, April 16, 2012, 04:42:16 AM From: IETF Secretariat To: D. Kitterman , Wayne Schlitt The following draft will expire soon: Name: draft-kitterman-4408bis Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in E- Mail, Version 1 State: I-D Exists Expires: 2012-04-26 (in 1 week, 2 days) ----------------------------------------- From ajs@anvilwalrusden.com Mon Apr 16 10:39: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 4434B11E80AB for ; Mon, 16 Apr 2012 10:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTW702Nc65v8 for ; Mon, 16 Apr 2012 10:39:04 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8002911E809C for ; Mon, 16 Apr 2012 10:39:04 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 0B6351ECB41D; Mon, 16 Apr 2012 17:38:52 +0000 (UTC) Date: Mon, 16 Apr 2012 13:38:51 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120416173851.GG49880@mail.yitter.info> References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> <4F8A4EAC.6020402@isdg.net> <4F8BE9BE.8060908@isdg.net> <4F8C3634.6020707@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8C3634.6020707@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:39:05 -0000 Colleagues, Hat on. On Mon, Apr 16, 2012 at 11:09:40AM -0400, Hector Santos wrote: > both ways because you are for all intent and purpose telling > commercial vendors to DROP something and the reasons are not sound. > Its OUT OF SCOPE, but BTW we decided to KILL it. That doesn't make > sense to me. [. . .] > We we saying all these companies no longer support SenderID? [. . .] > conclusions, not a false fallacy, extremely bias situation that a) > its not in use, b) the original use cases are indeed invalid and c) > what appears is a lack of understanding on it works in an > integrated, excuse me, in "TANDEM" fashion/ I think we need to be clear on what we are asked to do. First, we are asked to report on the experiment. The conditions for the experiment are not exactly clear, but the WG's experiment document gives an interpretation. If there is a clear disagreement with that interpretation and an alternative approach for interpreting the experiment, we did not receive a draft proposing it, despite having asked for such a draft. If, however, someone wants to produce a draft with such an alternative intepretation and ask that it be considered by the WG instead, then one is free to do so. If one intends to do that, it would be a good idea to do it as soon as possible, since we seem otherwise to be converging rapidly on the conclusions in the present WG draft. Objections that do not propose specific changes to the WG draft are not helpful in clarifying what needs to change. Second, we are asked to create an update of SPF for the standards track. That action has nothing at all to say about other things in the experiment. The IETF is not the protocol cops, and there is no reason whatever that we have to say anything about whether people continue to use SenderID or any other technology. The RFC series is an archival series, and those experimental RFCs will persist even if every single person participating in this WG thinks that they're bad ideas. In conclusion, then, 1. if anyone disagrees with specific parts of the WG's experiment document, then send text; 2. if anyone disagrees with the foundational assumptions of the WG's experiment document, then propose an alternative. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From dotzero@gmail.com Mon Apr 16 11:44: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 2670F21F8686 for ; Mon, 16 Apr 2012 11:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa5JLiaPmZTt for ; Mon, 16 Apr 2012 11:44:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFE1A21F8680 for ; Mon, 16 Apr 2012 11:44:13 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so4630563pbb.31 for ; Mon, 16 Apr 2012 11:44: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=HLweaUBbSWFyaiaPKUWyom6p8YC5e02Ix7R06/DioeE=; b=Xf4tc6PtYRQ5KBvYMVyTrSVGM66qH7fMVyTe99sr8KAiZ6gWcoAuhtQeLuTysown/h OrXUkgH/OEEuZvdv9Evcc6FMM2O+D3Kl+Yag7RBekfnUFIONKL8jE+jLkI7knZCKt5O0 3itei8PoWOQo2cbO2P3O3SvepFlWdMoaZF5t9KT/+8NhZxdJPkLjrosLTLyPgHXU1u9A MjzEunzW8OzBUa3zCsKg9zGEhg3tr0S2YqBw5tnI/o/j1h/RH2ygA/dRtDI+88IvsfFs mr5SjuUSrCFfVh2tzO3S5R5RMKzMxTWBrJ60NqnVvy8Lt7PgKa2SQNb3d051O6cOJu8i gEvQ== MIME-Version: 1.0 Received: by 10.68.202.163 with SMTP id kj3mr29495757pbc.165.1334601853501; Mon, 16 Apr 2012 11:44:13 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Mon, 16 Apr 2012 11:44:13 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280F17E8@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280EFF59@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F17E8@exch-mbx901.corp.cloudmark.com> Date: Mon, 16 Apr 2012 14:44:13 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 18:44:14 -0000 On Sat, Apr 14, 2012 at 2:55 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of John R Levine >> Sent: Friday, April 13, 2012 2:58 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 >> >> A few minor points: >> [...] > > Thanks, all incorporated for the next version. > > -MSK > > Reviewed http://www.ietf.org/id/draft-ietf-spfbis-experiment-02.txt and I'm comfortable with it overall. My only question is one of curiosity and does not need to be addressed as far as I'm concerned: Section 3.1 - For the 6,887 records that start with "spf2.0/", it would have been useful to further break this down into how many specify MFROM and how many specify PRA. My only other comment is to restate that PRA can consistently be gamed by abusers so as to gain a "neutral" outcome regardless of what the domain in the Mail From asserts. This might appropriately be documented. Despite these two minor quibbles I agree with the document overall and the reommendations to the IESG. Mike From SRS0=98fE5=CW==stuart@gathman.org Mon Apr 16 12:21: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 4CD6511E80C1 for ; Mon, 16 Apr 2012 12:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZw0Wsv--yiX for ; Mon, 16 Apr 2012 12:21:27 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2804311E80AD for ; Mon, 16 Apr 2012 12:21:27 -0700 (PDT) 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 q3GJLGIO029771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 15:21:16 -0400 Message-ID: <4F8C712C.6090008@gathman.org> Date: Mon, 16 Apr 2012 15:21:16 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> <4F8A4EAC.6020402@isdg.net> <4F8BE9BE.8060908@isdg.net> <4F8C3634.6020707@isdg.net> In-Reply-To: <4F8C3634.6020707@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 20:26:35 -0000 Long ago, Nostradamus foresaw that on 04/16/2012 11:09 AM, Hector Santos would write: > > Because I don't agree and its doesn't make engineering sense to me > that a charter with predetermined conclusions on a protocols fate > where, as you suggest, is actually out of scope. You can't have it > both ways because you are for all intent and purpose telling > commercial vendors to DROP something and the reasons are not sound. > Its OUT OF SCOPE, but BTW we decided to KILL it. That doesn't make > sense to me. > > And what is beyond me that all the 6+ years of Corporate marketing is > just all of sudden - puff- LOST. While Sender-ID hasn't gotten much use, my personal opinion is that it could get more use if the technical conflict with SPF (interpreting v=spf1 records as spf2.0/mfrom,pra) was formally fixed. The technical conflict forces people to choose between the two protocols, rather than trying them both. It is not too late to make that fix and compare SID with DKIM in practice. Making that fix is out of scope for this WG, however. From msk@cloudmark.com Mon Apr 16 14:09: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 21D4821F866D for ; Mon, 16 Apr 2012 14:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVQ0s4XM8JWX for ; Mon, 16 Apr 2012 14:09:48 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D71721F866A for ; Mon, 16 Apr 2012 14:09:48 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id yl9u1i0010ZaKgw01l9uZF; Mon, 16 Apr 2012 14:09:54 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=NYRkJh/4 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=3Oi21VZ3JeAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=UOFKrJZXeFh3SqWk37gA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 14:09:37 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 Thread-Index: AQHNGcCai4FkTeymQEGmbWrF0MI1vJaZ4nQwgARhOYD//6/joA== Date: Mon, 16 Apr 2012 21:09:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F3E3A@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280EFF59@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F17E8@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334610594; bh=ABsbrOlB8nbIG8r0SiW+1O1I1lMEaGsyCltW2N4u/AE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oiluXTmeNJr3uIRNi4FxLcm7g3ydTvSK7RBZSm5vUfrQ9LqOiMbOPpdrNeRrKBQUg OYTLv10AgLkKHWJPEwwtjLXIR/XIMLqhB8mdQ4wKDzkqS4zhdTChhCCEdvEvGf4FbP MeFSM6AcNxGu+QJ3LRuFHWQdMRiL91esNjqoctFc= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 21:09:49 -0000 > -----Original Message----- > From: Dotzero [mailto:dotzero@gmail.com] > Sent: Monday, April 16, 2012 11:44 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 >=20 > My only question is one of curiosity and does not need to be addressed > as far as I'm concerned: >=20 > Section 3.1 - For the 6,887 records that start with "spf2.0/", it would > have been useful to further break this down into how many specify MFROM > and how many specify PRA. I think I can add that; both Philip's survey and my own do contain that inf= ormation. If indeed it's easy to extract, I'll include it in -03. > My only other comment is to restate that PRA can consistently be gamed > by abusers so as to gain a "neutral" outcome regardless of what the > domain in the Mail From asserts. This might appropriately be > documented. I think the reasons that people picked one over the other can't be measured= without voluntary response to surveys that would take some time to craft a= nd run. This issue is undoubtedly on the list for some people, as might be IPR conc= erns. But I believe it's enough for us to include data we can actually col= lect and reach conclusions based on that. That is, we generally only need = to observe what the community chose to use, not so much why. > Despite these two minor quibbles I agree with the document overall and > the reommendations to the IESG. Thanks for the review! I'll post a -03 and perhaps request a working group= last call after one or two more. -MSK From sm@elandsys.com Mon Apr 16 15:06: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 4A4C411E808A for ; Mon, 16 Apr 2012 15:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EUm2FlXsLh7 for ; Mon, 16 Apr 2012 15:06: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 6B4B111E807F for ; Mon, 16 Apr 2012 15:06:13 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.220]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3GM5tTb009599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2012 15:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334613968; i=@elandsys.com; bh=Ie8YTC8HFnSjEnwz1h0Zxv8OIVvssjKC9Zu8zviR5/I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HhIXeJO2Yk12vF7yFWMRuGVkUKfOK38dMzMqLetP4KMNmiWuq+81S8HQ2F3163AsK pQznzClNHZNrGHu6ItGk27egy3rgLUG7ehNox8RsjzEOM7m8zPBg5deXWADcdzmEiY 1n1aYa4gk0gXBZ9XSf9ISjlhmr+fcHHL1T3NQrrA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334613968; i=@elandsys.com; bh=Ie8YTC8HFnSjEnwz1h0Zxv8OIVvssjKC9Zu8zviR5/I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OqerrL47tKJI7Jwpk0MJv4kt0U4lFc/u0dx08XVvXab9rglerTbPepuwFn/hjzc1m PxYznOZ2dBMU0TDArJncLHxukteYkFIcJ4H+6JnAdUya0kPIJ7deRkSvb2LPYshik8 EW0450lPP/h03+gFjK1Ug1JfZs43qQZEyL/n1DgE= Message-Id: <6.2.5.6.2.20120416135317.09f53ed0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Apr 2012 15:05:44 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F8C712C.6090008@gathman.org> References: <20120324090349.15462.qmail@joyce.lan> <3049024.WW88nJb152@scott-latitude-e6320> <4F88E852.6010607@isdg.net> <2544259.KoaNgMjTDF@scott-latitude-e6320> <4F8A4EAC.6020402@isdg.net> <4F8BE9BE.8060908@isdg.net> <4F8C3634.6020707@isdg.net> <4F8C712C.6090008@gathman.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Stuart D Gathman Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 22:06:14 -0000 At 12:21 16-04-2012, Stuart D Gathman wrote: >While Sender-ID hasn't gotten much use, my personal opinion is that >it could get more use if the technical conflict with SPF >(interpreting v=spf1 records as spf2.0/mfrom,pra) was formally >fixed. The technical conflict forces people to choose between the >two protocols, rather than trying them both. It is not too late to >make that fix and compare SID with DKIM in practice. Making that >fix is out of scope for this WG, however. I'll use the above as a basis for feedback. I gather that most of the group agree that there is a technical conflict. The next step is generally to agree on how to fix the technical conflict. My co-chair posted a message about that ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01182.html ). I'll quote part of his message: "First, we are asked to report on the experiment. The conditions for the experiment are not exactly clear, but the WG's experiment document gives an interpretation. If there is a clear disagreement with that interpretation and an alternative approach for interpreting the experiment [is welcome]." If the alternative is out of the scope of this WG, I cannot redefine the scope to fit that as it is beyond what I am allowed to do. If an alternative has been proposed and you don't see someone commenting, it may be that people did not understand that the person was proposing an alternative. Drop a note to the WG Chairs and one of us will ask you to clarify your proposal on this mailing list. It may also happen that other people do not support the alternative. It is up to the person proposing the alternative to reach out to other people and build support. Regards, S. Moonesamy From msk@cloudmark.com Mon Apr 16 16:00: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 6EC5821F8526 for ; Mon, 16 Apr 2012 16:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SEW7o2MD8e1 for ; Mon, 16 Apr 2012 16:00:46 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id A1F8721F851D for ; Mon, 16 Apr 2012 16:00:46 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id yn0l1i0010ZaKgw01n0laB; Mon, 16 Apr 2012 16:00:45 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=CMKorGXD c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=3Oi21VZ3JeAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=1N4MZ-oxfvayqWbfoO4A:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 16:00:45 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 Thread-Index: AQHNGcCai4FkTeymQEGmbWrF0MI1vJaZ4nQwgARhOYD//86CAA== Date: Mon, 16 Apr 2012 23:00:45 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F401A@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280EFF59@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F17E8@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334617246; bh=ZnNoNwOpiD3hSzBtvvh5yv71lR8XZeRIyhF9SuXodp4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=qp7Jw4AYlq3QM13KgRqDPVFdHoIILnDVS/2B4kqOsW+A/sSpb4eGaBRY/8ccQLb9l lB/OfCQMR4sGpfOOqJTALSxg9s1kPfjYNxwJpNmvDj7tfjLVkk3G3FSnJk7pE4nS4C MFmdReXVHU0ujjBuSpiJKC80yy0VxBMS9EJSLbqU= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 23:00:47 -0000 > -----Original Message----- > From: Dotzero [mailto:dotzero@gmail.com] > Sent: Monday, April 16, 2012 11:44 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 >=20 > Section 3.1 - For the 6,887 records that start with "spf2.0/", it would > have been useful to further break this down into how many specify MFROM > and how many specify PRA. The breakdown from my data is: 6329 spf2.0/pra 213 spf2.0/pra,mfrom 211 spf2.0/mfrom (which is just SPF) 134 spf2.0/mfrom,pra Is it worth including this breakdown in -03? Almost 97% of spf2.0/* record= s requested PRA handling. Philip's data contains similar numbers, certainly north of 90%. His data a= re available at the previously-given URL if anyone wants to run the queries= . -MSK From johnl@iecc.com Mon Apr 16 16:00: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 5695A21F854B for ; Mon, 16 Apr 2012 16:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.089 X-Spam-Level: X-Spam-Status: No, score=-111.089 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VvOXWM6YY0g for ; Mon, 16 Apr 2012 16:00: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 6F24721F851D for ; Mon, 16 Apr 2012 16:00:54 -0700 (PDT) Received: (qmail 29835 invoked from network); 16 Apr 2012 23:00:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Apr 2012 23:00: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=4f8ca4a5.xn--i8sz2z.k1204; i=johnl@user.iecc.com; bh=O/4uyEOFmgk9QvDTAoJbiocqqdRU0SS1Rxkn7zF4Jfs=; b=N2BjHt/jOi5b2KugPRGG1YP0fEkUAl4oupPJL41T9X6/mi3A0NeDlS6GTSPMxd3dTCPYklRlfg1sNKNH8AjCCrSnUCaVOl7eG7MxlkZTgKjSM8/ESNfhRt7AUx3b4txAf59gqUmgCBOR/eBmgvFuAjAfgKME2No+b5vYBe+j1W8= 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=4f8ca4a5.xn--i8sz2z.k1204; olt=johnl@user.iecc.com; bh=O/4uyEOFmgk9QvDTAoJbiocqqdRU0SS1Rxkn7zF4Jfs=; b=C9KRp1YrZDQhPUqgDm/sWIdVEzaaadc9TJm10qmrUJA8nZ5/z0aW6TLStJfJDRYvvngYoXT/UpgjMFGAt7Q2oryL4MRLing0ox16OOBXjr7s7h6ttYxUJBctsglrfekDYgvi+djV9FwHJJjYN0MMDA0+UYmSBAAmR0LwLsqaFjI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Apr 2012 23:00:31 -0000 Message-ID: <20120416230031.12409.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20120416135317.09f53ed0@resistor.net> 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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 23:00:55 -0000 In article <6.2.5.6.2.20120416135317.09f53ed0@resistor.net> you write: >At 12:21 16-04-2012, Stuart D Gathman wrote: >>While Sender-ID hasn't gotten much use, my personal opinion is that >>it could get more use if the technical conflict with SPF >>(interpreting v=spf1 records as spf2.0/mfrom,pra) was formally >>fixed. That would be something other than Sender-ID. Nobody really knows why Sender-ID didn't catch on, whether it was technical issues, uncertainly about the patent license, general hostility to Microsoft, or that people already had SPF and it was good enough. (In the absence of any data, I tend toward the last of those.) Anyone who was interested in Sender-ID has had the better part of a decade to invent new versions, nobody has, and doing so now most definitely is not our job. To wrap up the experiment, we just need to write up a document that says SPF has been widely adopted, Sender-ID hasn't, provide the evidence, and leave it at that. R's, John From dhc@dcrocker.net Mon Apr 16 16:19: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 6122521F853F for ; Mon, 16 Apr 2012 16:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ15a8M4wBUw for ; Mon, 16 Apr 2012 16:19:25 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C74EB21F853C for ; Mon, 16 Apr 2012 16:19:25 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3GNJ9mO013602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2012 16:19:12 -0700 Message-ID: <4F8CA8ED.2060704@dcrocker.net> Date: Mon, 16 Apr 2012 16:19:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: John Levine References: <20120416230031.12409.qmail@joyce.lan> In-Reply-To: <20120416230031.12409.qmail@joyce.lan> 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]); Mon, 16 Apr 2012 16:19:13 -0700 (PDT) Cc: spfbis@ietf.org, sm+ietf@elandsys.com Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 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, 16 Apr 2012 23:19:26 -0000 On 4/16/2012 4:00 PM, John Levine wrote: > To wrap up the experiment, we just need to write up a document that > says SPF has been widely adopted, Sender-ID hasn't, provide the > evidence, and leave it at that. +1 As much as it would be intellectually interesting to understand the 'why's of these successes and failures, we are currently left with the mere reality of them. That's the best we can document, at this stage, absent funding, time, research skill and quite a lot of energy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dotis@mail-abuse.org Mon Apr 16 16:19: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 A4A8221F8541 for ; Mon, 16 Apr 2012 16:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwsP47i2w8rW for ; Mon, 16 Apr 2012 16:19:27 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 27E2621F8539 for ; Mon, 16 Apr 2012 16:19:27 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id BF7691740097 for ; Mon, 16 Apr 2012 23:19:26 +0000 (UTC) Message-ID: <4F8CA8FE.4010201@mail-abuse.org> Date: Mon, 16 Apr 2012 16:19:26 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> In-Reply-To: <4F898D84.3050300@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 23:19:27 -0000 On 4/14/12 7:45 AM, Alessandro Vesely wrote: > On Sat 14/Apr/2012 16:12:56 +0200 Hector Santos wrote: >> Douglas Otis wrote: >> >>> The RFC5321 is not bound to a specific ADMD which is >>> where SPF framework fails. SPF does not permit valid operations of >>> http://tools.ietf.org/html/rfc5321#section-6.1 and >>> http://tools.ietf.org/html/rfc1123#section-5.2.6 which is why many >>> ignore "-all" and this represents a serious conflict that must be >>> resolved. >> Many? like who? > Gmail, for one. They register the failure, don't check the helo > identity, and deliver the message regularly. That's fine, IMHO. Agreed. >> anyone who is ignoring the -ALL policy is violating RFC4408 and >> worst, assuming product liability that was possibly repudiated by >> the domain policy. > SPF cannot guarantee that publishing -ALL ensures rejection. There > will always be SPF-ignorant servers, and servers like gmail that check > but don't reject. Receivers have found the experimental SPF (lacking SRS) does not permit normal SMTP operation as defined in rfc5321 section 6.1 and rfc1123 section 5.2.6. Rejection based on SPF will burden customer support when valid email becomes lost. Third-party domains should instead use SMTP compliant anti-phishing strategies, such as those found with DKIM, S/MIME, or OpenPGP. > Actually, it seems to me that those who reject can be accused of > breaking those SMTP features. To resolve the conflict we must devise > a safe way of rejecting, such that servers can adhere to it with no > risks. Our task is not to mandate it, but to enable it. Agreed. For example, this could be done using something as simple as incorporating the scope-ID used in RFC4406 to clarify applicable SMTP parameters with a list of EHLO / MFROM. When the scope contains just EHLO, only then will SPF verification offer a means to "authenticate" a source. EHLO also offers a safe means to ensure rejection will not interfere with normal SMTP operation. Since bounce addresses are normally not visible and might be UTF-8 encoded, only EHLO parameters in conjunction with DKIM signature alignment offers a reasonable level of exploitation protection. Of course, EHLO-only scopes should also exclude local-part macros. Regards, Douglas Otis From hsantos@isdg.net Mon Apr 16 16:32: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 08D5411E80EC for ; Mon, 16 Apr 2012 16:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSxCfrMVcf4f for ; Mon, 16 Apr 2012 16:32:28 -0700 (PDT) Received: from ftp.catinthebox.net (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 118BF11E80E4 for ; Mon, 16 Apr 2012 16:32:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2505; t=1334619137; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=AXsqf0BZrMNWmpvqKs9QlL2DYng=; b=kWdei6Jb7tY6M8sfxhPe VVQ8RswLVv8ZW2/R9bv0A1L8wZVR/u1v+HYFwbrWZnOIPTIpCkqUaKsMkMRwnmLw b9yTp3En2mlUuxdhxLZVeCMOGTbjYD6APXWCETQmI+uinAv4BwLHj7Myl1L1jsKJ YEhZUCHTZkXUsNnYhkfUW7Q= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 16 Apr 2012 19:32:17 -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 v6.4.454.1) with ESMTP id 3525961809.28057.5952; Mon, 16 Apr 2012 19:32:17 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2505; t=1334618808; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=/Nq+R8t uJFqFCYNMoN/KYAweXCjhhGivB38lzho5noY=; b=H5wB0r3JoIQF+ZW8S4nzSrg 5SuAZ6Yb3Q54YbqUCc/UW3I3df+9bnCASFAF+QgDld2Tgg58f1mYNS8mLcVZMgf5 DePm3KEX5DhxQmOEERjxVrA2Ens9GRLSyXx8ss0ONtbKuXRozy1RxyEBB+7Vcf5K CE4P4DOXHWDtqpjmikf0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 16 Apr 2012 19:26:48 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4124864346.1748.7300; Mon, 16 Apr 2012 19:26:48 -0400 Message-ID: <4F8CABE8.10007@isdg.net> Date: Mon, 16 Apr 2012 19:31:52 -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: <20120416230031.12409.qmail@joyce.lan> In-Reply-To: <20120416230031.12409.qmail@joyce.lan> 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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 23:32:29 -0000 Its unfortunate that a key point continues to be overlooked about SenderID. SIDF was proposed to basically cover certain use cases that SPF v1.0 did not cover. It was limited to possible use cases that fit within ~20% possible spectrum because it was measured early on ~80% of the transaction, the domains matched: 5322.PRA == 5321.MAILFROM and is why the 5321.SUBMITTER was proposed to optionally expose the PRA at 5321 as an optimization to avoid the payload and the accept/bounce potential. Its is basically the similar issue as it was with DKIM where, in general, the 5321.MAILFROM only differs with list mail distributions. You can measure at least one sum part of possible SENDERID client spectrum by seeing if they also support 4405 (SUBMITTER) and this is a high volume of transactions once your SMTP server enabled the SUBMITTER extension. Usage measurement is wrong. Its there, no doubt. If the SPFBIS is going recommend to end the SIDF protocol, IMV, the WG's prudent engineering job should include the consideration whether there will be new harm with the lost of PRA/SUBMITTER value in certain use cases where the PRA/SUBMITTER domains are different then 5321.MAILFROM. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com John Levine wrote: > In article <6.2.5.6.2.20120416135317.09f53ed0@resistor.net> you write: >> At 12:21 16-04-2012, Stuart D Gathman wrote: >>> While Sender-ID hasn't gotten much use, my personal opinion is that >>> it could get more use if the technical conflict with SPF >>> (interpreting v=spf1 records as spf2.0/mfrom,pra) was formally >>> fixed. > > That would be something other than Sender-ID. Nobody really knows why > Sender-ID didn't catch on, whether it was technical issues, > uncertainly about the patent license, general hostility to Microsoft, > or that people already had SPF and it was good enough. (In the > absence of any data, I tend toward the last of those.) Anyone who was > interested in Sender-ID has had the better part of a decade to invent > new versions, nobody has, and doing so now most definitely is not our > job. > > To wrap up the experiment, we just need to write up a document that > says SPF has been widely adopted, Sender-ID hasn't, provide the > evidence, and leave it at that. > > R's, > John > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From sm@elandsys.com Mon Apr 16 16:58: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 B347E11E80EB for ; Mon, 16 Apr 2012 16:58:56 -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.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkazvhM0fuvJ for ; Mon, 16 Apr 2012 16:58:54 -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 6197C11E807F for ; Mon, 16 Apr 2012 16:58:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.220]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3GNwdEq011494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 16:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334620731; i=@elandsys.com; bh=r6FTbyAQLezr3WYpQycrjGWG2npTXN0giaJfdNlBL7E=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=362ZfvPr0ZD7S9JTFaRlLCG08ZB1eBG6THGFbOtIP9Q4r81kCHekyLc+BGAQFmtB3 vQbP+pLHUbAbHX3qn/S//qdws7usv0ndlQjxHU7FTm4K2M/kBE7zEQFr1Cyk8zRLfD cMs338+ZswjOWvSFajIB8mt8aC9CAD+FLwgi8JYQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334620731; i=@elandsys.com; bh=r6FTbyAQLezr3WYpQycrjGWG2npTXN0giaJfdNlBL7E=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=cRiNH+7FaHTueEcTwOP7jSRm3ECJEJ1KnGb3RKUWfO/LR4kqSWz+8wO3v08qj+JSb A7W1kBj9eBhDeFPIeIcrRjcnOP6MI9yAun7m5Bn/hlad6Ewz2IKUqmgeJ0jEGuJ4Qn /H/DP/lzZQUxGPXhLgymOcB7DKaQPnVAH4BnzCVo= Message-Id: <6.2.5.6.2.20120416163851.0a95fb90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Apr 2012 16:56:17 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F8CABE8.10007@isdg.net> References: <20120416230031.12409.qmail@joyce.lan> <4F8CABE8.10007@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 23:58:56 -0000 At 16:31 16-04-2012, Hector Santos wrote: >Usage measurement is wrong. Its there, no doubt. If the SPFBIS is >going recommend to end the SIDF protocol, IMV, the WG's prudent >engineering job should include the consideration whether there will >be new harm with the lost of PRA/SUBMITTER value in certain use >cases where the PRA/SUBMITTER domains are different then 5321.MAILFROM. I gather that the above is a suggested alternative. That's covered by the "send text" mentioned by my co-chair at http://www.ietf.org/mail-archive/web/spfbis/current/msg01182.html Regards, S. Moonesamy SPFBIS WG co-chair From internet-drafts@ietf.org Mon Apr 16 21:11: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 C665811E8081; Mon, 16 Apr 2012 21:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+hqQcpg7S2N; Mon, 16 Apr 2012 21:11:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694CE11E809F; Mon, 16 Apr 2012 21:11:38 -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.00 Message-ID: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2012 21:11:38 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 04:11:42 -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 : Resolution of The SPF/Sender-ID Experiment Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-03.txt Pages : 10 Date : 2012-04-16 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender-ID, two proposed email authentication protocols. Because of interoperability concerns created by simultaneous use of the two protocols by a receiver, and some concerns with Sender-ID and compatibility with existing standards, the IESG required them to have Experimental status and invited the community to observe their deployments for a period of time, hoping convergence would be possible later. After six years, sufficient experience and evidence have been collected that the experiment thus created can be considered concluded, and a single protocol can be advanced. This memo presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-03.txt From msk@cloudmark.com Mon Apr 16 21:36: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 76A3B11E80A5 for ; Mon, 16 Apr 2012 21:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.672 X-Spam-Level: X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7m7qWuYaQwN for ; Mon, 16 Apr 2012 21:36:35 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 00E2111E80A2 for ; Mon, 16 Apr 2012 21:36:34 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id ysca1i0010ZaKgw01scacP; Mon, 16 Apr 2012 21:36:34 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=bsfO9Tmi c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=DT6a4BtRxdAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=X-lYJVElW5okdQY7UtUA:9 a=gtGr0H4IgxCvet4IPqYA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 21:36:34 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt Thread-Index: AQHNHFAzU6UbIC23j0+O47qTsnarm5aeZ/sw Date: Tue, 17 Apr 2012 04:36:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F448B@exch-mbx901.corp.cloudmark.com> References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> In-Reply-To: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334637394; bh=AzE6SoBqy6EGE3mmLwBLg/cYSZ2wfuKxJlMkYyhA8OA=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Vt88oHueNxdO9X7BDvOGQ8rO78pt9Ju9fw8VUHP3zxpWSRPOsSSgIfRxkH3gdoQ1n mQHbeF8HbzZZgi10GW6elBwBvXI3eODZcwmzgetKWj/Lb1WF4V8enUkJv5XOk0+3r5 3QZulR78fz1kF0SYa2OooJtXXEmVXBahS3/HD7eE= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 04:36:39 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Monday, April 16, 2012 9:12 PM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt >=20 >=20 > 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. >=20 > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-03.txt > Pages : 10 > Date : 2012-04-16 >=20 > [...] Includes the following changes: - remove old Section 2 - add text to remind readers that this document doesn't do a thorough techn= ical comparison of the two protocols; the community at large has already do= ne that, and I don't believe we either need to or could be expected to trac= k down consensus on that point beyond the evidence in hand - expand "MUA" on first use - mention DNS provisioning tools as a concern that may have hindered type 9= 9 adoption - some other tweaks John Levine suggested - update acknowledgements I'm told there are a couple of complete reviews outstanding, so there will = be an -04 before we go about requesting WGLC. In -04 I will also update th= e numbers from the two surveys I'm running, namely the DNS survey and the S= UBMITTER survey, but I don't expect that the updated results will change an= ything. -MSK From sm@elandsys.com Tue Apr 17 03:03: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 8AF6F21F8464 for ; Tue, 17 Apr 2012 03:03:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWDgRemxmJBV for ; Tue, 17 Apr 2012 03:03: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 3CB2F21F85CF for ; Tue, 17 Apr 2012 03:03:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3HA3GVX010067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 03:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334657008; i=@elandsys.com; bh=GN96y5VKDJ4PRyEh1zaw4Y17vIMEBTFTqBrUCbh0II4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=wfT2eAtHgAoLcev7w1VdAE+OlsXVV987VvLyVa2z95vBFDbWqmf8jIoDtelc14uM9 Oq+P14dJ6q/56bcaI6xYNivb2O43ZtJjuTxzsm4nCWRP53jYDQXnSyMi4VcEpTPsbg lOfP2BcmkVLrZtHmBRUn5T3+EZOq6OaM6x7nVh8M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334657008; i=@elandsys.com; bh=GN96y5VKDJ4PRyEh1zaw4Y17vIMEBTFTqBrUCbh0II4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=MvHaWobK9NWih7CJ6JpfhTq8+GYsiiq3i2OkuyaOEK+YFo50vwmYDgy+An2RZM8Rh DdF2RaJSBZtlmXJL1w7Elra7YtMNbM/EofVI3BEolnmS8HmFROD0Ut50uaLA2mSuwf ix7UC7G5QhlhM3UdRPgEmG0Qqne0gY4B4ynzWxdA= Message-Id: <6.2.5.6.2.20120417002539.0af11520@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Apr 2012 02:29:01 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F8561D8.4030208@isdg.net> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 10:03:40 -0000 At 03:50 11-04-2012, Hector Santos wrote: >2) What does "de facto obsolete" mean? From an IETF perspective, I read it as: RFC 4405, 4406 and 4407 are viewed as obsolete in practice. draft-ietf-spfbis-experiment-03, as it stands, is not a formal action to change the status of those three RFCs. If this WG was requesting such an action, it would have added an "Obsoletes:" tag at the top of Page 1 of the draft-ietf-spfbis-experiment-03. RFC 2821 is supported by Microsoft Exchange Server 2010. That RFC was obsoleted by RFC 5321 in October 2008. According to the current Exim documentation, Exim implements RFC 2554. That RFC was obsoleted by RFC 4954 in July 2007. The current Postfix documentation refers to RFC 2821. If I have to send an email to hotmail.com, my mail server must adhere to RFC 2821 and RFC 2822. RFC 2822 was obsoleted by RFC 5322 in October 2008. Regards, S. Moonesamy From vesely@tana.it Tue Apr 17 06:25: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 D77AF21F862F for ; Tue, 17 Apr 2012 06:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq8lGB74HO7c for ; Tue, 17 Apr 2012 06:24:59 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8DABE21F85AA for ; Tue, 17 Apr 2012 06:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334669098; bh=YGuUnDdqyiJ0hecECR3pRlhqfbBeJTQ6/J1tkQizrCo=; l=1067; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Z9oSZj5k8KEtOBXcJOdgbsvpTyELIkZ3wAU+QmURUUT+rFL0ogIQy98234oDl0Sdf vaTUt6h4M2L03i8v6jKMwrYcKXu6y13zXiLOkSYahF0G820OWDqn9ymvYQT65oZoRG fmREpBHWCqP4AWb+yR91RDAPKy68xoM9TEqKOakM= Received: from [192.168.8.53] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Apr 2012 15:24:57 +0200 id 00000000005DC033.000000004F8D6F2A.00000E28 Message-ID: <4F8D6F25.9010203@tana.it> Date: Tue, 17 Apr 2012 15:24:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> In-Reply-To: <6.2.5.6.2.20120417002539.0af11520@resistor.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:25:04 -0000 On Tue 17/Apr/2012 15:08:03 +0200 S Moonesamy wrote: > At 03:50 11-04-2012, Hector Santos wrote: >> 2) What does "de facto obsolete" mean? > > From an IETF perspective, I read it as: RFC 4405, 4406 and 4407 are viewed as > obsolete in practice. draft-ietf-spfbis-experiment-03, as it stands, is not > a formal action to change the status of those three RFCs. If this WG was > requesting such an action, it would have added an "Obsoletes:" tag at the top > of Page 1 of the draft-ietf-spfbis-experiment-03. Right. Then, I'd support removing Sender-ID stuff from that paragraph. Indeed, we don't /need/ to recommend to the IESG that "the [SUBMITTER] extension, [SENDER-ID], and [PRA], indicates that they are de facto obsolete." I'd rather reformulate point 3 to stress the DNS question, possibly summarizing the recommendations that emerged from the relevant ietf list thread ("provisioning software, was DNS RRTYPEs, the difficulty with"), and making it clear that accusations of spurious DNS usage are moot until they won't have been addressed. From vesely@tana.it Tue Apr 17 06:30: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 ED35321F8613 for ; Tue, 17 Apr 2012 06:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+rEHsfq3p1t for ; Tue, 17 Apr 2012 06:30:36 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A0EAA21F861C for ; Tue, 17 Apr 2012 06:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334669435; bh=ocql/fMVuymBHI8ExBkEyauA0Zcr6+uD1ZeO6LBCUUI=; l=790; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BVgWSORGqfPg9Z1BVmsGQ38ccGilIEsl5L39v9qmCLdoMSdXBSLGBsyhdnt3Gr+Oc QdCK2/x4R05s19v5owf5sGvgTDhE7yUSieXJo1O+hEW4fr8l4VFS96L/HBy25SxehW uexmn2HhJ20pgLiCckUxcBumh4fZsHoOBxYhI24M= Received: from [192.168.8.53] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Apr 2012 15:30:35 +0200 id 00000000005DC033.000000004F8D707B.00000F78 Message-ID: <4F8D7077.7040904@tana.it> Date: Tue, 17 Apr 2012 15:30:31 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> <4F8CA8FE.4010201@mail-abuse.org> In-Reply-To: <4F8CA8FE.4010201@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:30:41 -0000 On Tue 17/Apr/2012 15:26:05 +0200 Douglas Otis wrote: > On 4/14/12 7:45 AM, Alessandro Vesely wrote: > >> Actually, it seems to me that those who reject can be accused of >> breaking those SMTP features. To resolve the conflict we must devise >> a safe way of rejecting, such that servers can adhere to it with no >> risks. Our task is not to mandate it, but to enable it. > > Agreed. For example, this could be done using something as simple as > incorporating the scope-ID used in RFC4406 to clarify applicable SMTP > parameters with a list of EHLO / MFROM. When the scope contains just EHLO, > only then will SPF verification offer a means to "authenticate" a source. We cannot do that for this SPF version. However, we could require that a helo-pass prevents rejection. From spf2@kitterman.com Tue Apr 17 06:56: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 14F9521F8562 for ; Tue, 17 Apr 2012 06:56: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PuUocDpo3LZ for ; Tue, 17 Apr 2012 06:56:12 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F121F85C0 for ; Tue, 17 Apr 2012 06:56:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CC92120E40CC; Tue, 17 Apr 2012 09:56:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334670971; bh=gJCJHWW1f/OJRXN+Ws6ZjkOP7ylM+PfpbHTjTn3Y/Rg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TwM+OlOLenkaxhrVmcRldTAnxfm0UOUNp5zBHmM3k0luUdQAcmGxac8rPzBcYOhDz WO8126TFwCHJ9EUB53arkT0lIEYv+HgPCT1OXWbIH0lDxlSOPiFnuZvgEj1lhiuNl/ w1MQymn8L8OKzrh/SU9j2n2all99t0+UKSFU2xj4= Received: from scott-latitude-e6320.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 ESMTPSA id C013E20E4064; Tue, 17 Apr 2012 09:56:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Apr 2012 09:56:11 -0400 Message-ID: <2311908.lptl6ivU91@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8D7077.7040904@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <4F8CA8FE.4010201@mail-abuse.org> <4F8D7077.7040904@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] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:56:17 -0000 On Tuesday, April 17, 2012 03:30:31 PM Alessandro Vesely wrote: > On Tue 17/Apr/2012 15:26:05 +0200 Douglas Otis wrote: > > On 4/14/12 7:45 AM, Alessandro Vesely wrote: > >> Actually, it seems to me that those who reject can be accused of > >> breaking those SMTP features. To resolve the conflict we must devise > >> a safe way of rejecting, such that servers can adhere to it with no > >> risks. Our task is not to mandate it, but to enable it. > > > > Agreed. For example, this could be done using something as simple as > > incorporating the scope-ID used in RFC4406 to clarify applicable SMTP > > parameters with a list of EHLO / MFROM. When the scope contains just > > EHLO, > > only then will SPF verification offer a means to "authenticate" a source. > > We cannot do that for this SPF version. However, we could require that a > helo-pass prevents rejection. No. We could not. Scott K From vesely@tana.it Tue Apr 17 07:16: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 ECD1B11E8094 for ; Tue, 17 Apr 2012 07:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXAW9L09xqAG for ; Tue, 17 Apr 2012 07:16:04 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE6411E8080 for ; Tue, 17 Apr 2012 07:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334672163; bh=cdjLvzU8WmmWTyHTFCLHf5xJJ2NKCOf9TRZNl7p/Ws0=; l=814; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Rqvtp/2VeOYKQlKpXsIUzkzjAIapWnrzls9Fn0RxkjUek7edEgdKU3qeehcpKH9en 8xWyy3PQxugwGpa3tyIuTa/81JBxquIj8hlySVWnUwqmY2p4WF+qQ1b3CNiPKON2FA wDXDKF5E5uIhqcEjJDl8N2Xs0I5dINz+7Try4z0c= Received: from [192.168.8.53] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Apr 2012 16:16:00 +0200 id 00000000005DC042.000000004F8D7B21.00001AC7 Message-ID: <4F8D7B0D.4070609@tana.it> Date: Tue, 17 Apr 2012 16:15:41 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039280EFF59@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F17E8@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F401A@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F401A@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:16:09 -0000 On Tue 17/Apr/2012 15:48:25 +0200 Murray S. Kucherawy wrote: >> From: Dotzero > >> Section 3.1 - For the 6,887 records that start with "spf2.0/", it would >> have been useful to further break this down into how many specify MFROM >> and how many specify PRA. > > The breakdown from my data is: > > 6329 spf2.0/pra > 213 spf2.0/pra,mfrom > 211 spf2.0/mfrom (which is just SPF) It is not just SPF. To only validate MFROM one should set 2 records: v=spf1 [mechanisms omitted] -all and spf2.0/pra ?all > 134 spf2.0/mfrom,pra > > Is it worth including this breakdown in -03? Almost 97% of spf2.0/* > records requested PRA handling. That seems to be consistent with the recommended settings of Microsoft's wizard, see http://www.ietf.org/mail-archive/web/spfbis/current/msg00343.html From ajs@anvilwalrusden.com Tue Apr 17 07:26: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 85F2C21F8526 for ; Tue, 17 Apr 2012 07:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.768 X-Spam-Level: X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lVdi2-NCfFn for ; Tue, 17 Apr 2012 07:26:30 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BA60321F84EE for ; Tue, 17 Apr 2012 07:26:30 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id AD5C71ECB41D for ; Tue, 17 Apr 2012 14:26:29 +0000 (UTC) Date: Tue, 17 Apr 2012 10:26:27 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120417142622.GE53275@mail.yitter.info> References: <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> <4F8CA8FE.4010201@mail-abuse.org> <4F8D7077.7040904@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8D7077.7040904@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:26:31 -0000 Dear colleagues, No hat. On Tue, Apr 17, 2012 at 03:30:31PM +0200, Alessandro Vesely wrote: > On Tue 17/Apr/2012 15:26:05 +0200 Douglas Otis wrote: > > Agreed. For example, this could be done using something as simple as > > incorporating the scope-ID used in RFC4406 to clarify applicable SMTP > > parameters with a list of EHLO / MFROM. > We cannot do that for this SPF version. However, we could require that a > helo-pass prevents rejection. There are many things we could do to SPF. I advise everyone considering what they'd like SPF to look like to read the charter carefully, however, because anything that isn't actually already deployed _today_ or else a straightforward clarification is, in my reading, not part of the scope of our work. The above two examples are picked more or less at random, and not with the intention of picking on Doug or Alessandro. I'm just urging that, if you have things you want of SPF, you consider very carefully when you plan those changes for consideration. In many cases, it might be wise to build up a list of desiderata for a subsequent effort. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Tue Apr 17 07: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 5BA6021F84F1 for ; Tue, 17 Apr 2012 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccvvNsxt-quL for ; Tue, 17 Apr 2012 07:37:40 -0700 (PDT) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by ietfa.amsl.com (Postfix) with ESMTP id 36CA221F84A6 for ; Tue, 17 Apr 2012 07:37:40 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id q3HEbaXJ024522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 07:37:39 -0700 Message-ID: <4F8D802F.1020101@dcrocker.net> Date: Tue, 17 Apr 2012 07:37:35 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120324090349.15462.qmail@joyce.lan> <4F8CA8FE.4010201@mail-abuse.org> <4F8D7077.7040904@tana.it> <2311908.lptl6ivU91@scott-latitude-e6320> In-Reply-To: <2311908.lptl6ivU91@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 (sbh11.songbird.com [72.52.113.11]); Tue, 17 Apr 2012 07:37:39 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] #12 again, was Meaning... 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, 17 Apr 2012 14:37:44 -0000 On 4/17/2012 6:56 AM, Scott Kitterman wrote: >>> Agreed. For example, this could be done using something as simple as >>> > > incorporating the scope-ID used in RFC4406 to clarify applicable SMTP >>> > > parameters with a list of EHLO / MFROM. When the scope contains just >>> > > EHLO, >>> > > only then will SPF verification offer a means to "authenticate" a source. >> > >> > We cannot do that for this SPF version. However, we could require that a >> > helo-pass prevents rejection. > No. We could not. It might be worth our being clear about the reason we could not. I believe the proposed "helo-pass prevents rejection" would qualify as adding new functionality to spf and that there is not already wide deployment of it. As such, it falls outside of the charter. Does that match the reason(s) other folk see? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dotzero@gmail.com Tue Apr 17 07:44: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 B652621F852A for ; Tue, 17 Apr 2012 07:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3PkznP3QGkL for ; Tue, 17 Apr 2012 07:44:47 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id D556921F8528 for ; Tue, 17 Apr 2012 07:44:47 -0700 (PDT) Received: by dady13 with SMTP id y13so11724157dad.27 for ; Tue, 17 Apr 2012 07:44:47 -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=VtLs+9WxkR/p8zl3ZrGCSannuCYgeOkKEn2zwvoXRgE=; b=ZqVuA7/X/fGE5uVr6xOZabyI/j2Ud7m/CFuSRZOguLqjKGm9VM9YJcwUDGo8gm9xd5 AfW8gYla0YJrh8H+bwZVWUmC5mfENdaNLO5uUiB88dltIf0KHRoY7BDWx0is4lvTBZm4 Uv+XfDLIkTNijQBkYdeHValGAaJpJ7WmLITROuzsC1IJP/c5FpGlrfkR660n9t0+bRQg vy71gahEVIlQTI3DTdYziyl2BDg4lofFxhl/gG/c5upRJqUjv6ptemZPWaF6n0ODdEu+ l8ixQRtirLMwvtPhwAenrctgR4YzjTUAPeRMd682/712t4R6H3Ir10kbj+dpQwWuQ15V JBFA== MIME-Version: 1.0 Received: by 10.68.223.67 with SMTP id qs3mr37041565pbc.142.1334673887657; Tue, 17 Apr 2012 07:44:47 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Tue, 17 Apr 2012 07:44:47 -0700 (PDT) In-Reply-To: <4F8D802F.1020101@dcrocker.net> References: <20120324090349.15462.qmail@joyce.lan> <4F8CA8FE.4010201@mail-abuse.org> <4F8D7077.7040904@tana.it> <2311908.lptl6ivU91@scott-latitude-e6320> <4F8D802F.1020101@dcrocker.net> Date: Tue, 17 Apr 2012 10:44:47 -0400 Message-ID: From: Dotzero To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:44:48 -0000 On Tue, Apr 17, 2012 at 10:37 AM, Dave Crocker wrote: > > > On 4/17/2012 6:56 AM, Scott Kitterman wrote: >>>> >>>> Agreed. =A0For example, this could be done using something as simple a= s >>>> > > incorporating the scope-ID used in RFC4406 to clarify applicable >>>> > > SMTP >>>> > > parameters with a list of EHLO / MFROM. =A0When the scope contains >>>> > > just >>>> > > EHLO, >>>> > > only then will SPF verification offer a means to "authenticate" a >>>> > > source. >>> >>> > >>> > We cannot do that for this SPF version. =A0However, we could require = that >>> > a >>> > helo-pass prevents rejection. >> >> No. =A0We could not. > > > > It might be worth our being clear about the reason we could not. > > I believe the proposed "helo-pass prevents rejection" would qualify as > adding > new functionality to spf and that there is not already wide deployment of > it. > As such, it falls outside of the charter. > > Does that match the reason(s) other folk see? > > d/ > -- > +1 From spf2@kitterman.com Tue Apr 17 08:13: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 9FF7511E80C9 for ; Tue, 17 Apr 2012 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFw0aFqwmtxh for ; Tue, 17 Apr 2012 08:13:02 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 630AC21F856D for ; Tue, 17 Apr 2012 08:13:02 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8054F20E40CC; Tue, 17 Apr 2012 11:13:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334675581; bh=vqRfQtnyWad/frrojsNmQYh6MnvlLiRlxURDOWtbyZg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ds5j4xSM/sRimt99E36l0QFWkRcmKRdGBZ9b53bi9e+qB28UuXqN6GysAQAvYqrJR jyI3LOhDxNO7+IJs8RYjDaoydnSG8QgE2MYEM0TLTCqpbkDatUzefhpw2tAPQBVGak OIjzQ37u8r/3XEqFSskACXFi37KEvtpMrOErCcxA= Received: from scott-latitude-e6320.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 ESMTPSA id 74CF720E4064; Tue, 17 Apr 2012 11:13:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Apr 2012 11:13:01 -0400 Message-ID: <1357789.Kafn83GcaR@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8D802F.1020101@dcrocker.net> References: <20120324090349.15462.qmail@joyce.lan> <2311908.lptl6ivU91@scott-latitude-e6320> <4F8D802F.1020101@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] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:13:06 -0000 On Tuesday, April 17, 2012 07:37:35 AM Dave Crocker wrote: > On 4/17/2012 6:56 AM, Scott Kitterman wrote: > >>> Agreed. For example, this could be done using something as simple as > >>> > >>> > > incorporating the scope-ID used in RFC4406 to clarify applicable > >>> > > SMTP > >>> > > parameters with a list of EHLO / MFROM. When the scope contains > >>> > > just > >>> > > EHLO, > >>> > > only then will SPF verification offer a means to "authenticate" a > >>> > > source. > >> > > >> > We cannot do that for this SPF version. However, we could require that > >> > a > >> > helo-pass prevents rejection. > > > > No. We could not. > > It might be worth our being clear about the reason we could not. > > I believe the proposed "helo-pass prevents rejection" would qualify as > adding new functionality to spf and that there is not already wide > deployment of it. As such, it falls outside of the charter. > > Does that match the reason(s) other folk see? There is a mention of this in RFC 4408 paragraph 9.3.3.2 as something one may do. It does not how every describe the conditions under which doing so is appropriate. I agree that absent evidence of wide spread deployment, promoting a may to a MUST is out of scope. Even if it were in scope, it would still be a bad idea since it only works if the identity in HELO is trusted in some manner. Adding Sender-ID scopes to SPF is clearly outside the charter. Scott K From johnl@iecc.com Tue Apr 17 08:27: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 7817911E80AF for ; Tue, 17 Apr 2012 08:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.948 X-Spam-Level: X-Spam-Status: No, score=-108.948 tagged_above=-999 required=5 tests=[AWL=-2.049, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu8VnmMEherU for ; Tue, 17 Apr 2012 08:26:58 -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 DC1F811E8080 for ; Tue, 17 Apr 2012 08:26:57 -0700 (PDT) Received: (qmail 9104 invoked from network); 17 Apr 2012 15:26:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Apr 2012 15:26:55 -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=4f8d8bbe.xn--9vv.k1204; i=johnl@user.iecc.com; bh=RM6Njh+rKolsKJdhLeflZWihAbIIuy6P2lNSsIfIIwc=; b=KVocVTWRWYziwrRbO3c+s1x3/MlJUvqu/XqXNNo76UbIFCoaicDTadXIVINVgubDSCEiNllAl+oQrEagndlHRyO1+UNxR0Mq9RWeOEAFj9AmzpgXUaSaFtp4wMLlG9KD4nz69VOPDD3+6QW6SEtxTd/14r9+dfNdGVwm1yaBPG0= 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=4f8d8bbe.xn--9vv.k1204; olt=johnl@user.iecc.com; bh=RM6Njh+rKolsKJdhLeflZWihAbIIuy6P2lNSsIfIIwc=; b=oDQWb/QWEdP3ELgDdM30NHpLMMtcK4tkBsFDmoeVM6YSlOhdm/dNxX07RdttwjNx4O4VUnSO58pfZgEoOS4cVDWvJiIvbsFll5woiE5EDp3UIIIwQhsqxbtDsHE4lAVXVg4CxSGagtrV93AXDmAhy7oFdw6OF1/H5v5cskYLDWI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Apr 2012 15:26:32 -0000 Message-ID: <20120417152632.13020.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F8D802F.1020101@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:27:03 -0000 >I believe the proposed "helo-pass prevents rejection" would qualify as adding >new functionality to spf and that there is not already wide deployment of it. >As such, it falls outside of the charter. > >Does that match the reason(s) other folk see? Yes. This is a cleanup pass, to make the documentation match what SPF actually does. R's, John From R.E.Sonneveld@sonnection.nl Tue Apr 17 08:39: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 926A711E8080 for ; Tue, 17 Apr 2012 08:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI1XPP6oF8YK for ; Tue, 17 Apr 2012 08:39:49 -0700 (PDT) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id 553BA11E80AF for ; Tue, 17 Apr 2012 08:39:49 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M2M00400R4OW400@hydrogen.mailtransaction.com>; Tue, 17 Apr 2012 17:39:47 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M2M00ILERIA9A00@hydrogen.mailtransaction.com>; Tue, 17 Apr 2012 17:39:47 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M2M00G3ZRI92700@lion.sonnection.nl> for spfbis@ietf.org; Tue, 17 Apr 2012 17:39:46 +0200 (CEST) Message-id: <4F8D9072.2020208@sonnection.nl> Date: Tue, 17 Apr 2012 17:46:58 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: dcrocker@bbiw.net References: <20120417152632.13020.qmail@joyce.lan> In-reply-to: <20120417152632.13020.qmail@joyce.lan> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1334677187; bh=Ij8paQPLqcv2Z26pfkvN+2AZo7r4Utwb2OaudpaNbuw=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=QOt0+jUaFp0DEHmtypOQ00phVN25Ow6m8JlKdIDgrRt43ineEiBLyJwKFEuvJfXf+ A2y7IBpJESQSlLO96AZgCmx4Fzgh6K4KTc6dee65C7OkXXpIaIvrQFYnFmKXpBKXKu 1CaDqeSoTXrDjC/d/K30mderQJhT9ZNGusV6MXgk= X-DKIM: OpenDKIM Filter v2.4.3 hydrogen.mailtransaction.com 0M2M00400R4OW400 Cc: spfbis@ietf.org, John Levine Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:39:53 -0000 On 4/17/12 5:26 PM, John Levine wrote: >> I believe the proposed "helo-pass prevents rejection" would qualify as adding >> new functionality to spf and that there is not already wide deployment of it. >> As such, it falls outside of the charter. >> >> Does that match the reason(s) other folk see? > Yes. This is a cleanup pass, to make the documentation match what > SPF actually does. +1 /rolf From vesely@tana.it Tue Apr 17 08:59: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 A3C7721F8566 for ; Tue, 17 Apr 2012 08:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlZUN0MxP0nZ for ; Tue, 17 Apr 2012 08:59:12 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C35DF21F856D for ; Tue, 17 Apr 2012 08:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334678342; bh=aosHxN/KCPCtWp/0sHkjHNC6Q5UbBRluw38sdVbv2E8=; l=1754; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cBfIpwcUMNAwcB1iHeBobDJ49pvVvzG18Izk48QwoX6HzUvypGw99i9dqRnfGMzzm wLpXMaXOjKMXoe2tJNFk8tnPY5AA0PT87joNISV9GxyjL8GStc/QpcqnX2ZKAWTHo/ kq8dC2JMKDrwcbPPyfradfPpX9BKZlOHTeEzj0+4= Received: from [192.168.8.53] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Apr 2012 17:59:00 +0200 id 00000000005DC035.000000004F8D9344.000033E0 Message-ID: <4F8D9335.2090204@tana.it> Date: Tue, 17 Apr 2012 17:58:45 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <2311908.lptl6ivU91@scott-latitude-e6320> <4F8D802F.1020101@dcrocker.net> <1357789.Kafn83GcaR@scott-latitude-e6320> In-Reply-To: <1357789.Kafn83GcaR@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:59:16 -0000 On Tue 17/Apr/2012 17:19:47 +0200 Scott Kitterman wrote: > On Tuesday, April 17, 2012 07:37:35 AM Dave Crocker wrote: >> On 4/17/2012 6:56 AM, Scott Kitterman wrote: >>>>> >>>>> we could require that a helo-pass prevents rejection. >>> >>> No. We could not. >> >> It might be worth our being clear about the reason we could not. >> >> I believe the proposed "helo-pass prevents rejection" would qualify as >> adding new functionality to spf and that there is not already wide >> deployment of it. As such, it falls outside of the charter. >> >> Does that match the reason(s) other folk see? > > There is a mention of this in RFC 4408 paragraph 9.3.3.2 as something one may > do. It does not how every describe the conditions under which doing so is > appropriate. Those conditions are introduced at the very beginning of section 9, namely to ameliorate the fact that SPF is not compatible with SMTP. It is not a new functionality, anyway. > I agree that absent evidence of wide spread deployment, promoting a may to > a MUST is out of scope. Section 9 is explicitly declared non-normative, so may-vs-must arguments have little sense. I claim this proposal is in scope because it is the correction of an error, as it is obviously an error for a mail protocol to be incompatible with SMTP. > Even if it were in scope, it would still be a bad idea since it only works > if the identity in HELO is trusted in some manner. I'm not following you. The correction doesn't imply whitelisting a specific helo identity (that's mentioned in 9.3.3.1). It relies on an SPF "pass" result for the helo identity, with no trust implications whatsoever. > Adding Sender-ID scopes to SPF is clearly outside the charter. Yes. From hsantos@isdg.net Tue Apr 17 08: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 1A02A21F8570 for ; Tue, 17 Apr 2012 08:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 942JJ2cGOAF8 for ; Tue, 17 Apr 2012 08:59:20 -0700 (PDT) Received: from mail.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BAF1321F8566 for ; Tue, 17 Apr 2012 08:59:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1746; t=1334678353; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9QCtNdsNoQkTv0cjVDwpIdUnEDI=; b=qUs+8Y1IZR+J+LSsNaFU nh8rXoHJfQ9HuPegU0n/siwpfXnXvFJet2Dp5rX6LWSt8tNNnWLMSNX3yHMfzzIP ec0yMTj2IjrDkGSHeTCEqUBmFy0n31xgShXwjheth7ER9PsOCAymEddtH7GYZzxH F831P70f77HhAJO9l6fv7z0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 11:59:13 -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 v6.4.454.1) with ESMTP id 3585177339.29191.4848; Tue, 17 Apr 2012 11:59:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1746; t=1334678023; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RY2kPeJ +crzRARGuSGzmQVIx8c4xlmt5zNURpLfw9MI=; b=utEzc0stccnuAAvFujBUqP1 k5KjjPO6eG+8Xkut13VaeSyEbU1Gd0ZmL+4PChz4gdavE9p7XzW+qbx76UAbO0o8 9jZ4/lhSqE2fH+RU7+UX8h2uBpNrZiwvWjdV6AH0KYEe1uGIWQLmzqcZmMZsdd+V V9pp48uW8pSDbVC/v5d0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 11:53:43 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4184079565.1821.5844; Tue, 17 Apr 2012 11:53:43 -0400 Message-ID: <4F8D930E.7020509@isdg.net> Date: Tue, 17 Apr 2012 11:58:06 -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: <20120324090349.15462.qmail@joyce.lan> <4F8CA8FE.4010201@mail-abuse.org> <4F8D7077.7040904@tana.it> <2311908.lptl6ivU91@scott-latitude-e6320> <4F8D802F.1020101@dcrocker.net> In-Reply-To: <4F8D802F.1020101@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:59:25 -0000 Dave Crocker wrote: >>> Alessandro: >>> We cannot do that for this SPF version. However, we could require >>> that a helo-pass prevents rejection. >> Scott: >> No. We could not. > It might be worth our being clear about the reason we could not. > > I believe the proposed "helo-pass prevents rejection" would qualify as > adding new functionality to spf and that there is not > already wide deployment of it. As such, it falls outside of > the charter. > > Does that match the reason(s) other folk see? Not really, because its already in scope as a possible condition by implementations to consider the HELO SPF value. The reason issue is essential a matter of trust and confidence values for the MAIL FROM vs HELO results. The suggestion problem is that its can not be an a new functional requirement as you suggested, but one that would be in the form of an inherent HELO-PASS mandate for acceptance, essentially a White "Good Mail" filtering trump card over any other possible illogical condition or SPF failure. Overall, the suggestion implies a SPF provision such as: SPF MUST NOT provide a mechanism that impugns the existence of non-first party MTA router authentication with a SPF HELO-PASS. A corollary of this requirement is that the protocol MUST NOT link practices of first party MAIL FROM domains with the practices of third party MTA router policies. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the MTA router or local policy of the receiver. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Tue Apr 17 09:10: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 20C7211E80A3 for ; Tue, 17 Apr 2012 09:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g-giZoErqmg for ; Tue, 17 Apr 2012 09:09:58 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1DC11E80B3 for ; Tue, 17 Apr 2012 09:09:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id z49s1i0010ZaKgw014A4WD; Tue, 17 Apr 2012 09:10:04 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=NYRkJh/4 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=ZJWT_UiDdG8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=K_Vnq-C_CnQEbnx9iwMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=BtM-yTyH7nXQ_GNG:21 a=SUvNq-JOFtXKZxdX:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 09:09:37 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split Thread-Index: AQHNF9EOQgr+SihpH0GvvLd/7ViEI5afPsKAgABB5oD//7cB0A== Date: Tue, 17 Apr 2012 16:09:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> In-Reply-To: <4F8D6F25.9010203@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334679004; bh=+F9EDR0FrNOg49BIujHa1Tqjv5Uarj9ML4byaL4naw4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=x8VVhLWfa42IR7l6+ulSiX5HRJIDfm0I0mYUNw/R3D+X7bpOcEqQaOLJBIZixgQeC Qc3A1NX+JkUK2xbkFxrEL4ZrLH1WmLOMqIILgWw89K/anvSm2sJItIArCCF90MR0ma eYkZvGVJJC9n9ZZD7gqKK8hjCD3x3Fzu32w72vxI= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:10:02 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Tuesday, April 17, 2012 6:25 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 = Item 3 recommendation to split >=20 > > From an IETF perspective, I read it as: RFC 4405, 4406 and 4407 are > > viewed as obsolete in practice. draft-ietf-spfbis-experiment-03, as > > it stands, is not a formal action to change the status of those three > > RFCs. If this WG was requesting such an action, it would have added > > an "Obsoletes:" tag at the top of Page 1 of the draft-ietf-spfbis- > > experiment-03. >=20 > Right. Then, I'd support removing Sender-ID stuff from that paragraph. > Indeed, we don't /need/ to recommend to the IESG that "the [SUBMITTER] > extension, [SENDER-ID], and [PRA], indicates that they are de facto > obsolete." >=20 > I'd rather reformulate point 3 to stress the DNS question, possibly > summarizing the recommendations that emerged from the relevant ietf > list thread ("provisioning software, was DNS RRTYPEs, the difficulty > with"), and making it clear that accusations of spurious DNS usage are > moot until they won't have been addressed. I don't agree. What we're trying to resolve here is which of the two proto= cols the community wants to advance to the standards track, leaving one beh= ind, thus concluding the experiment. If we omit that, we haven't actually = met our first deliverable. The DNS RRtype question is a relevant part of the question, but not all of = it. The term "de facto obsolete" means, quite literally, "from the facts, obsol= ete". The dictionary defines "obsolete" as "no longer in general use; fall= en into disuse". So, based on the data collected and presented in the document, which nobody= has challenged yet in terms of either methods or content, the expression i= s quite appropriate. As SM also points out, this document doesn't change the status of the three= documents. That's for us to decide to do (or not) in the other document. -MSK From spf2@kitterman.com Tue Apr 17 09:16: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 A45E311E80B4 for ; Tue, 17 Apr 2012 09:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLKlJhrMkPay for ; Tue, 17 Apr 2012 09:16:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20711E8088 for ; Tue, 17 Apr 2012 09:16:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AC53A20E40CC; Tue, 17 Apr 2012 12:16:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334679360; bh=Mi4b7iE17Y6stchhC8s6ANda3lrW9fEDzfBASW2IujM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KueprGI9sR6Tk3Ec7GmwUFC8rQnZ1gIS90ijKq4q0BcGSOBGN1uq0BH7m8zCX36Bh UOzzW6mCtr4Lt8QmXglPGIQZSHmW54UEYab/bkDXaLcTvUK1xrziF+RTx1opqPXh4S XF6USJ/Oc+Mqzhga6bPoB/ONEf35LKHqzqDXIBrE= Received: from scott-latitude-e6320.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 ESMTPSA id 932D220E4064; Tue, 17 Apr 2012 12:16:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Apr 2012 12:15:59 -0400 Message-ID: <4213133.7QvcCDOQnQ@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8D9335.2090204@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <1357789.Kafn83GcaR@scott-latitude-e6320> <4F8D9335.2090204@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] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:16:05 -0000 On Tuesday, April 17, 2012 05:58:45 PM Alessandro Vesely wrote: > > Even if it were in scope, it would still be a bad idea since it only works > > if the identity in HELO is trusted in some manner. > > I'm not following you. The correction doesn't imply whitelisting a specific > helo identity (that's mentioned in 9.3.3.1). It relies on an SPF "pass" > result for the helo identity, with no trust implications whatsoever. This is similar to my objection to SUBMITTER overriding Mail From. Here's an example: EHLO: bad.example.net Mail From: good.example.com Based on the published SPF records for both and the connect IP address, in this example, the SPF check for bad.example.net passes and the check for good.example.com fails. If the EHLO result trumps the Mail From result, then malicious senders can trivially construct arbitrary hostnames and arrange for a HELO/EHLO pass result. This is, without external information, indistinguishable from: EHLO: relay.example.net Mail From: good.example.com This may be a transparent relay (AKA forwarder). In order to let a pass HELO/EHLO result trump a fail Mail From result, you have to know and trust the host in question, otherwise you've just made SPF pointless. This is NOT how SPF works today and changing it to work this way is completely out of scope. Scott K From msk@cloudmark.com Tue Apr 17 09:27: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 5F15A11E80A3 for ; Tue, 17 Apr 2012 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSKkLqiuyCwT for ; Tue, 17 Apr 2012 09:26:46 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC5321F84A1 for ; Tue, 17 Apr 2012 09:26:46 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id z4SQ1i0010ZaKgw014SQCA; Tue, 17 Apr 2012 09:26:24 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=W866pGqk c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=ZJWT_UiDdG8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=6KrMzQIDXzls9J-uGA4A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 09:26:24 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split Thread-Index: AQHNF9EOQgr+SihpH0GvvLd/7ViEI5afPsKAgABB5oD//7cB0IAABhQg Date: Tue, 17 Apr 2012 16:26:23 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334679984; bh=vOSMvdyGSzoSv5gwTb2OfP8ZX6unqVpeqwlDT1HKSU0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AqRZQTHxYAwB08F4UyN8m6rrsEzQytUR2swAS4SKRf5R8mr6TlNdAiba5CqQ4e09a VsP5xUHDiMSsPYx/Dv2QhpmXuUL0yn0t9Na0wPl634mVWQ/5NtTjZ2o8fxOgctdXwS T5xsHxZSxpMscDJRwDm9kRWYpsZ1b5BZoOrFjTBg= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:27:06 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Tuesday, April 17, 2012 9:10 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 = Item 3 recommendation to split >=20 > As SM also points out, this document doesn't change the status of the > three documents. That's for us to decide to do (or not) in the other > document. ...although if we want RFC4408bis itself to be completely SIDF-agnostic, pe= rhaps we should consider the status change actions for inclusion in this do= cument. Opinions? -MSK From vesely@tana.it Tue Apr 17 09:46: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 1B8F711E8074 for ; Tue, 17 Apr 2012 09:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loS9kcehVf2K for ; Tue, 17 Apr 2012 09:46:46 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B8A1D21F848A for ; Tue, 17 Apr 2012 09:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334681204; bh=XAXDIPjNyk2Xm0usO7iLnhPghzNKV0NCyhsLAtDHX+w=; l=1227; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=fddxbX4C754n1navvM4mi73BaGNjVWYTAOYshGu/dAaqCbKOgBxg0MIPuGjpvUXfO oWVTG6RYQahsG9pw2P9P/K6rf6GhYp9J+ehN4DTMDwhJ3YQTi5yI3f82nGqTrZAGmx xtNaz2kyd8raafkdxF5KAFtoQCAe9/A7/ezUSHbY= Received: from [192.168.8.53] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Apr 2012 18:46:39 +0200 id 00000000005DC039.000000004F8D9E70.00003F7E Message-ID: <4F8D9E69.1070706@tana.it> Date: Tue, 17 Apr 2012 18:46:33 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:46:50 -0000 On Tue 17/Apr/2012 18:35:28 +0200 Murray S. Kucherawy wrote: > > What we're trying to resolve here is which of the two protocols the > community wants to advance to the standards track, leaving one behind, > thus concluding the experiment. If we omit that, we haven't actually met > our first deliverable. That's not quite what the charter says, though. We cannot opt to advance Sender-ID instead. > The DNS RRtype question is a relevant part of the question, but not all of > it. I'd split that point in any case, because they are two unrelated questions. > The term "de facto obsolete" means, quite literally, "from the facts, > obsolete". The dictionary defines "obsolete" as "no longer in general > use; fallen into disuse". > > So, based on the data collected and presented in the document, which > nobody has challenged yet in terms of either methods or content, the > expression is quite appropriate. Yes, it is. The point is that we don't need to change the status of those documents, or recommend that the IESG does so, in order to advance SPF. If there were consensus on that, perhaps we could do it. But given that there doesn't seem to be consensus, it would seem easier to skip it. From dhc@dcrocker.net Tue Apr 17 09:50: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 9ED4821F8450 for ; Tue, 17 Apr 2012 09:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZVJqT8xz1Hs for ; Tue, 17 Apr 2012 09:50:02 -0700 (PDT) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by ietfa.amsl.com (Postfix) with ESMTP id 973CE21F8437 for ; Tue, 17 Apr 2012 09:50:01 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id q3HGnw1L030670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 09:50:01 -0700 Message-ID: <4F8D9F35.6070402@dcrocker.net> Date: Tue, 17 Apr 2012 09:49:57 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> <4F8CA8FE.4010201@mail-abuse.org> <4F8D7077.7040904@tana.it> <20120417142622.GE53275@mail.yitter.info> In-Reply-To: <20120417142622.GE53275@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh11.songbird.com [72.52.113.11]); Tue, 17 Apr 2012 09:50:01 -0700 (PDT) Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:50:02 -0000 On 4/17/2012 7:26 AM, Andrew Sullivan wrote: > anything that isn't actually already > deployed_today_ or else a straightforward clarification is, in my > reading, not part of the scope of our work. +1. But to emphasize that a mere existence proof is not sufficient, the qualifier "widely" also applies. The formal charter language is rather clear about 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. /already/ and /widespread/ For any suggestion to make /additions/ to the spfbis specification, I believe this means that the only reasonable response is: "Document where this is already in widespread use." d/ From spf2@kitterman.com Tue Apr 17 09:56: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 9F97711E8080 for ; Tue, 17 Apr 2012 09:56: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmcYYyHRoEYW for ; Tue, 17 Apr 2012 09:56:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6960E11E80BE for ; Tue, 17 Apr 2012 09:56:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E9E4520E40CC; Tue, 17 Apr 2012 12:56:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334681775; bh=+2oJbJd/IfYmI/RWSUZKeeZeSpnuOKOtvhmVP2vK1sU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=htOzT5Lhzl+45T546AYhJyD+CorxtFv/yzVfJvlsW8vknoJqg76herhhnDAHm0eXa B5bE+Bgv+gUofgV053PoQyXfc4mHX+WRJtqP1IqN+b9/FqdxkQwvVRCHuWfSL5RguT eqJnKDTKA6zhMydS1gjjI0ZU0AXNlPg/3t/Nrji0= Received: from scott-latitude-e6320.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 ESMTPSA id D05BE20E4043; Tue, 17 Apr 2012 12:56:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Apr 2012 12:56:14 -0400 Message-ID: <222449751.KD0kA2Z13W@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:56:19 -0000 On Tuesday, April 17, 2012 04:26:23 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Murray S. Kucherawy Sent: Tuesday, April 17, 2012 9:10 AM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 > > Item 3 recommendation to split > > > > As SM also points out, this document doesn't change the status of the > > three documents. That's for us to decide to do (or not) in the other > > document. > > ...although if we want RFC4408bis itself to be completely SIDF-agnostic, > perhaps we should consider the status change actions for inclusion in this > document. > > Opinions? I would strongly prefer that 4408bis not change the status of 4405 - 7. I don't believe it's necessary for this working group to change the status of those documents to do it's work. We are documenting the result of an experiment and developing 4408bis to move SPF from experimental to standards track. That's it. As a definition of the experimental protocol, I think 4405 - 7 are fine. They document it correctly. At some point it will be appropriate to mark them all historic. I don't think it is necessary for us to get distracted with a discussion about how dead they need to be to do that. Scott K From dotzero@gmail.com Tue Apr 17 09: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 16CAF21F8474 for ; Tue, 17 Apr 2012 09:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh14RFLrK3gr for ; Tue, 17 Apr 2012 09:59:24 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF4321F8466 for ; Tue, 17 Apr 2012 09:59:24 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so5828399pbb.31 for ; Tue, 17 Apr 2012 09:59:24 -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=oGkIc/vXqSY1PIJbDfYJftA3revrTdOQXbHVq1xCk7M=; b=rJGWJkma+wo1V/1J4LJNqwd4CnUXK2xa/cv8G9t/J+zkw07gjQ5N+xodjMwUWP5UR4 7NWXGu90g0wHMAbjJpkpyRElvgabXOURHZfNusOjIvn7dqjjw/PPxmpd9RVlXCjQ5giQ tGkzbZxY0WU6zC+JeFMGK73Pyo5F33fedYyKPDL/GjmRNyZ6EuAt6SdGiLHz4SyJGKt8 OIcPGlavWfJMOIkVAMdR305v2XeFkm5/g8fbAny63J5GcAx7rUXNz4qkQ+hJbfRSBhlI A+3UneIyRjvq/D3WziwfEzqRsC40B5ti9TEbaXODMnTjg5irAHhrLk3+biAE4PaA4vaI nsLA== MIME-Version: 1.0 Received: by 10.68.229.73 with SMTP id so9mr37381416pbc.163.1334681964435; Tue, 17 Apr 2012 09:59:24 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Tue, 17 Apr 2012 09:59:24 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> Date: Tue, 17 Apr 2012 12:59:24 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:59:25 -0000 On Tue, Apr 17, 2012 at 12:26 PM, Murray S. Kucherawy w= rote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf= Of Murray S. Kucherawy >> Sent: Tuesday, April 17, 2012 9:10 AM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2= Item 3 recommendation to split >> >> As SM also points out, this document doesn't change the status of the >> three documents. =A0That's for us to decide to do (or not) in the other >> document. > > ...although if we want RFC4408bis itself to be completely SIDF-agnostic, = perhaps we should consider the status change actions for inclusion in this = document. > > Opinions? > > -MSK > I personally think the best course of action is to ignore the 3 SIDF documents. RFC4408 does not address them and neither should 4408bis. If others wish to take up those documents to either get them marked historic or to update them in an attempt to go standards track then that is up to them. From msk@cloudmark.com Tue Apr 17 10:01: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 CD70111E80BE for ; Tue, 17 Apr 2012 10:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC3djjmowUaR for ; Tue, 17 Apr 2012 10:01:03 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id D130611E80A3 for ; Tue, 17 Apr 2012 10:01:03 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id z51L1i0010ZaKgw0151LGl; Tue, 17 Apr 2012 10:01:20 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=ZJWT_UiDdG8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=X-H97GIYAh4KDP2icRgA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 10:01:03 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split Thread-Index: AQHNF9EOQgr+SihpH0GvvLd/7ViEI5afPsKAgABB5oD//7cB0IAAgViA//+LB8A= Date: Tue, 17 Apr 2012 17:01:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6245@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <4F8D9E69.1070706@tana.it> In-Reply-To: <4F8D9E69.1070706@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334682080; bh=eedhfXAL5Tca7Mt2/ePNhY3H5nubPaXMrBBUl0wQMAY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Cy31bsp3Ke40Y/1ZMAbOOg3aabvvtlB9LKJz42c127y9pFxuilxNgZAk1AduZjrCk WXg90Jh37HM6racae7886JFh+bob0l6tZpZPIfocQTnAuJPD6l3ssOILgWwGfazbtm uKsWWGlcw5iHtppiHaTD45ZHVUSLpzY8CWahMFl4= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:01:07 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Tuesday, April 17, 2012 9:47 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 = Item 3 recommendation to split >=20 > > The DNS RRtype question is a relevant part of the question, but not > > all of it. >=20 > I'd split that point in any case, because they are two unrelated > questions. I don't see what clarity this change adds to the document, so I still disag= ree. Any other opinions? > > So, based on the data collected and presented in the document, which > > nobody has challenged yet in terms of either methods or content, the > > expression is quite appropriate. >=20 > Yes, it is. The point is that we don't need to change the status of > those documents, or recommend that the IESG does so, in order to > advance SPF. If there were consensus on that, perhaps we could do it. > But given that there doesn't seem to be consensus, it would seem easier > to skip it. The recommendation to the IESG to consider them obsolete is not itself a do= cument action. It's merely a conclusion based on the data. As SM pointed out, the current version of the experiment document doesn't c= hange the status of the other documents. It could, if that's what we think= it should do, especially if we think RFC4408bis itself should not do so. = I posed that question in my last message. =20 Personally, I think one of our two deliverables needs to take that action. = The IESG Note included at the top of the original four documents makes it = clear that the IESG (at least, the one seated back then) didn't like the id= ea of them coexisting since they share policy data but apply different algo= rithms. It seems to me the resolution of that point doesn't leave us many = options. So really the only question to me is which of the two documents s= hould do it, and whether we want to do "obsolete", or both "obsolete" and "= historic". -MSK From msk@cloudmark.com Tue Apr 17 10:01: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 114F911E80A1 for ; Tue, 17 Apr 2012 10:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlDCV1VJU3jo for ; Tue, 17 Apr 2012 10:01:54 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9B86111E8074 for ; Tue, 17 Apr 2012 10:01:53 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id z52A1i0040as01C0152AGx; Tue, 17 Apr 2012 10:02:10 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=ZJWT_UiDdG8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=0Vb-I8kydNYN0aLhMY4A:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 10:01:53 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split Thread-Index: AQHNF9EOQgr+SihpH0GvvLd/7ViEI5afPsKAgABB5oD//7cB0IAABhQggAB+2wD//4s18A== Date: Tue, 17 Apr 2012 17:01:52 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F625C@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334682130; bh=SgiNuZtZLIEbSaFWqxKLHVv4ucP7sA9v2yz0EzfMVyw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EZV+vEyNH21Tr2vc5wAS+0yPRFkoDzK4EXmXKFIG6SerUx61yI4IqfDLsNP9YG8gL roe4rzz2oWCHsdSSCfh4zu+WDE47UALKuOiPZM+NlN2b9EAz0ktbcVl1t0swLNd2DW YztiCrT9Luij29V4UmupXrUfLJE7+u0Hx7RvFKdg= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:01:58 -0000 > -----Original Message----- > From: Dotzero [mailto:dotzero@gmail.com] > Sent: Tuesday, April 17, 2012 9:59 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 = Item 3 recommendation to split >=20 > I personally think the best course of action is to ignore the 3 SIDF > documents. [...] Ignore them in RFC4408bis, or in both that and the experiment document? From hsantos@isdg.net Tue Apr 17 10:07: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 1944221F8437 for ; Tue, 17 Apr 2012 10:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59mUQhgYwCh4 for ; Tue, 17 Apr 2012 10:07:06 -0700 (PDT) Received: from dkim.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B578A21F8450 for ; Tue, 17 Apr 2012 10:07:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2372; t=1334682419; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=8zGUST9atxFfecGpmtLDNCR0c/k=; b=o22UXFtIckxfHvpeUxz1 N6KDTUZtZcMzMA30b8szjiPGWWyUPO4H3Xz5QH0dGB+IKbWRZwHzbQ7XP28MFvkc 0YnBoFndg/u7+2oLDfbUEaG3oCfvwnVxuhrMGQssYMZYGE+zuFS6KjvsszxYvTKH A01JPnBvxoJdY80zsrOGQsA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 13:06:59 -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 v6.4.454.1) with ESMTP id 3589242428.29191.1436; Tue, 17 Apr 2012 13:06:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2372; t=1334682087; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=ZNc7Uj8 QNLSjaA+Q2DiOqABift+xtDuIDxf8U43FJ7Y=; b=as58vxWOyS9h4tEfL/53s2B PyetIpNGOMe2AEP/XiHQONbDs+PSrdf1Y/CQ6fTp6aIqrtm1QxEnUM6zcUzkHGxp 9M6rs9axIbOyi8Etwi1AbV4WshSmJJvZ+StHnL9hA9NnpBz0+Rg0rK/twH7Y5mzr aPvUtfs7xozZwn2f+tig= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 13:01:27 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4188142674.1837.2564; Tue, 17 Apr 2012 13:01:26 -0400 Message-ID: <4F8DA2ED.3050601@isdg.net> Date: Tue, 17 Apr 2012 13:05:49 -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: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.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] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:07:11 -0000 Murray S. Kucherawy wrote: > > The term "de facto obsolete" means, quite literally, "from the facts, > obsolete". The dictionary defines "obsolete" as "no longer in general > use; fallen into disuse". > > So, based on the data collected and presented in the document, > which nobody has challenged yet in terms of either methods or > content, the expression is quite appropriate. Its not appropriate because its applied incorrectly. Does it imply? 1. SenderID is no longer considered by vendors? 2. It its no longer offered as an option in vendor software? i.e. operators no longer have the option to enable it? 3. It was unofficially deprecated long ago and now can be considered obsolete? 4. A Low Usage Threshold, very subjective, justifies a classification of obsolete? A key point is #4 because the SenderID Framework inherently only considered certain limited uses cases and it was long pointed out since 2006 that statistically over 80% of the transaction, it didn't apply. All the domains matched: PRA.domain = 5321.MAILFROM.domain = 5322.FROM.domain and this is reflective with SUBMITTER PRA.domain = 5321.MAILFROM.domain = 5322.FROM.domain = 5321.SUBMITTER.domain It was all part of showing that PRA consideration came a more PAYLOAD/DNS price 80% of the time, especially in the early initial deployment era when blind DNS lookups and a logical expectation for a very high waste in NXDOMAIN results. So is your conclusion based on the 20% possible spectrum of use cases is not an appropriate consideration? That the PRA proposal of that 3rd identity was invalid and incorrect and therefore allows the IETF the engineering affordability and perspective to recommend its no longer a consideration and therefore obsolete? The reality in practice is that is not obsolete. It is in play, it is still used and we know we can measure at least one part of the population with the significant volume of SUBMITTER clients. And if its not already understood, a compliant client MUST use the MAIL FROM SUBMITTER= attribute, even when the 80% of the time they are the same as 5321.MAIL FROM domain. I believe these comments are valid technical challenges to the assertion the protocols are by "de facto" obsolete. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From dotzero@gmail.com Tue Apr 17 10:15: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 6194111E80C5 for ; Tue, 17 Apr 2012 10:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLQM5d7U7XS2 for ; Tue, 17 Apr 2012 10:15:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E556011E8074 for ; Tue, 17 Apr 2012 10:15:29 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so5842261pbb.31 for ; Tue, 17 Apr 2012 10:15: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=EXNtP/EuxfPa6LXzejXdXfeY+HPEJbvbAZ5zkvgJAY8=; b=gXDhme52D6yjdwEuO0XbmsRN3EUAMgvO0YoUzjgqJ3Ny1vl6QuhTDUfh/hPrekKL/l sCwQTC8kd9ftia3bzsD095VUE2eS0PkV3ZzhpMR2daG4WGaaL1KoHHM7OlgSwfl/igk8 QUucdr17I+kpf7jdLU+Lee8KwiwuiPGHhuAzKICQm7oOcAfMam8E65Bqj+/M++L72QiS eC3hSd6CwbGk1TD16D0L5Dqj9NPJM1PEhNdcy6qXdPAgnffbj5vWhVMovSmpU/kg+hcF PTFc57Uml+yQHigOSlDuQwtqKKYaN0ih1GGeNBL7nJhVSdbZ38vl8AN1mvfs5EbcvUgB scyg== MIME-Version: 1.0 Received: by 10.68.229.73 with SMTP id so9mr37489907pbc.163.1334682929655; Tue, 17 Apr 2012 10:15:29 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Tue, 17 Apr 2012 10:15:29 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280F625C@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F625C@exch-mbx901.corp.cloudmark.com> Date: Tue, 17 Apr 2012 13:15:29 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:15:30 -0000 On Tue, Apr 17, 2012 at 1:01 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Dotzero [mailto:dotzero@gmail.com] >> Sent: Tuesday, April 17, 2012 9:59 AM >> To: Murray S. Kucherawy >> Cc: spfbis@ietf.org >> Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split >> >> I personally think the best course of action is to ignore the 3 SIDF >> documents. [...] > > Ignore them in RFC4408bis, or in both that and the experiment document? > Ignore them (or any parts which some have proposed including) in RFC4408bis. As long as the experiment document is descriptive (not prescriptive) I don't have any objections to an examination of SIDF implementation as part of that document. From hsantos@isdg.net Tue Apr 17 10:21: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 1A19E11E80A3 for ; Tue, 17 Apr 2012 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCnLoLYrbKBH for ; Tue, 17 Apr 2012 10:21:28 -0700 (PDT) Received: from dkim.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AB15E21F84B5 for ; Tue, 17 Apr 2012 10:21:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1234; t=1334683284; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=weZd7c8AG5zmTsSsRYZbIx1+jZY=; b=dBIf5K4EE21vnkTzL5Pc mxj1w41uAE9Fdu62jH0PR/L/VHMltLTezMK39/HgJm7B2mWEcF8DnkgbRTkHkou5 D72AhjKPG+n9soTvpLLDsr+DZxZ3Lfumf6EHZIyeqtsFTZ4rz9z9yFxAjsfiQjMq mLo//Lu8CsM7B3wsIOZYrF0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 13:21: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3590107579.29191.4380; Tue, 17 Apr 2012 13:21:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1234; t=1334682953; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vkpLyOR CLWtfLux36xAPH2wFuO4dwazVRAbfBjf2dHs=; b=faoYe/A7iSaVGqfDZcaY802 dAyfvZ7VynRR2asQas85vanXIdQMEhwmPVVKGsQ7vijg8XLE6G4aNoHisw53aGjX MgNPm5tdrtRc0vpF/Pv342xEofMYshkr+iH+zeFRymybrXav8vKLNCFcxw6vjXCL 3hX4+VFtHOj0IuPKcOfo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 13:15:53 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4189008283.1839.5420; Tue, 17 Apr 2012 13:15:52 -0400 Message-ID: <4F8DA64F.8090803@isdg.net> Date: Tue, 17 Apr 2012 13:20: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" References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:21:34 -0000 Dotzero wrote: >> ...although if we want RFC4408bis itself to be completely SIDF-agnostic, perhaps we should consider the status change actions for inclusion in this document. >> >> Opinions? >> >> -MSK >> > > I personally think the best course of action is to ignore the 3 SIDF > documents. RFC4408 does not address them and neither should 4408bis. > If others wish to take up those documents to either get them marked > historic or to update them in an attempt to go standards track then > that is up to them. +1, If SPFBIS is not interested in a total SPF framework solution that benefits all and can't afford or has the desire to review in earnest the SenderID Framework (SIDF), then its should not be making any subjective conclusions on the SIDF. Allow another "SIDF-BIS" WG to look at the 6+ years of integrated experiences, review its original purpose and problem solving idea, see what payoff the PRA brought, review the documented use cases and also see if they still valid today and if deemed worthy to move it forward to IS, clean it up and make any corrections of the cited conflicts with SPFBIS, if any. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Tue Apr 17 10:32: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 E011511E80A0 for ; Tue, 17 Apr 2012 10:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvI9j+eb2JfE for ; Tue, 17 Apr 2012 10:32:00 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id DDE4511E80BD for ; Tue, 17 Apr 2012 10:32:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id z5YH1i0010ZaKgw015YHUC; Tue, 17 Apr 2012 10:32:17 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=ZJWT_UiDdG8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=0Vb-I8kydNYN0aLhMY4A:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 10:32:00 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split Thread-Index: AQHNF9EOQgr+SihpH0GvvLd/7ViEI5afPsKAgABB5oD//7cB0IAABhQggAB+2wD//4s18IAAeUmA//+OzgA= Date: Tue, 17 Apr 2012 17:31:59 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6324@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F625C@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334683937; bh=ijz/IQqOthTVKkBtt9FsrWNQrBaeMUZ4icEbxdABjNU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Bae24/zWeyBgT3090GMvjWKHrCJUJ8JtVuYxrpegp3AP4qWl2Pdf6/9dPRaALnUbq gMBe/oapFmQTsx5+/a413nYqE4aJySu0MwwHYiICPsoq2TZ9i3WMA+Fsox1ZLfLGOc 4yuzhnxBdLbBJ1jbNCx7aCgAeUD6off/YGHYt0+s= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:32:05 -0000 > -----Original Message----- > From: Dotzero [mailto:dotzero@gmail.com] > Sent: Tuesday, April 17, 2012 10:15 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 = Item 3 recommendation to split >=20 > Ignore them (or any parts which some have proposed including) in RFC4408b= is. OK that part's clear. > As long as the experiment document is descriptive (not prescriptive) I > don't have any objections to an examination of SIDF implementation as > part of that document. I'm still not clear here. The question is: Do we want to consider having t= he experiment document change the status of the Sender-ID documents? It's = already doing the examination you're talking about, but the status change q= uestion remains open. -MSK From dotzero@gmail.com Tue Apr 17 10:36: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 510AA21F854B for ; Tue, 17 Apr 2012 10:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z61s1MYbUTOV for ; Tue, 17 Apr 2012 10:36:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27DB821F854A for ; Tue, 17 Apr 2012 10:36:08 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so5861756pbb.31 for ; Tue, 17 Apr 2012 10:36:07 -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=+gPXnPhMl99Nv3A4VQpnab7RJogQhE8SFPV+JmT8Uc0=; b=ZG3fcYDVW4hQ2umJrlqmZo5ITeWNijn0S0Re858YyUYl7jHD7yduW2uqx/qWM9onG8 L3K1g3qpVNvi6llaMNgF6qnWK+KwTDmmqmhO71ZAZoRyxSq5/Z2C/EZebekuiISwb8rU b1la3xeoEVh6+oWUsUdxSjFIioDYwIn7ate5aD2d/OqsReNQZWIe/l8LKdJ9Wopc2tu8 fd7ruCzdvDjX/2ETU3o/we8DbGVkmWu0foz68pYCHs2OJEaRDzzs3kyY5fBXQ42led1t TkJH9y19sh5A2UooChY4JUvWLowFgN5T5ctiylmcAK4iFaZH3XJFiTpdTSdpSRPehus/ KVrA== MIME-Version: 1.0 Received: by 10.68.204.228 with SMTP id lb4mr37820168pbc.37.1334684166565; Tue, 17 Apr 2012 10:36:06 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Tue, 17 Apr 2012 10:36:06 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280F6324@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F625C@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6324@exch-mbx901.corp.cloudmark.com> Date: Tue, 17 Apr 2012 13:36:06 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:36:09 -0000 On Tue, Apr 17, 2012 at 1:31 PM, Murray S. Kucherawy wr= ote: >> -----Original Message----- >> From: Dotzero [mailto:dotzero@gmail.com] >> Sent: Tuesday, April 17, 2012 10:15 AM >> To: Murray S. Kucherawy >> Cc: spfbis@ietf.org >> Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2= Item 3 recommendation to split >> >> Ignore them (or any parts which some have proposed including) in RFC4408= bis. > > OK that part's clear. > >> As long as the experiment document is descriptive (not prescriptive) I >> don't have any objections to an examination of SIDF implementation as >> part of that document. > > I'm still not clear here. =A0The question is: Do we want to consider havi= ng the experiment document change the status of the Sender-ID documents? = =A0It's already doing the examination you're talking about, but the status = change question remains open. > > -MSK > While I personally believe that SIDF provides little if any additional value beyond SPF - and PRA is clearly broken - I feel it is outside of the scope of the WG Charter to make changes to the status of the 3 SIDF RFCs - one way or the other. If it were within the WG Charter my poersonal position would be to mark those 3 RFCs as historic. From msk@cloudmark.com Tue Apr 17 10:38: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 E8ABF21F8551 for ; Tue, 17 Apr 2012 10:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ri9HQgK2ydr for ; Tue, 17 Apr 2012 10:38:04 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id E6F1321F854C for ; Tue, 17 Apr 2012 10:38:03 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id z5eL1i0010as01C015eLWK; Tue, 17 Apr 2012 10:38:20 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=ZJWT_UiDdG8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=0Vb-I8kydNYN0aLhMY4A:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 10:38:03 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split Thread-Index: AQHNF9EOQgr+SihpH0GvvLd/7ViEI5afPsKAgABB5oD//7cB0IAABhQggAB+2wD//4s18IAAeUmA//+OzgAADt6kAAAOo+Ng Date: Tue, 17 Apr 2012 17:38:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F634D@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F625C@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6324@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334684300; bh=vykbDx9gLNOz78XpZ5C8mWYweW3bw/b24D3XpI8WCUs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=DiQRMDuHf6F2zv4aJaT7mG69ZHgVMsmXA1rRIhrBI5cW9RzqF7HF+ZSTZu1sTBTF6 6JoN5fIFfWFvMC8elWc6Qs+H/6fKsFeRemhoFsOW1S4Z6FDBl6sTnT/voHmZ/lekAF pTAhKYxgl2Nc2s7LjrtG38Y3jDnGVv6L5P/AzZa0= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:38:08 -0000 > -----Original Message----- > From: Dotzero [mailto:dotzero@gmail.com] > Sent: Tuesday, April 17, 2012 10:36 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 = Item 3 recommendation to split >=20 > While I personally believe that SIDF provides little if any additional > value beyond SPF - and PRA is clearly broken - I feel it is outside of > the scope of the WG Charter to make changes to the status of the 3 SIDF > RFCs - one way or the other. If it were within the WG Charter my > poersonal position would be to mark those 3 RFCs as historic. Thanks, that's what I'm after. And since you said RFC4408bis itself should= ignore the others, then if we were to make that status change (and you fel= t the charter permitted such), the experiment document would be the place t= o do it? From vesely@tana.it Tue Apr 17 10:38: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 4E5B621F8559 for ; Tue, 17 Apr 2012 10:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU6SKHvyOuTi for ; Tue, 17 Apr 2012 10:38:08 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DA3DF21F8550 for ; Tue, 17 Apr 2012 10:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334684287; bh=MxdrqSl3tjE1jSiNoi8ZQA/laudyYIIz3kEIGPASDHA=; l=3049; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=StUpCJWao046SK3m9mPq+5hv6Q4CmZ9IpkeWPtKhG+Pf26Yv4bLX6shTdpEnRzXNu VsO76zG4rzVKd33r3mP34MFZ6SzVOO4gVe/q4R1BChHTT9KnKDVeQlwyJ2CyGRHNsQ vK8n0OK/X08WhtVc+WnvqMMJ3iE4FxSXYd994FQo= Received: from [192.168.8.53] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Apr 2012 19:38:06 +0200 id 00000000005DC039.000000004F8DAA7E.00004BA2 Message-ID: <4F8DAA7A.9030507@tana.it> Date: Tue, 17 Apr 2012 19:38:02 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1357789.Kafn83GcaR@scott-latitude-e6320> <4F8D9335.2090204@tana.it> <4213133.7QvcCDOQnQ@scott-latitude-e6320> In-Reply-To: <4213133.7QvcCDOQnQ@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:38:12 -0000 On Tue 17/Apr/2012 18:47:15 +0200 Scott Kitterman wrote: > On Tuesday, April 17, 2012 05:58:45 PM Alessandro Vesely wrote: >>> Even if it were in scope, it would still be a bad idea since it only works >>> if the identity in HELO is trusted in some manner. >> >> I'm not following you. The correction doesn't imply whitelisting a specific >> helo identity (that's mentioned in 9.3.3.1). It relies on an SPF "pass" >> result for the helo identity, with no trust implications whatsoever. > > This is similar to my objection to SUBMITTER overriding Mail From. Here's an > example: > > EHLO: bad.example.net > Mail From: good.example.com It would be similar if you had to validate the helo identity against some value to be determined later examining the message content. > Based on the published SPF records for both and the connect IP address, in > this example, the SPF check for bad.example.net passes and the check for > good.example.com fails. I'm not sure what you mean by "passes". If bad.example.net passes, then the server found the IP address of the connecting client in an SPF record under that DNS label. I'm not proposing "helo-neutral prevents rejection", but helo-pass. > If the EHLO result trumps the Mail From result, then malicious senders can > trivially construct arbitrary hostnames and arrange for a HELO/EHLO pass > result. Yes, but since --as we discussed before-- they cannot realistically hope to induce backscatter, they would easily obtain exactly the same result by forging the Mail From in the same way as they forge EHLO. It is not difficult for a malicious sender to say: EHLO: good.example.com Mail From: good.example.com > This is, without external information, indistinguishable from: > > EHLO: relay.example.net > Mail From: good.example.com > > This may be a transparent relay (AKA forwarder). According to this proposal, we'd require that example.net define an SPF record, under the label relay.example.net, where they authorize the IP addresses that their relay uses. This workaround might be acceptable considering the many reasons why such kind of relaying/forwarding should not be done. The only clients that behave the way you exemplified are forwarders who are unable to do better than that. That workaround is good enough, as long as we consider that publishing an SPF record for each relay has no contraindications (which SRS and other solutions apparently have). > In order to let a pass HELO/EHLO result trump a fail Mail From result, you > have to know and trust the host in question, otherwise you've just made SPF > pointless. That would be true if I knew the Mail From. Since I know neither, they are equivalent. > This is NOT how SPF works today and changing it to work this way is > completely out of scope. What I'm proposing to change is how it chokes, not how it works. And although it is a small fraction of cases, it generates so much noise as to become a major hindrance to universal adoption of reject-on-fail. From vesely@tana.it Tue Apr 17 10:38: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 ABB6F21F8550 for ; Tue, 17 Apr 2012 10:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZSz0zK3WO-F for ; Tue, 17 Apr 2012 10:38:31 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22221F854C for ; Tue, 17 Apr 2012 10:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334684300; bh=1C8j0URheoS8LYyWpldqxWM/W3jyxLFVQcUP7elcAPg=; l=1143; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=PRR+XKxq6JpyZX7I2jD/HROi1wrw+WWdiUONAbR2qfUBBLAIRfQcAvArEx3BzK2Mw cYnIbKG745bbr6x5NEKl58bkxvXn8SDKcLaE8QTXMmTrEsk5Y2Vs44nQCKeoUIsjjq jUf/5OIT4v+a8eypsNr9Db1MLKCr/9HpqgBSiMKk= Received: from [192.168.8.53] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Apr 2012 19:38:19 +0200 id 00000000005DC039.000000004F8DAA8C.00004BD1 Message-ID: <4F8DAA88.9000402@tana.it> Date: Tue, 17 Apr 2012 19:38:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280F448B@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F448B@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:38:35 -0000 On Tue 17/Apr/2012 18:03:23 +0200 Murray S. Kucherawy wrote: > > there will be an -04 before we go about requesting WGLC. I'd like to run an extra test, but I'm out of the office right now, and it will presumably take some more time anyway to complete. That's the test we talked about in Paris. As inconclusive as we concluded it would be, it may still bring some more knowledge of the existing implementations. Let me recall the idea: For the MXes corresponding to the surveyed domains, start an SMTP session and initiate transactions that contain the command, say, MAIL FROM: Some servers are setup to plainly fail that command. If not, the test could check whether a recipient like postmaster@the-domain-being-tested succeeds. Finally, if a rejection is substantiated, the test could check whether using an SPF-authorized helo identity has any effect. I think we can consider any treatment after an accepted RCPT TO an indirect effect of the SPF check, even a reject after data --that the test will never reach. Thus, the outcome will indicate how many servers directly reject on fail. From dotzero@gmail.com Tue Apr 17 10:45: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 694A121F8551 for ; Tue, 17 Apr 2012 10:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36-n117tZQQR for ; Tue, 17 Apr 2012 10:45:42 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8B21F8572 for ; Tue, 17 Apr 2012 10:45:38 -0700 (PDT) Received: by dady13 with SMTP id y13so12007620dad.27 for ; Tue, 17 Apr 2012 10:45: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:content-transfer-encoding; bh=YhDsInii6mKLXVs1vwSD3DKPTRps6fOEQ0USNJm4z/Y=; b=wgGxN8DSZeRf0EmjX4ChPUoDQWPy3Lmz/jQZy1Yy54CK6VePxBf4fPXDVdeznA/uxK 7OMBG8A6FLVJbpVyG/aViJOtwDDbu0vg2HN49lLiCMCyFpgdoS3yswggJ+4ngEPtWbGU qybmAuGAkTyVUUI+TXJpkrWMZRSRD9Z4VwLl9WQhAGok+mELj88ET/sHSlnM+JVmHVt2 kF7DYGaG2xAPWPjCjg8PBJZ+bK4jeOdQWRv5CqURgXo6MmNgZScHahJp48rlJ+vfpi/2 Su77z/7Q4FAprOVOStDfzm0SpoAqw54XCOeLP5rchxPfMwyKWG3izUhrd73pXzCocaEN hk0A== MIME-Version: 1.0 Received: by 10.68.217.67 with SMTP id ow3mr38458070pbc.16.1334684734693; Tue, 17 Apr 2012 10:45:34 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Tue, 17 Apr 2012 10:45:34 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280F634D@exch-mbx901.corp.cloudmark.com> References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F625C@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6324@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F634D@exch-mbx901.corp.cloudmark.com> Date: Tue, 17 Apr 2012 13:45:34 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:45:45 -0000 On Tue, Apr 17, 2012 at 1:38 PM, Murray S. Kucherawy wr= ote: >> -----Original Message----- >> From: Dotzero [mailto:dotzero@gmail.com] >> Sent: Tuesday, April 17, 2012 10:36 AM >> To: Murray S. Kucherawy >> Cc: spfbis@ietf.org >> Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2= Item 3 recommendation to split >> >> While I personally believe that SIDF provides little if any additional >> value beyond SPF - and PRA is clearly broken - I feel it is outside of >> the scope of the WG Charter to make changes to the status of the 3 SIDF >> RFCs - one way or the other. If it were within the WG Charter my >> poersonal position would be to mark those 3 RFCs as historic. > > Thanks, that's what I'm after. =A0And since you said RFC4408bis itself sh= ould ignore the others, then if we were to make that status change (and you= felt the charter permitted such), the experiment document would be the pla= ce to do it? > > I've already indicated that I believe this is outside the WG charter. I've already indicated my belief that "fixing"/moving 4405-7 to standards track is outside the scope of the WG charter. This would leave marking them historic. I don't know what the process is for that. Again though, I'd prefer to let sleeping dogs lie and focuse on updating 4408 and getting it on Standards track. From R.E.Sonneveld@sonnection.nl Tue Apr 17 10:49: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 678EE21F84FB for ; Tue, 17 Apr 2012 10:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug90UPs6lidP for ; Tue, 17 Apr 2012 10:49:49 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0D11E80A0 for ; Tue, 17 Apr 2012 10:49:48 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M2M00I00XIZSS00@helium.mailtransaction.com>; Tue, 17 Apr 2012 19:49:47 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M2M008XWXIYMA00@helium.mailtransaction.com>; Tue, 17 Apr 2012 19:49:47 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nyW3R6J3jBdl2c+dZ2a6Nw)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M2M00G4EXIY2700@lion.sonnection.nl> for spfbis@ietf.org; Tue, 17 Apr 2012 19:49:46 +0200 (CEST) Message-id: <4F8DAEEA.8020607@sonnection.nl> Date: Tue, 17 Apr 2012 19:56:58 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: "Murray S. Kucherawy" References: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> In-reply-to: <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1334684987; bh=6r0OzylrK62jtUxvp2b16cIDPilFQgSCDgEwZniHvso=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=Q0dWL4UG3Ikb6LxSMj1pi9CM1UGDWUkTS8WW9UPFzoZER+gz0FAV6b/qtha2VeRG/ UVMv/atmw8CI8MXy4Z9sjFd3+BSm8oKK4lHnPCTlPCUw91KYRBR8Hz2if/kyzjnE9Q KpRRgzEwQ777z97Hiap2NOoIctReMoEIeLOw98FA= X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0M2M00I00XIZSS00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:49:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_nyW3R6J3jBdl2c+dZ2a6Nw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 4/17/12 6:26 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy >> Sent: Tuesday, April 17, 2012 9:10 AM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split >> >> As SM also points out, this document doesn't change the status of the >> three documents. That's for us to decide to do (or not) in the other >> document. > ...although if we want RFC4408bis itself to be completely SIDF-agnostic, perhaps we should consider the status change actions for inclusion in this document. > > Opinions? Another option is, similar to what happened with 4870 and 4871: publish a set of four new documents, where the 4405bis, 4406bis and 4407bis documents all get: Obsoleted By: RFC4408bis Category: Historic This way, the SPFBIS charter is not violated, in my opinion, as it states: The group will complete additional work on SPF (described below), but will not complete additional work on the Sender-ID specification. By publishing the SIDFbis documents as obsoleted/historic, no additional work has been done on the Sender-ID specification. If the SIDF documents are not declared historic/obsoleted, the conflicting interests of SPF and Sender-ID with respect to the use of the DNS records is not resolved and it may not be able to advance SPF as standards track document. /rolf --Boundary_(ID_nyW3R6J3jBdl2c+dZ2a6Nw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 4/17/12 6:26 PM, Murray S. Kucherawy wrote: 
-----Original Message-----
From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, April 17, 2012 9:10 AM
To: spfbis@ietf.org
Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split

As SM also points out, this document doesn't change the status of the
three documents.  That's for us to decide to do (or not) in the other
document.

...although if we want RFC4408bis itself to be completely SIDF-agnostic, perhaps we should consider the status change actions for inclusion in this document.

Opinions?

Another option is, similar to what happened with 4870 and 4871: publish a set of four new documents, where the 4405bis, 4406bis and 4407bis documents all get:

Obsoleted By: RFC4408bis
Category: Historic

This way, the SPFBIS charter is not violated, in my opinion, as it states:

The group will complete additional work on SPF
      (described below), but will not complete additional work on the
      Sender-ID specification.

By publishing the SIDFbis documents as obsoleted/historic, no additional work has been done on the Sender-ID specification.

If the SIDF documents are not declared historic/obsoleted, the conflicting interests of SPF and Sender-ID with respect to the use of the DNS records is not resolved and it may not be able to advance SPF as standards track document.

/rolf

--Boundary_(ID_nyW3R6J3jBdl2c+dZ2a6Nw)-- From dotis@mail-abuse.org Tue Apr 17 11:08: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 93BF621F848B for ; Tue, 17 Apr 2012 11:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IxqZWRkbOck for ; Tue, 17 Apr 2012 11:08:19 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id D395721F8575 for ; Tue, 17 Apr 2012 11:08:18 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 92B9417400E2 for ; Tue, 17 Apr 2012 18:08:18 +0000 (UTC) Message-ID: <4F8DB192.2080808@mail-abuse.org> Date: Tue, 17 Apr 2012 11:08:18 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> <4F8CA8FE.4010201@mail-abuse.org> <4F8D7077.7040904@tana.it> In-Reply-To: <4F8D7077.7040904@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 18:08:20 -0000 On 4/17/12 6:30 AM, Alessandro Vesely wrote: > On Tue 17/Apr/2012 15:26:05 +0200 Douglas Otis wrote: >> On 4/14/12 7:45 AM, Alessandro Vesely wrote: >> >>> Actually, it seems to me that those who reject can be accused of >>> breaking those SMTP features. To resolve the conflict we must devise >>> a safe way of rejecting, such that servers can adhere to it with no >>> risks. Our task is not to mandate it, but to enable it. >> Agreed. For example, this could be done using something as simple as >> incorporating the scope-ID used in RFC4406 to clarify applicable SMTP >> parameters with a list of EHLO / MFROM. When the scope contains just EHLO, >> only then will SPF verification offer a means to "authenticate" a source. > We cannot do that for this SPF version. However, we could require that a > helo-pass prevents rejection. Dear Alessandro, Disagree, but the inverse would be true. EHLO identity based failure permits SMTP compliant rejection by SPF "-all" records. The EHLO identity compliance provides a basis for a MUST REJECT requirement that avoids conflicts with existing use protected by existing standards. EHLO also offers safer DKIM domain alignments since both use A-labels. Asserting identity scopes in future record versions would ensure against possible misuse and prevent authorization escalating to authentication. Regards, Douglas Otis From johnl@iecc.com Tue Apr 17 11:39: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 A466C21F847F for ; Tue, 17 Apr 2012 11:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.941 X-Spam-Level: X-Spam-Status: No, score=-110.941 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXCS90g2SoiQ for ; Tue, 17 Apr 2012 11:39:03 -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 2894621F847D for ; Tue, 17 Apr 2012 11:39:02 -0700 (PDT) Received: (qmail 48406 invoked from network); 17 Apr 2012 18:39:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Apr 2012 18:39:00 -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=4f8db8c4.xn--3zv.k1204; i=johnl@user.iecc.com; bh=ojyi04/+CPa+8Hmt+SG+We7Rp7a0sLWwgEjruUfVYV4=; b=LgogbeEcZct2ePDeJWz7R03HeP9ajXbYbs6qSvuULASKjWm0Em/RFehXWePTjMt5EP1SEKkJwrtAn1Gc/eJ0iCpRZIHylfkU9zuNHGWsmM2fEiXZB5tJZWsA31ci2P2b3pIXE4u/g/FqxoNf5XYvkhvzsVecFi6/8zeCqo7WKwY= 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=4f8db8c4.xn--3zv.k1204; olt=johnl@user.iecc.com; bh=ojyi04/+CPa+8Hmt+SG+We7Rp7a0sLWwgEjruUfVYV4=; b=TMtZxKTs5ucoNlUw8vxLNZeqL05ZZQGUCTX8rCrRtgV3+xCoVT29sXnJ+jqKFa4Yz1fIk1bzEmq5+sQze8pgC9PuPwZThBTT4+zHLu6sMrAPIEbHU7UIK1NVg3gVefPcy/ozD+3Thi2sbwmqvZmsDYuBR7Re8MMShyEOPVbb4jg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Apr 2012 18:38:37 -0000 Message-ID: <20120417183837.73069.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F8DAEEA.8020607@sonnection.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: R.E.Sonneveld@sonnection.nl Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 18:39:10 -0000 >If the SIDF documents are not declared historic/obsoleted, the >conflicting interests of SPF and Sender-ID with respect to the use of >the DNS records is not resolved and it may not be able to advance SPF as >standards track document. This seems exceedingly unlikely unless our ADs are a lot dimmer than I think they are. We all know that there's no practical problem. If it's OK with the IESG for the experiment report to reclassify 4405 through 4407 as historic, that would be a reasonable thing to do. Or failing that, someone could do one-page independent submission similar to RFC 6547 that just notes that they're historic now. But it's not urgent. R's, John From msk@cloudmark.com Tue Apr 17 11: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 A673B21F852E for ; Tue, 17 Apr 2012 11:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CHM+4-BlyXV for ; Tue, 17 Apr 2012 11:48:09 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6A10821F852B for ; Tue, 17 Apr 2012 11:48:09 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id z6nx1i0030ZaKgw016nxy0; Tue, 17 Apr 2012 11:47:58 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=W866pGqk c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=ZJWT_UiDdG8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=bdkMaEdFIym-zm0ZzGAA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 11:47:58 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split Thread-Index: AQHNHMljxGfpDm0zEECzfi0lnHnkppafW3dQ Date: Tue, 17 Apr 2012 18:47:57 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6526@exch-mbx901.corp.cloudmark.com> References: <4F8DAEEA.8020607@sonnection.nl> <20120417183837.73069.qmail@joyce.lan> In-Reply-To: <20120417183837.73069.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334688478; bh=Kk9EatkciC+/4bQhLD1hFovenGNT8zvvBbiim2QDKS4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nm0/BxLOCDii6ikUooW8ZXWKToh4lEczu1OPTulvYUg7iK91hXt0IG6kvG0SUQPsY XPUq/72gUZAmMiRY+/Dw8nF9J7WOSSAFwA1qH9MVQ3z9bB5xYeqEy2zpvo1CzcdU0y 3Bi2z63bSrv4mt8UuuxL32+VLbDN665KGzYeDcGo= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 18:48:13 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Levine > Sent: Tuesday, April 17, 2012 11:39 AM > To: spfbis@ietf.org > Cc: R.E.Sonneveld@sonnection.nl > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 = Item 3 recommendation to split >=20 > If it's OK with the IESG for the experiment report to reclassify 4405 > through 4407 as historic, that would be a reasonable thing to do. Or > failing that, someone could do one-page independent submission similar > to RFC 6547 that just notes that they're historic now. But it's not > urgent. On the other hand, given the text of the IESG Note in those RFCs, they migh= t ask why we didn't. -MSK From johnl@iecc.com Tue Apr 17 12:20: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 DC75F11E80C5 for ; Tue, 17 Apr 2012 12:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.959 X-Spam-Level: X-Spam-Status: No, score=-110.959 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO6wrpHkQ9WY for ; Tue, 17 Apr 2012 12:20: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 1311C11E80BA for ; Tue, 17 Apr 2012 12:20:47 -0700 (PDT) Received: (qmail 55974 invoked from network); 17 Apr 2012 19:20:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Apr 2012 19:20:45 -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=4f8dc28d.xn--btvx9d.k1204; i=johnl@user.iecc.com; bh=UWj/fbZops4KYa30Mm2H7GuBwP+JyENbAd7EBwv2iEw=; b=dGqOpL0pOsFjOscRj6dE607+0xfoMSBp2FmcIewec1o+r6BuwshFV+kGJJgERk0jSVmp/6wuGMA6sMdB31CVgE56UtRkDOFJxLyrWDZnk2HAQAlh352IiQ2upLMwlcbwbiXY8QtbwHAyuh0HauwISRPwvJVnM394jB3FuL1Umo0= 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=4f8dc28d.xn--btvx9d.k1204; olt=johnl@user.iecc.com; bh=UWj/fbZops4KYa30Mm2H7GuBwP+JyENbAd7EBwv2iEw=; b=cl+GxpFNNNj1o6af1zwogEbPPSYULkeLGCgTqcqdje0Ay0qA2t36b/aOjOruMJVh24wU4ds59JG3Ga8vs230SM9u9MdTyyI7wpsAEQOiVuHifG01tgAa0yV265DaiATqlgiC1nbDD9j+XT1hb3eo0fSy91qOnTQ/b09eDrcI6yw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Apr 2012 19:20:21 -0000 Message-ID: <20120417192021.60660.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E0039280F6526@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:20:54 -0000 >> If it's OK with the IESG for the experiment report to reclassify 4405 >> through 4407 as historic, that would be a reasonable thing to do. Or >> failing that, someone could do one-page independent submission similar >> to RFC 6547 that just notes that they're historic now. But it's not >> urgent. > >On the other hand, given the text of the IESG Note in those RFCs, they might ask why we didn't. Perhaps we could ask our AD to inquire whether it'd be OK for the experiment report to do the reclassification. R's, John From hsantos@isdg.net Tue Apr 17 12:50: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 0960411E80D9 for ; Tue, 17 Apr 2012 12:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMglz47vRP08 for ; Tue, 17 Apr 2012 12:50:11 -0700 (PDT) Received: from winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7598D11E80D6 for ; Tue, 17 Apr 2012 12:50:11 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=961; t=1334692204; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ssqpdJuRdyD5PFsszs8PXDzLGEg=; b=XN9oFZtxEjIZbrDGrBnB b2JDTJj2edh2TLrCWoPs/vQgtFMl7nclA7D7sfT7YaJHVQvOZaqbkUROW6neBL/k /DARLpx2TYsRu2gNdqw42cf1zUw9F/cPMA1H81UvSyxgEqgqgjOgrXcMPJnAkmSJ uRCq82RBFcrh9pXMSf7pR7c= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 15:50:04 -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 v6.4.454.1) with ESMTP id 3599027700.29191.3776; Tue, 17 Apr 2012 15:50:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=961; t=1334691872; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=IRTkk2C 0SEjJU4GII6W4lxFgHgZtaP4Gfj7+obXoJQg=; b=1VQY/s1x+XPxS1CY4SC5sk6 63PyfZ6kRa1gxSvZ8hq3eVua3nhcLevTzuSCmFItWAwCIQqKsqdxS0H62BeLcZ7U uFdzReQ7ql6STwT3C260YBqF3ixiuevTqgkbKr6E7sqDD94s43xT1u6EC9qCGPxa nrO2tNEUSNDq/XFQYh2Y= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 15:44:32 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4197928127.1851.1988; Tue, 17 Apr 2012 15:44:32 -0400 Message-ID: <4F8DC925.1030709@isdg.net> Date: Tue, 17 Apr 2012 15:48: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: <20120411041939.18506.10899.idtracker@ietfa.amsl.com> <4F8561D8.4030208@isdg.net> <6.2.5.6.2.20120417002539.0af11520@resistor.net> <4F8D6F25.9010203@tana.it> <9452079D1A51524AA5749AD23E0039280F60C3@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6149@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F625C@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F6324@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280F634D@exch-mbx901.corp.cloudmark.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:50:17 -0000 Dotzero wrote: >> Thanks, that's what I'm after. �And since you said RFC4408bis itself should ignore the others, then if we were to make that status change (and you felt the charter permitted such), the experiment document would be the place to do it? >> >> > > I've already indicated that I believe this is outside the WG charter. > I've already indicated my belief that "fixing"/moving 4405-7 to > standards track is outside the scope of the WG charter. This would > leave marking them historic. IMV, it doesn't seem proper to make any status changes, including one to Historic. If its not prepared to do a thorough technical review of all the 6+ years experimentation of the SPF/SenderID Framework as recommended by the IESG either as separate or in tandem, then any decision of lieu of a real review, conflicts with its declared out of scope status. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From sm@elandsys.com Tue Apr 17 12:50: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 49BB511E80D9 for ; Tue, 17 Apr 2012 12:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqctcWEN6U+1 for ; Tue, 17 Apr 2012 12:50: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 1817311E80D6 for ; Tue, 17 Apr 2012 12:50:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.171]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3HJoOnK023208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 12:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334692238; i=@elandsys.com; bh=ivTMHUGGd8VckRqo3jPqAF4iZLWaaxDNSGru7dTHlgk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pl7yNtBnXa+A8NsHLtUWDvN3/GqhOBdvQOTvIrTaW74bTBsqj7wgRhY40ydKCwlJS CAPu/jJoxHkSFHv14Cr2p1r3hUHi6W22yxhCJmJgJptqEsLNVg7HWut2UEkh+UThW6 Xs6bWhhC0LXp14d0amJjT+rE++dojuqm3d308YDk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334692238; i=@elandsys.com; bh=ivTMHUGGd8VckRqo3jPqAF4iZLWaaxDNSGru7dTHlgk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OIgb/c7NgWO3ObUL+WlmjDUxCK9Q+lA7IeuvdhVmsIt8lVgGlw9Wx4WOevH4gWfAn Nh6WYn9ab4ucGBLaDOY7kUIJrD+ULEj1sHItidXM9DHtr4IBvfluwv3rAJ6dCmqC2m JquxRD+an2iixQKP+dKdaU86bqAEo5vO+87bhims= Message-Id: <6.2.5.6.2.20120417123436.0abae878@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Apr 2012 12:48:52 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120417192021.60660.qmail@joyce.lan> References: <9452079D1A51524AA5749AD23E0039280F6526@exch-mbx901.corp.cloudmark.com> <20120417192021.60660.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: John Levine Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:50:50 -0000 At 12:20 17-04-2012, John Levine wrote: >Perhaps we could ask our AD to inquire whether it'd be OK for the >experiment report to do the reclassification. http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html Regards, S. Moonesamy From spf2@kitterman.com Tue Apr 17 13:01: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 B607921F84F3 for ; Tue, 17 Apr 2012 13:01: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ove-RIhIoiHJ for ; Tue, 17 Apr 2012 13:01:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF7F21F84F1 for ; Tue, 17 Apr 2012 13:01:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B236620E40CC; Tue, 17 Apr 2012 16:01:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334692872; bh=l89nqMSGl5lggqA6fVQJtl1UIbdxf++RR0cPQcHxLDI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=doHbLBehHP4CWBpjueAZ4sedR07AiqjOlXhckRLsQtOP7j8X7q62ayoWh0zZSWobE WtBzwBNYZaAbj9FRvfz9vzxtkBNCpLFxjMaIEzTgiC/KDYO3sjw7LBMMb302EqfwNn D6LiFSrSzxCYSJye75eRkZEPHGF5twVM5PlzclQQ= Received: from scott-latitude-e6320.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 ESMTPSA id 98D8920E4064; Tue, 17 Apr 2012 16:01:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Apr 2012 16:01:11 -0400 Message-ID: <5882493.5Mykm05NRS@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20120417123436.0abae878@resistor.net> References: <9452079D1A51524AA5749AD23E0039280F6526@exch-mbx901.corp.cloudmark.com> <20120417192021.60660.qmail@joyce.lan> <6.2.5.6.2.20120417123436.0abae878@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] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:01:17 -0000 On Tuesday, April 17, 2012 12:48:52 PM S Moonesamy wrote: > At 12:20 17-04-2012, John Levine wrote: > >Perhaps we could ask our AD to inquire whether it'd be OK for the > >experiment report to do the reclassification. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html > So if they complain we didn't obsolete the Sender ID RFCs we can tell them they should have given us a better charter. Scott K From msk@cloudmark.com Tue Apr 17 13:04: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 C34CE11E80BA for ; Tue, 17 Apr 2012 13:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPQS+w80+0HP for ; Tue, 17 Apr 2012 13:04:15 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8D07421F848A for ; Tue, 17 Apr 2012 13:04:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id z84Y1i0010ZaKgw0184YCe; Tue, 17 Apr 2012 13:04:32 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=_RWgGLA2ZFgA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=6oOKkq69zweqNnNsXDwA:9 a=CjuIK1q_8ugA:10 a=lLZfSwNMdGkA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 13:04:14 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split Thread-Index: AQHNHNTo9FUSgYTSmke6r1d14RZ+gJafcFPg Date: Tue, 17 Apr 2012 20:04:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6A9D@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280F6526@exch-mbx901.corp.cloudmark.com> <20120417192021.60660.qmail@joyce.lan> <6.2.5.6.2.20120417123436.0abae878@resistor.net> <5882493.5Mykm05NRS@scott-latitude-e6320> In-Reply-To: <5882493.5Mykm05NRS@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334693072; bh=sSR4z+xLMiFfqBXp6Gzd0mAfwddDp4f2E052Bgzt/bo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SWicRpufStfctIwL9P02VFbk4Isf+AReZDACP1JJwj9EEk+fzLSHCLAxq6GoxO2zG qEG6l6IubH7NIejq23JTO8REd1vVnqzWLfAo188tEJwf3KULXVtv6W+RJ08pQ0G5/W 7ICIa6VAxNyCfe0L9zZu7p0a0P4xzgFa3sP5x3pw= Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:04:19 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, April 17, 2012 1:01 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 = Item 3 recommendation to split >=20 > On Tuesday, April 17, 2012 12:48:52 PM S Moonesamy wrote: > > At 12:20 17-04-2012, John Levine wrote: > > >Perhaps we could ask our AD to inquire whether it'd be OK for the > > >experiment report to do the reclassification. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html >=20 > So if they complain we didn't obsolete the Sender ID RFCs we can tell > them they should have given us a better charter. I'm pretty sure that, to tie up this loose end as Dave suggests: a) The IESG could decide to do so on its own based on our document(s), with= out us actually saying so; or b) We could make the request to the IESG without an accompanying document; = or c) An individual could make such a request. -MSK From msk@cloudmark.com Tue Apr 17 13:14: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 D28C511E80C6 for ; Tue, 17 Apr 2012 13:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J-VtIPhWPmM for ; Tue, 17 Apr 2012 13:14:33 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id DC5C011E80BA for ; Tue, 17 Apr 2012 13:14:33 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id z8Eq1i0030as01C018EqGU; Tue, 17 Apr 2012 13:14:50 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=DT6a4BtRxdAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=dqLhg3ObAAAA:8 a=ULkY-ZCyShw9YuW-u7EA:9 a=6LJ_FtwbcJf9weKk2zkA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=y3ZDLB1yaQwA:10 a=ZhjvvJR0poYy_yqA:21 a=86pnuRbKbIepbxLt:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 13:14:33 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt Thread-Index: AQHNHFAzU6UbIC23j0+O47qTsnarm5aeZ/swgAFWegD//7UUwA== Date: Tue, 17 Apr 2012 20:14:32 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6ACD@exch-mbx901.corp.cloudmark.com> References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280F448B@exch-mbx901.corp.cloudmark.com> <4F8DAA88.9000402@tana.it> In-Reply-To: <4F8DAA88.9000402@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334693690; bh=EQCxmpZunAGrtdxjdO2C26l6KdrEULYC3IwJQiUkJqM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bdma1c5d6rr3wLdNh1mbVCVWfVBJB/GItD0fpaZ5advraxmf/NeYUMvX4RiDe31L4 9NpvKiCPwQPTURfhw2hmIFAoqHNm0muTce14Y6/ZzXV/heS8fYWWtGzwEdkrCh0sow UMTJBO2zpBEJ28fyGmLX//CcEUywvUG/UbXtGTio= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:14:37 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Tuesday, April 17, 2012 10:38 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt >=20 > I'd like to run an extra test, but I'm out of the office right now, and > it will presumably take some more time anyway to complete. >=20 > That's the test we talked about in Paris. As inconclusive as we > concluded it would be, it may still bring some more knowledge of the > existing implementations. >=20 > Let me recall the idea: For the MXes corresponding to the surveyed > domains, start an SMTP session and initiate transactions that contain > the command, say, >=20 > MAIL FROM: >=20 > Some servers are setup to plainly fail that command. If not, the test > could check whether a recipient like postmaster@the-domain-being-tested > succeeds. > Finally, if a rejection is substantiated, the test could check whether > using an SPF-authorized helo identity has any effect. >=20 > I think we can consider any treatment after an accepted RCPT TO an > indirect effect of the SPF check, even a reject after data --that the > test will never reach. Thus, the outcome will indicate how many > servers directly reject on fail. My concern with this approach is that it's not accurate. A 5yz reply to MA= IL FROM isn't guaranteed to be caused by SPF because there isn't a specific= SMTP reply code or enhanced status code that guarantees the rejection is c= aused by SPF. For all you know, a DNSBL could be the cause of the error. The same goes for a DATA failure and SIDF, where those could be caused by D= KIM failures, ADSP failures, or any content analysis error you can imagine. By contrast, the survey data currently represented in the experiment docume= nt don't have the "maybe" sort of quality to them. -MSK From hsantos@isdg.net Tue Apr 17 13:25: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 F321721F845B for ; Tue, 17 Apr 2012 13:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtrMQCVXFtJb for ; Tue, 17 Apr 2012 13:25:34 -0700 (PDT) Received: from winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2D21F8450 for ; Tue, 17 Apr 2012 13:25:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=669; t=1334694330; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=EVZnpcIHuoajxSOVO7CbrgK0LrM=; b=UjtlfcRW8ZODr3xkabna zplurGpHRngp0KNA3RIGiJtXtawV6R0j2ZP1hb+UT87JcCA3Ajy482tCvY9tFddV olAfvA+hk9cFC64Sjn/+oLF0eVJ+RUPG7wiL1rDR9uyNCvbIBmVH0o1ZEURUrEn1 hrOEd/fvHgD9kITjPdj9WEg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 16:25: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 v6.4.454.1) with ESMTP id 3601152902.29191.6132; Tue, 17 Apr 2012 16:25:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=669; t=1334693999; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=l/8Ou2y 6bzsmJG7fJVDg5pDLrM/dbF4lEVxo64kAIeE=; b=izXPt30qjfwK5PKbItpjQ6U 7Hl0INq0dm+fVNFjl+nO+k/XJTtrAaZPdZbcY1by97PHidBERgdVuO6/pHOlZNkH w/wQUuTi4tYLNRdPCRC/c0RGsAy1EBTmy+0Y7CFrG0sYALz1KSoekX+8e5bKQ2QT 31IcaaLy9aRB/kLz+09g= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 16:19:59 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4200055315.1854.5104; Tue, 17 Apr 2012 16:19:59 -0400 Message-ID: <4F8DD175.7000407@isdg.net> Date: Tue, 17 Apr 2012 16:24:21 -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: <4F8DAEEA.8020607@sonnection.nl> <20120417183837.73069.qmail@joyce.lan> <9452079D1A51524AA5749AD23E0039280F6526@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F6526@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:25:40 -0000 Murray S. Kucherawy wrote: > > On the other hand, given the text of the IESG Note in those RFCs, they might > ask why we didn't. Or they may ask or is asked they consider why the cited conflicts, if it actually existed and provided serious conflicts, were not resolved? I don't agree it was just a "Select One or other" consideration, but also how they could coexist in tandem: The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From dhc@dcrocker.net Tue Apr 17 13:26: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 6524521F8450 for ; Tue, 17 Apr 2012 13:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.235 X-Spam-Level: X-Spam-Status: No, score=-4.235 tagged_above=-999 required=5 tests=[AWL=-1.636, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElRXrDAlE5cp for ; Tue, 17 Apr 2012 13:26:28 -0700 (PDT) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by ietfa.amsl.com (Postfix) with ESMTP id 491F521F844B for ; Tue, 17 Apr 2012 13:26:28 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id q3HKQOti012283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 13:26:27 -0700 Message-ID: <4F8DD1EF.3050708@dcrocker.net> Date: Tue, 17 Apr 2012 13:26:23 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E0039280F6526@exch-mbx901.corp.cloudmark.com> <20120417192021.60660.qmail@joyce.lan> <6.2.5.6.2.20120417123436.0abae878@resistor.net> <5882493.5Mykm05NRS@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280F6A9D@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F6A9D@exch-mbx901.corp.cloudmark.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 (sbh11.songbird.com [72.52.113.11]); Tue, 17 Apr 2012 13:26:27 -0700 (PDT) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split 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, 17 Apr 2012 20:26:32 -0000 On 4/17/2012 1:04 PM, Murray S. Kucherawy wrote: > I'm pretty sure that, to tie up this loose end as Dave suggests: ... > b) We could make the request to the IESG without an accompanying document; or While they will, no doubt, need some sort of document draft to refer to for this, it doesn't need to get published. A one-page I-D with the recommendation is probably enough. In any event, your b) path is the direction I'm thinking is sufficient. d/ -- Dave Crocker bbiw.net From msk@cloudmark.com Tue Apr 17 13:43: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 7063D21F8474 for ; Tue, 17 Apr 2012 13:43:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vehFH-8PR5U for ; Tue, 17 Apr 2012 13:43:54 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7E10921F8473 for ; Tue, 17 Apr 2012 13:43:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id z8kB1i0010ZaKgw018kBQq; Tue, 17 Apr 2012 13:44:11 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=DT6a4BtRxdAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=X-lYJVElW5okdQY7UtUA:9 a=kkZ8QSdxDnf8I60D30AA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 13:43:53 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt Thread-Index: AQHNHFAzU6UbIC23j0+O47qTsnarm5afd6rA Date: Tue, 17 Apr 2012 20:43:53 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6B45@exch-mbx901.corp.cloudmark.com> References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> In-Reply-To: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334695451; bh=y0X/J/0wzEy87eeZqCuNJpBNH3CK3fO8vedJau7jPuw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=j/o459uSuzomTS3crg8wk+Nspb4H3l0fEyxDJeqrWa9BhwkpW53q4mcmky7xdMxV3 b2T08y8iyFlBb6K2YVgLvDEtKbZJ1Q35pFsR/9As1Aa3mxNkYSwuNe6U8hCcEF2PxI zKJY445GJsksytc6ukePG2MkeNyjgzf49QbSV0ro= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:43:58 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Monday, April 16, 2012 9:12 PM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt >=20 > 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. >=20 > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-03.txt > Pages : 10 > Date : 2012-04-16 > [...] To avoid ratholing on the whole "which is better" question, the document cu= rrently avoids any substantial comparison of the methods of the two protoco= ls. The exception is Section 3 of this version which spends the first two = paragraphs comparing the costs of evaluation, independent of their semantic= s. That text supports what is currently said in Section 4.1, bullet 6, whi= ch speculates as to one of the likely reasons of near-zero adoption of Send= er ID. On review, as currently written, this bit looks out-of-place along with the= rest of the document. That is, it doesn't matter (to this document) what = the two protocols do or how they do it; it matters that the overwhelming ma= jority appears to have decided which one is "standard". So should we remove it, or work to accommodate it? I think I'm inclined to= remove it, in line with Andrew's previous Saint-Exupery reference. -MSK From SRS0=2Y/xx=CX==stuart@gathman.org Tue Apr 17 14: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 7BDD711E80B5 for ; Tue, 17 Apr 2012 14: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnd3LnHd+89U for ; Tue, 17 Apr 2012 14:38:21 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id DCE9811E80AD for ; Tue, 17 Apr 2012 14:38:20 -0700 (PDT) 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 q3HLcIGQ022936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 17:38:19 -0400 Message-ID: <4F8DE2CA.1000005@gathman.org> Date: Tue, 17 Apr 2012 17:38:18 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> <4F8CA8FE.4010201@mail-abuse.org> In-Reply-To: <4F8CA8FE.4010201@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:38:43 -0000 Long ago, Nostradamus foresaw that on 04/16/2012 07:19 PM, Douglas Otis would write: > l'd instead use SMTP compliant anti-phishing strategies, such as those > found with DKIM, S/MIME, or OpenPGP. >> Actually, it seems to me that those who reject can be accused of >> breaking those SMTP features. To resolve the conflict we must devise >> a safe way of rejecting, such that servers can adhere to it with no >> risks. Our task is not to mandate it, but to enable it. > Agreed. For example, this could be done using something as simple as > incorporating the scope-ID used in RFC4406 to clarify... No SMTP features are broken unless a receiver rejects emails from their own "admin domain boundary" MTAs - which includes alias forwarders requested/authorized by the recipient. An alias forward which the (end user) recipient did not authorize or request (even informally) is a forgery, plain and simple, and should be rejected. It is a *limitation* of SPF that tracking said "boundary" MTAs can be difficult for public email providers (like gmail), which is why those public email providers tend not to reject on SPF fail (as they shouldn't). However, smaller email domains that *do* track which forwarders are authorized get a lot of mileage out of rejecting SPF fail. Statements like "SPF breaks forwarding" are made from the perspective of large public email providers, and are not strictly true - they are only true in practical sense and only if you happen to be a large public email provider (with a tiny percentage of email domains and large percentage of email traffic). From R.E.Sonneveld@sonnection.nl Tue Apr 17 15:11: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 2ED5611E80AD for ; Tue, 17 Apr 2012 15:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxrFFLHCODfx for ; Tue, 17 Apr 2012 15:11:24 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 875FB11E80A6 for ; Tue, 17 Apr 2012 15:11:21 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M2N005009MW3C00@helium.mailtransaction.com>; Wed, 18 Apr 2012 00:11:20 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M2N00N6Z9MWWP00@helium.mailtransaction.com>; Wed, 18 Apr 2012 00:11:20 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_QeNF/mt337kmqaOxXb23WA)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M2N00P0O9MV2900@lion.sonnection.nl> for spfbis@ietf.org; Wed, 18 Apr 2012 00:11:20 +0200 (CEST) Message-id: <4F8DEC38.4000005@sonnection.nl> Date: Wed, 18 Apr 2012 00:18:32 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: "Murray S. Kucherawy" References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280F6B45@exch-mbx901.corp.cloudmark.com> In-reply-to: <9452079D1A51524AA5749AD23E0039280F6B45@exch-mbx901.corp.cloudmark.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1334700680; bh=xFnNhL0r65F1L/Ze60j3nTzJgK+FYBfTEoy3REpt3mE=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=K/X7CjRV2jqe8GxRSMYhs5sqC9XzCVsU0UaqeC0NxR/VvMLkjMQTH6mBAj/UPhzU+ P/+Fx7wCDvEZKHyByY8HI1xpLG24We/eBLXK/Nv14xQNl92jxjFBSrQ03duBxWPi+K oBFeZGBblWV0oXTCf3px21wxoAZNXzhDxehrpsTw= X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0M2N005009MW3C00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 22:11:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_QeNF/mt337kmqaOxXb23WA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 4/17/12 10:43 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Monday, April 16, 2012 9:12 PM >> To: i-d-announce@ietf.org >> Cc: spfbis@ietf.org >> Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt >> >> 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 : Resolution of The SPF/Sender-ID Experiment >> Author(s) : Murray S. Kucherawy >> Filename : draft-ietf-spfbis-experiment-03.txt >> Pages : 10 >> Date : 2012-04-16 >> [...] > To avoid ratholing on the whole "which is better" question, the document currently avoids any substantial comparison of the methods of the two protocols. The exception is Section 3 of this version which spends the first two paragraphs comparing the costs of evaluation, independent of their semantics. That text supports what is currently said in Section 4.1, bullet 6, which speculates as to one of the likely reasons of near-zero adoption of Sender ID. > > On review, as currently written, this bit looks out-of-place along with the rest of the document. That is, it doesn't matter (to this document) what the two protocols do or how they do it; it matters that the overwhelming majority appears to have decided which one is "standard". > > So should we remove it, or work to accommodate it? I think I'm inclined to remove it, in line with Andrew's previous Saint-Exupery reference. Summarizing the differences between SPF and Sender-ID is OK. Leave in section 3, but rephrase it: s/ substantially// for both occurrences in the second paragraph of 3. Another aspect / difference between SPF and Sender-ID is that the post-DATA processing prevents the SMTP server from per-recipient SMTP responses. Most of the time _in the context of SPF/Sender-ID_ this will not be a problem, but suppose a recipient has a whitelist entry for example.com, where the SPF policy of example.com would instruct the server to reject the message, the user policy would be overruled by the system-level decision. I agree with you that bullet 6 of section 4.1 does not belong in the list of 'From the Evidence', as it merely poses a possible reason for the low adoption rate of Sender-ID, so I'd suggest to leave it out, or add it to section 3 with a text like: It is possible that the additional cost of having to accept and process the entire message rather than just a portion of its envelope is (part of) the reason of the low adoption rate of Sender-ID. /rolf --Boundary_(ID_QeNF/mt337kmqaOxXb23WA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 4/17/12 10:43 PM, Murray S. Kucherawy wrote: 
-----Original Message-----
From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Monday, April 16, 2012 9:12 PM
To: i-d-announce@ietf.org
Cc: spfbis@ietf.org
Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt

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           : Resolution of The SPF/Sender-ID Experiment
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-spfbis-experiment-03.txt
	Pages           : 10
	Date            : 2012-04-16
[...]

To avoid ratholing on the whole "which is better" question, the document currently avoids any substantial comparison of the methods of the two protocols.  The exception is Section 3 of this version which spends the first two paragraphs comparing the costs of evaluation, independent of their semantics.  That text supports what is currently said in Section 4.1, bullet 6, which speculates as to one of the likely reasons of near-zero adoption of Sender ID.

On review, as currently written, this bit looks out-of-place along with the rest of the document.  That is, it doesn't matter (to this document) what the two protocols do or how they do it; it matters that the overwhelming majority appears to have decided which one is "standard".

So should we remove it, or work to accommodate it?  I think I'm inclined to remove it, in line with Andrew's previous Saint-Exupery reference.

Summarizing the differences between SPF and Sender-ID is OK. Leave in section 3, but rephrase it: s/ substantially// for both occurrences in the second paragraph of 3.

Another aspect / difference between SPF and Sender-ID is that the post-DATA processing prevents the SMTP server from per-recipient SMTP responses. Most of the time _in the context of SPF/Sender-ID_ this will not be a problem, but suppose a recipient has a whitelist entry for example.com, where the SPF policy of example.com would instruct the server to reject the message, the user policy would be overruled by the system-level decision.

I agree with you that bullet 6 of section 4.1 does not belong in the list of 'From the Evidence', as it merely poses a possible reason for the low adoption rate of Sender-ID, so I'd suggest to leave it out, or add it to section 3 with a text like:

       It is possible that the additional cost of having to accept and
       process the entire message rather than just a portion of its
       envelope is (part of) the reason of the low adoption rate of Sender-ID.

/rolf

--Boundary_(ID_QeNF/mt337kmqaOxXb23WA)-- From hsantos@isdg.net Tue Apr 17 15:39: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 01C7A11E8086 for ; Tue, 17 Apr 2012 15:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4K8b-yAXkSW for ; Tue, 17 Apr 2012 15:39:18 -0700 (PDT) Received: from mail.santronics.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5145021F84C5 for ; Tue, 17 Apr 2012 15:39:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3645; t=1334702350; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=LZZJ60/6jYA10m4V/dbZ3KyMxvY=; b=YycxXfhYk8bXsVF1X7BG bfMNBSozD/vl/9B0scBEkWkTVs+S4r/w9DKdibB3p5N4LFDfB7YSPL7EmGzcBYsQ q2a8xLayyK4joi4kflFEZrKLI7qCD6SXbYXf8ag8wpF3g62ziqnRdYf7+mjmTccx 7GPRTD1xLbOG2LdSqsuzLxg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 18:39: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3609173085.29191.4992; Tue, 17 Apr 2012 18:39:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3645; t=1334702022; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=6mdWWo1 dPCbXg5bi2SALW4RdwZMMxHAfnTFYDksR4N0=; b=fvXBZjNlzxcIa/5lMoT0ZC8 YgFvt+6DFLJtCwogoeQGK4msTlL6oSZUkRof1cJqajXamEeVgS/uRK7VZlctefmu lV03yfPe9Sljgyxy0b/8/EytasLmllDtc7N5zIp21ghltRVJZbBYurH99e/PsbXi DHRKcravNfjSIgj8ddHs= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 17 Apr 2012 18:33:42 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4208077455.1859.5164; Tue, 17 Apr 2012 18:33:41 -0400 Message-ID: <4F8DF0CC.7090200@isdg.net> Date: Tue, 17 Apr 2012 18:38:04 -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: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> <4F8CA8FE.4010201@mail-abuse.org> <4F8DE2CA.1000005@gathman.org> In-Reply-To: <4F8DE2CA.1000005@gathman.org> 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] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 22:39:24 -0000 Stuart D Gathman wrote: > Douglas Otis would write: >> Agreed. For example, this could be done using something as simple as >> incorporating the scope-ID used in RFC4406 to clarify... > No SMTP features are broken unless a receiver rejects emails from their > own "admin domain boundary" MTAs - which includes alias forwarders > requested/authorized by the recipient. An alias forward which the (end > user) recipient did not authorize or request (even informally) is a > forgery, plain and simple, and should be rejected. It is a *limitation* > of SPF that tracking said "boundary" MTAs can be difficult for public > email providers (like gmail), which is why those public email providers > tend not to reject on SPF fail (as they shouldn't). However, smaller > email domains that *do* track which forwarders are authorized get a lot > of mileage out of rejecting SPF fail. > > Statements like "SPF breaks forwarding" are made from the perspective of > large public email providers, and are not strictly true - they are only > true in practical sense and only if you happen to be a large public > email provider (with a tiny percentage of email domains and large > percentage of email traffic). +1. People seem to forget the that majority of systems are the smaller sites and they are generally the targeted victims created by the operations of the smaller group of larger volume sites. Domains like yahoo.com, hotmail.com, earthlink.com, aol.com, msn.com, compuserv.com and others and now gmail.com are extremely highly abusive, spoofed domains and the rest of the larger group of smaller sites are the victims. I recall many years ago it was so bad, for a moment there we just just BLOCKED all these domains, unless it was an authenticated session and the user was allowed to use these domains as an author alias. It got so bad, vendors could no longer just pass the buck to the operators and the competitive advantage was now offering both system and user level mail filtering. So SPF and other ideas is not just about protected the the domain message, but also the RECEIVER system from ABUSE! For the first time ever, section 7.8 was added to 2821BIS (5321) recognizing the problem receivers were facing: 7.8. Resistance to Attacks In recent years, there has been an increase of attacks on SMTP servers, either in conjunction with attempts to discover addresses for sending unsolicited messages or simply to make the servers inaccessible to others (i.e., as an application-level denial of service attack). While the means of doing so are beyond the scope of this Standard, rational operational behavior requires that servers be permitted to detect such attacks and take action to defend themselves. For example, if a server determines that a large number of RCPT TO commands are being sent, most or all with invalid addresses, as part of such an attack, it would be reasonable for the server to close the connection after generating an appropriate number of 5yz (normally 550) replies. While I had recommended we needed the section recognizing pending payload based standards on the horizon, like DKIM/ADSP, the above statement "rational operational behavior" was sufficient for providing SMTP receivers the idea of having a IETF protocol technical "legal" authorization for discarding mail and not some flimsy concept of "local policy always rules." I guess because ADSP was still only a proposed standard, a normative reference could not be made for 2821BIS. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Tue Apr 17 15: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 8172011E80B1 for ; Tue, 17 Apr 2012 15:43:26 -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.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QATLi+bqlHa4 for ; Tue, 17 Apr 2012 15:43:22 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 782E921F8484 for ; Tue, 17 Apr 2012 15:43:22 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zAjM1i0010as01C01AjM4C; Tue, 17 Apr 2012 15:43:21 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=W866pGqk c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=DT6a4BtRxdAA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=A1X0JdhQAAAA:8 a=xItTy3eIP94xqSELYMIA:9 a=S7BzJwWhkLUkoI7AtLgA:7 a=CjuIK1q_8ugA:10 a=4rq7TwIXcRUA:10 a=lZB815dzVvQA:10 a=XTp-N5uPVyIILu7S:21 a=k9UK391dqeXWU5zv:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=ENQaWnk9ziRbizdWJ8sA:9 a=pvyhYEBlAN_fS43YfUUA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=JI6sUI89rnNAhbuW:21 a=ojfd8Fh_i8_SgD_2:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 15:43:21 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt Thread-Index: AQHNHFAzU6UbIC23j0+O47qTsnarm5afd6rAgACVGgD//5B1YA== Date: Tue, 17 Apr 2012 22:43:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6D40@exch-mbx901.corp.cloudmark.com> References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280F6B45@exch-mbx901.corp.cloudmark.com> <4F8DEC38.4000005@sonnection.nl> In-Reply-To: <4F8DEC38.4000005@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280F6D40exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334702602; bh=J8J27CAsEsqYl7PY3uBGKCE4ud54IfBhp2bE7z1sglQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=xFAhUYwS7qhIw6Fvxs2NZpzx2Ge0fYf6MEByQkAUCNyUkS5wwO9mrr/BK/o6G5HyG FYcCgf2WMsR+qrTzLJAv3rgv/Hg3M9tg7f5yOUAYDrhgMndx5QhWgQYYipHB68YGCZ QeISFmhNXPSeRL41emlpfFYl3R3QPLjzIaJeYwc8= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 22:43:26 -0000 --_000_9452079D1A51524AA5749AD23E0039280F6D40exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rolf, If we do decide we want to pontificate on the "why" in terms of adoption ch= oices people made, I would prefer to collect that information in an appendi= x and not in the "meat" of the document. Although it might be interesting = to revisit all of that, the question before us doesn't necessarily include = that analysis, and I think it only complicates the question quite a bit bec= ause we'd have to be sure somehow that we've covered everything. Instead, I think it suffices for us to demonstrate which one has wider adop= tion after six years. -MSK From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Rolf E. Sonneveld Sent: Tuesday, April 17, 2012 3:19 PM To: Murray S. Kucherawy Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt On 4/17/12 10:43 PM, Murray S. Kucherawy wrote: -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbi= s-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, April 16, 2012 9:12 PM To: i-d-announce@ietf.org Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt 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 : Resolution of The SPF/Sender-ID Experiment Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-03.txt Pages : 10 Date : 2012-04-16 [...] To avoid ratholing on the whole "which is better" question, the document cu= rrently avoids any substantial comparison of the methods of the two protoco= ls. The exception is Section 3 of this version which spends the first two = paragraphs comparing the costs of evaluation, independent of their semantic= s. That text supports what is currently said in Section 4.1, bullet 6, whi= ch speculates as to one of the likely reasons of near-zero adoption of Send= er ID. On review, as currently written, this bit looks out-of-place along with the= rest of the document. That is, it doesn't matter (to this document) what = the two protocols do or how they do it; it matters that the overwhelming ma= jority appears to have decided which one is "standard". So should we remove it, or work to accommodate it? I think I'm inclined to= remove it, in line with Andrew's previous Saint-Exupery reference. Summarizing the differences between SPF and Sender-ID is OK. Leave in secti= on 3, but rephrase it: s/ substantially// for both occurrences in the secon= d paragraph of 3. Another aspect / difference between SPF and Sender-ID is that the post-DATA= processing prevents the SMTP server from per-recipient SMTP responses. Mos= t of the time _in the context of SPF/Sender-ID_ this will not be a problem,= but suppose a recipient has a whitelist entry for example.com, where the S= PF policy of example.com would instruct the server to reject the message, t= he user policy would be overruled by the system-level decision. I agree with you that bullet 6 of section 4.1 does not belong in the list o= f 'From the Evidence', as it merely poses a possible reason for the low ado= ption rate of Sender-ID, so I'd suggest to leave it out, or add it to secti= on 3 with a text like: It is possible that the additional cost of having to accept and process the entire message rather than just a portion of its envelope is (part of) the reason of the low adoption rate of Sender-= ID. /rolf --_000_9452079D1A51524AA5749AD23E0039280F6D40exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rolf,

 <= /p>

If we do decide we want t= o pontificate on the “why” in terms of adoption choices people = made, I would prefer to collect that information in an appendix and not in the “meat” of the document.  Although it might be = interesting to revisit all of that, the question before us doesn’t ne= cessarily include that analysis, and I think it only complicates the questi= on quite a bit because we’d have to be sure somehow that we’ve covered everything. 

 <= /p>

Instead, I think it suffi= ces for us to demonstrate which one has wider adoption after six years.

 <= /p>

-MSK

 <= /p>

From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ie= tf.org] On Behalf Of Rolf E. Sonneveld
Sent: Tuesday, April 17, 2012 3:19 PM
To: Murray S. Kucherawy
Cc: spfbis@ietf.org
Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.tx= t

 

On 4/17/12 10:43 PM, Murray S. Kucherawy wrote: 

-----Original Message-----
From: spfbis-bounces@ietf.o=
rg [mailto:spfbis-bounces@ie=
tf.org] On Behalf Of intern=
et-drafts@ietf.org
Sent: Monday, April 16, 2012 9:12 PM
To: i-d-announce@ietf.org=

Cc: spfbis@ietf.org<=
/pre>

Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt=



 


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           : R=
esolution of The SPF/Sender-ID Experiment


 Author(s)       : Murray S. Kucherawy


 Filename        : draft-ietf-spfbi=
s-experiment-03.txt


 Pages           : 1=
0


 Date           =
; : 2012-04-16


[...]


 
To avoid ratholing on the whole "which is better" question, =
the document currently avoids any substantial comparison of the methods of =
the two protocols.  The exception is Section 3 of this version which s=
pends the first two paragraphs comparing the costs of evaluation, independe=
nt of their semantics.  That text supports what is currently said in S=
ection 4.1, bullet 6, which speculates as to one of the likely reasons of n=
ear-zero adoption of Sender ID.
 
On review, as currently written, this bit looks out-of-place along wit=
h the rest of the document.  That is, it doesn't matter (to this docum=
ent) what the two protocols do or how they do it; it matters that the overw=
helming majority appears to have decided which one is "standard".=

 
So should we remove it, or work to accommodate it?  I think I'm i=
nclined to remove it, in line with Andrew's previous Saint-Exupery referenc=
e.


Summarizing the differences between SPF and Sender-ID is OK. Leave in secti= on 3, but rephrase it: s/ substantially// for both occurrences in the secon= d paragraph of 3.

Another aspect / difference between SPF and Sender-ID is that the post-DATA= processing prevents the SMTP server from per-recipient SMTP responses. Mos= t of the time _in the context of SPF/Sender-ID_ this will not be a problem,= but suppose a recipient has a whitelist entry for example.com, where the SPF policy of example.com would instruct = the server to reject the message, the user policy would be overruled by the= system-level decision.

I agree with you that bullet 6 of section 4.1 does not belong in the list o= f 'From the Evidence', as it merely poses a possible reason for the low ado= ption rate of Sender-ID, so I'd suggest to leave it out, or add it to secti= on 3 with a text like:

       It is possible that the additiona=
l cost of having to accept and
       process the entire message rather=
 than just a portion of its
       envelope is (part of) the reason =
of the low adoption rate of Sender-ID.


/rolf

--_000_9452079D1A51524AA5749AD23E0039280F6D40exchmbx901corpclo_-- From dotis@mail-abuse.org Tue Apr 17 17:30: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 65C0A11E80E5 for ; Tue, 17 Apr 2012 17:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i7wQ5rXiTsS for ; Tue, 17 Apr 2012 17:30:28 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id CC83311E8086 for ; Tue, 17 Apr 2012 17:30:28 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 4468E1740087 for ; Wed, 18 Apr 2012 00:30:28 +0000 (UTC) Message-ID: <4F8E0B23.8060006@mail-abuse.org> Date: Tue, 17 Apr 2012 17:30:27 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> <4F8CA8FE.4010201@mail-abuse.org> <4F8DE2CA.1000005@gathman.org> In-Reply-To: <4F8DE2CA.1000005@gathman.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 00:30:29 -0000 On 4/17/12 2:38 PM, Stuart D Gathman wrote: > Long ago, Nostradamus foresaw that on 04/16/2012 07:19 PM, Douglas > Otis would write: >> l'd instead use SMTP compliant anti-phishing strategies, such as >> those found with DKIM, S/MIME, or OpenPGP. >>> Actually, it seems to me that those who reject can be accused of >>> breaking those SMTP features. To resolve the conflict we must devise >>> a safe way of rejecting, such that servers can adhere to it with no >>> risks. Our task is not to mandate it, but to enable it. >> Agreed. For example, this could be done using something as simple as >> incorporating the scope-ID used in RFC4406 to clarify... > No SMTP features are broken unless a receiver rejects emails from > their own "admin domain boundary" MTAs - which includes alias > forwarders requested/authorized by the recipient. An alias forward > which the (end user) recipient did not authorize or request (even > informally) is a forgery, plain and simple, and should be rejected. > It is a *limitation* of SPF that tracking said "boundary" MTAs can be > difficult for public email providers (like gmail), which is why those > public email providers tend not to reject on SPF fail (as they > shouldn't). However, smaller email domains that *do* track which > forwarders are authorized get a lot of mileage out of rejecting SPF fail. Dear Stuart, This describes ad hoc out-of-band signaling not practical for email exchange protocols. When users request email forwarding from Provider-X to Provider-Y, return-path/SPF rejection requires non-scalable arrangements to prevent loss of accepted email. Only when the EHLO identity fails, is there evidence of forgery. Loss of valid email is likely to prompt complaints for providers who reject email because return-paths referenced SPF records that can't possibly define "requested" forward-paths. Such rejections break SMTP since this disrupts what many consider an essential SMTP function. SRS had been the proposed solution never widely implemented, nor likely practical. > Statements like "SPF breaks forwarding" are made from the perspective > of large public email providers, and are not strictly true - they are > only true in practical sense and only if you happen to be a large > public email provider (with a tiny percentage of email domains and > large percentage of email traffic). Only SPF records referenced by EHLO provide source confirmations offering a suitable basis for acceptance or rejection. Regards, Douglas Otis From SRS0=DCK5i=CY==stuart@gathman.org Tue Apr 17 18: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 9FF5921F8570 for ; Tue, 17 Apr 2012 18:28:21 -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_47=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-mr5pBdhUyI for ; Tue, 17 Apr 2012 18:28: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 4550121F8573 for ; Tue, 17 Apr 2012 18:28:19 -0700 (PDT) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q3I1QZTt025914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 21:28:17 -0400 Message-ID: <4F8E184B.2030109@gathman.org> Date: Tue, 17 Apr 2012 21:26:35 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> In-Reply-To: <4F7DDB7C.9080605@tana.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 02:06:23 -0000 Long ago, Nostradamus foresaw that on 04/05/2012 01:50 PM, Alessandro Vesely would write: > On Thu 05/Apr/2012 19:26:19 +0200 Stuart D Gathman wrote: >> that on 04/04/2012 11:22 AM, Alessandro Vesely would write: >>>> c) the alias forwarding was *not* authorized by the sender or target. >>>> In this case, the "forwarder" is a forger and SHOULD be rejected. >>> False, this case includes legitimate forwarders. People who work in >>> an organization may sport an email address that reflects their >>> affiliation. Email facilities at that organization's site may include >>> the ability to set a forward address. Users may choose a different >>> mail site for its interface, its filtering, or whatever other reason. >>> It is not uncommon to have users forwarding to gmail, and from there >>> to yahoo, and possibly more. >> The situations you just described are *authorized* forwarding, so it >> is case b. > I don't see how. You described case (b) as: > > b) the alias forwarding was requested/authorized by the sender. > In this case, the sender screwed up by failing to include the > forwarder (who has now become a "border MTA" for the sender) in > their Sender Policy. > > I was talking about generic dot-forward files, whereby they forward > any message, irrespectively of the sender, to whatever external > addresses the users configured their forwarding recipe with. Sorry, I meant case a. >> I repeat, unauthorized forwarding is forgery and should be rejected. > They configure forwarding recipes through web forms. Nobody is going > to ask and obtain authorizations, and have SPF records updated. The authorization is informal, but it is authorized/requested. >> *If* a recipient wants to check SPF, then their implementation must >> take into account authorized forwarders as described in rfc4408 >> section 9, esp 9.5. A recipient authorized forwarder is a "border >> MTA" of the recipient. > Keeping in mind that relaying should be authorized on a per-user > basis, the only way to do that consistently, AFAICS, would be that > each organization maintains a user+forward whitelist of granted > authorizations. Records in such whitelists are inserted after a That is only if you wish to automate formal authorization *and* check SPF. > trusted request of forwarding, presumably performed by web2 means in > the server part of the web form that users configure forwarding with. > Then, the whitelists are referred from SPF records, using local macros > as appropriate. That is SMTP-fictional, IMHO. Yes, too much work at present, hence the correct thing to do, if you wish to allow informal forwarding is not reject on SPF. SPF has this limitation, but it does not "break forwarding" unless you do it wrong. From SRS0=DCK5i=CY==stuart@gathman.org Tue Apr 17 18:42: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 91A4321F8458 for ; Tue, 17 Apr 2012 18:42:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9zQnd3hbmdr for ; Tue, 17 Apr 2012 18:42:01 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 320B321F858D for ; Tue, 17 Apr 2012 18:42:01 -0700 (PDT) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q3I1fxjA026105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 21:42:00 -0400 Message-ID: <4F8E1BE7.3050604@gathman.org> Date: Tue, 17 Apr 2012 21:41:59 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <6040139.OxyMbgc6SQ@scott-latitude-e6320> <4F84D0CD.4090007@mail-abuse.org> <2183407.C4QXyJ5reZ@scott-latitude-e6320> <4F85BCD0.1040403@mail-abuse.org> <4F875085.1060702@isdg.net> <4F88BB70.3040307@mail-abuse.org> <4F88E302.2010203@isdg.net> <4F898D84.3050300@tana.it> <4F8CA8FE.4010201@mail-abuse.org> <4F8DE2CA.1000005@gathman.org> <4F8E0B23.8060006@mail-abuse.org> In-Reply-To: <4F8E0B23.8060006@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 02:06:39 -0000 Long ago, Nostradamus foresaw that on 04/17/2012 08:30 PM, Douglas Otis would write: > On 4/17/12 2:38 PM, Stuart D Gathman wrote: >> No SMTP features are broken unless a receiver rejects emails from >> their own "admin domain boundary" MTAs - which includes alias >> forwarders requested/authorized by the recipient. An alias forward >> which the (end user) recipient did not authorize or request (even >> informally) is a forgery, plain and simple, and should be rejected. >> It is a *limitation* of SPF that tracking said "boundary" MTAs can be >> difficult for public email providers (like gmail), which is why those >> public email providers tend not to reject on SPF fail (as they >> shouldn't). However, smaller email domains that *do* track which >> forwarders are authorized get a lot of mileage out of rejecting SPF >> fail. > Dear Stuart, > > This describes ad hoc out-of-band signaling not practical for email > exchange protocols. When users request email forwarding from > Provider-X to Provider-Y, return-path/SPF rejection requires > non-scalable arrangements to prevent loss of accepted email. Only > when the EHLO identity fails, is there evidence of forgery. Loss of > valid email is likely to prompt complaints for providers who reject > email because return-paths referenced SPF records that can't possibly > define "requested" forward-paths. Such rejections break SMTP since > this disrupts what many consider an essential SMTP function. SRS had > been the proposed solution never widely implemented, nor likely > practical. When I, as owner of the example.com domain, request (informally) that someotherdomain.org forward to my example.com mailbox, there is absolutely no problem for me, and the dozen or so other users of example.com, to add such authorized forwarders to our company list. If our company grows, as long as its policy is always "all authorized forwarders must be entered in the company authorized forwarder list or risk rejection", there is no scalability problem. It is only large public email providers, like gmail, which have a problem with alias forwarding, and it is easily solved by not rejecting on SPF fail. >> Statements like "SPF breaks forwarding" are made from the perspective >> of large public email providers, and are not strictly true - they are >> only true in practical sense and only if you happen to be a large >> public email provider (with a tiny percentage of email domains and >> large percentage of email traffic). > Only SPF records referenced by EHLO provide source confirmations > offering a suitable basis for acceptance or rejection. For gmail, perhaps - until they invent some magic way of divining likely authorized forwarders from their huge user base. For small domains like the ones I operate, you are wrong. SPF fail on MFROM *is* a suitable bases for rejection, because I (and the other users) have listed (and hence exempted) all authorized alias forwarders. I reject 10000s of forgeries daily that are sent to our tiny email domain. From spf2@kitterman.com Tue Apr 17 19:16: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 D795911E80D7 for ; Tue, 17 Apr 2012 19:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6DRTvB5PIno for ; Tue, 17 Apr 2012 19:16:48 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 302B711E807F for ; Tue, 17 Apr 2012 19:16:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5E48E20E40CC; Tue, 17 Apr 2012 22:16:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334715407; bh=C8yHCpZrRRS6oMS4AVq5QkNGMTb5Ex1JyDJHcVnz7eI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=hY5CqK18F4axPhIS1/jUTyGiOv4dE3vKcpcaMM2YcULVUyl+vwhXWvUwZXakk1Bg6 izEXwCkDQO3HKPOt7mw/oD3fY8px+SH/09qsZC+etpdB/knV3vtJkkYnyvXpqEY4Zj tJtesAHm4vJOjg2IASsInqIplyooAe08ZGhrXgKY= Received: from scott-latitude-e6320.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 ESMTPSA id 410DB20E4064; Tue, 17 Apr 2012 22:16:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Apr 2012 22:16:46 -0400 Message-ID: <30350164.Z6NJS3khFv@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8E1BE7.3050604@gathman.org> References: <20120324090349.15462.qmail@joyce.lan> <4F8E0B23.8060006@mail-abuse.org> <4F8E1BE7.3050604@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #12 again, was Meaning... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 02:16:53 -0000 On Tuesday, April 17, 2012 09:41:59 PM Stuart Gathman wrote: > For gmail, perhaps - until they invent some magic way of divining likely > authorized forwarders from their huge user base. FWIW, it appears they've done this. If you publish a DMARC record (dmarc.org) and examine the Gmail feedback, mail they believe was forwarded (relayed) is marked as such. Scott K From SRS0=DCK5i=CY==stuart@gathman.org Tue Apr 17 19:06: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 7303411E80D7 for ; Tue, 17 Apr 2012 19:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP5zhWZFmoET for ; Tue, 17 Apr 2012 19:06:01 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4211E8086 for ; Tue, 17 Apr 2012 19:06:00 -0700 (PDT) Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q3I25vTp026346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 22:05:57 -0400 Message-ID: <4F8E2185.2050003@gathman.org> Date: Tue, 17 Apr 2012 22:05:57 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 02:29:46 -0000 Long ago, Nostradamus foresaw that on 03/24/2012 12:52 AM, Murray S. Kucherawy would write: >> Forwarding is only broken when receivers >> confuse pseudo-SPF results from an alias forwarder with real SPF >> results, and then reject on FAIL. >> [...] > This an interesting tack, but I don't think I agree. SPF takes as input a domain name and an IP address, does some crunching, and returns a result. That result is deterministic. At the level of that interface, the IP address of a forwarder is indistinguishable from any other, so to say one class of IP address is valid while another is not seems a nonsequitur to me. Ok, so the SPF result is a real SPF result. But it is insane for a receiver to pay any attention to that SPF result when *they themselves* have requested the alias forward, and they *know* (or ought to know) from rfc4408 9.3 that the SPF result from such forwards are not useful (if you don't agree with my stronger term of "not valid"). The IP address of a forwarder *is* distinguishable to the recipient. The recipient requested the forward! Translating that to an IP set representing forwarders is especially easy when the forwarder publishes SPF (and the revised RFC ought to recommend this - it is not mentioned in rfc4408). Conceptually, apply the check() algorithm to each forwarder domain in your list (the domains will not appear in MFROM, of course) with the connect IP. All I'm saying is, don't check SPF, or at least don't reject on SPF for alias forwarders. This is an *easy* requirement for the vast majority of domains, which have a relatively small number of users. A Specific Request for 4408bis In section 9.3: 2. The middle, when E-Mail is forwarded. ... 3. Forwarder services SHOULD publish SPF for a domain representing their forwarding service, so that recipients can conveniently skip SPF checks for the forwarder, in a manner that automatically incorporates IP changes on forwarders MTAs (assuming they update their policy properly). From R.E.Sonneveld@sonnection.nl Wed Apr 18 00: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 BDA6D21F84B6 for ; Wed, 18 Apr 2012 00:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FcPxo5LhC79 for ; Wed, 18 Apr 2012 00:17:42 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 74AAB21F84B9 for ; Wed, 18 Apr 2012 00:17:41 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M2N00200YXGEE00@helium.mailtransaction.com>; Wed, 18 Apr 2012 09:17:40 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M2N00A0MYXGTZ00@helium.mailtransaction.com>; Wed, 18 Apr 2012 09:17:40 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NSmBYbCZaxBCO4Ype6SKdQ)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M2N00P2EYXG2900@lion.sonnection.nl> for spfbis@ietf.org; Wed, 18 Apr 2012 09:17:40 +0200 (CEST) Message-id: <4F8E6C45.6090300@sonnection.nl> Date: Wed, 18 Apr 2012 09:24:53 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: "Murray S. Kucherawy" References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280F6B45@exch-mbx901.corp.cloudmark.com> <4F8DEC38.4000005@sonnection.nl> <9452079D1A51524AA5749AD23E0039280F6D40@exch-mbx901.corp.cloudmark.com> In-reply-to: <9452079D1A51524AA5749AD23E0039280F6D40@exch-mbx901.corp.cloudmark.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1334733460; bh=uwTaGaJklBRkFqswPS9+aCY6u0e3N3UfYwB1B4Ye1bI=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=KFXeuHfwsQ6mol71RukVfX1+H6F65anjFqiyI1LCyfem3TY+7XZX0d7Ul0ZRT6EkK aD0KSAbOrqP//h/ypDVZ/O2f63u+dKKK2pZORTq0Yb8sHMpEaPiQOGDwhwuIdehB9I De8oOQz0eeYORB40E2WXINmKTjiMvLdcbbkeN4JQ= X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0M2N00200YXGEE00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:17:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NSmBYbCZaxBCO4Ype6SKdQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 4/18/12 12:43 AM, Murray S. Kucherawy wrote: > > Hi Rolf, > > If we do decide we want to pontificate on the "why" in terms of > adoption choices people made, I would prefer to collect that > information in an appendix and not in the "meat" of the document. > Although it might be interesting to revisit all of that, the question > before us doesn't necessarily include that analysis, and I think it > only complicates the question quite a bit because we'd have to be sure > somehow that we've covered everything. > > Instead, I think it suffices for us to demonstrate which one has wider > adoption after six years. > Agreed. /rolf --Boundary_(ID_NSmBYbCZaxBCO4Ype6SKdQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 4/18/12 12:43 AM, Murray S. Kucherawy wrote:

Hi Rolf,

 

If we do decide we want to pontificate on the “why” in terms of adoption choices people made, I would prefer to collect that information in an appendix and not in the “meat” of the document.  Although it might be interesting to revisit all of that, the question before us doesn’t necessarily include that analysis, and I think it only complicates the question quite a bit because we’d have to be sure somehow that we’ve covered everything. 

 

Instead, I think it suffices for us to demonstrate which one has wider adoption after six years.


Agreed.

/rolf
--Boundary_(ID_NSmBYbCZaxBCO4Ype6SKdQ)-- From R.E.Sonneveld@sonnection.nl Wed Apr 18 01:06: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 EE0B721F860B for ; Wed, 18 Apr 2012 01:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoeqdiwV0zdq for ; Wed, 18 Apr 2012 01:06:00 -0700 (PDT) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id AFF3B21F85E1 for ; Wed, 18 Apr 2012 01:05:59 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0M2O00D000JBTW00@hydrogen.mailtransaction.com>; Wed, 18 Apr 2012 10:05:58 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0M2O00FC815XDF00@hydrogen.mailtransaction.com>; Wed, 18 Apr 2012 10:05:58 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0M2O00P2N15X2900@lion.sonnection.nl> for spfbis@ietf.org; Wed, 18 Apr 2012 10:05:57 +0200 (CEST) Message-id: <4F8E7796.2080703@sonnection.nl> Date: Wed, 18 Apr 2012 10:13:10 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: Stuart Gathman References: <20120315175753.21172.qmail@joyce.lan> <6903649.1Kk6b2HWnu@scott-latitude-e6320> <4F6381C7.1050001@tana.it> <1961226.eMbsOy0Kc2@scott-latitude-e6320> <4F6C4903.8090901@tana.it> <42ddd9f6-d3b1-42a4-9135-80958505b379@email.android.com> <4F6CADDC.1000005@tana.it> <4F6CE6EC.1060501@gathman.org> <9452079D1A51524AA5749AD23E00392809958F@exch-mbx901.corp.cloudmark.com> <4F8E2185.2050003@gathman.org> In-reply-to: <4F8E2185.2050003@gathman.org> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1334736358; bh=bc9AkxWkIhkrix1mRwOzjJDFOnzG7c84BPOvSG4veyE=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=ApaqyVY/nV8EbFsf3CEtd+ZtsNGw/qA7Y8ycQZEz0jsXvecU/Czb15RIjpuGtZ4Wu G/ZQqnDbZBK2596G/1VCZaNSUA1fC/AWxvs/qetgdMuS3oRP+N+tTFDD7YnlcnNo0d LWiR+FX7QQpkYBZtGKJp/7DtNhBLQPq64LJOjJGc= X-DKIM: OpenDKIM Filter v2.4.3 hydrogen.mailtransaction.com 0M2O00D000JBTW00 Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:06:04 -0000 On 4/18/12 4:05 AM, Stuart Gathman wrote: [...] > Ok, so the SPF result is a real SPF result. But it is insane for a > receiver to pay any attention to that SPF result when *they themselves* > have requested the alias forward, and they *know* (or ought to know) > from rfc4408 9.3 that the SPF result from such forwards are not useful > (if you don't agree with my stronger term of "not valid"). This typically scales to a company size where all employees still fit in one room and the mail admin can yell: thou shalt always tell me thy forwardings. It simply doesn't scale to the size of the Internet. > The IP > address of a forwarder *is* distinguishable to the recipient. The > recipient requested the forward! Translating that to an IP set > representing forwarders is especially easy when the forwarder publishes > SPF (and the revised RFC ought to recommend this - it is not mentioned > in rfc4408). Conceptually, apply the check() algorithm to each > forwarder domain in your list (the domains will not appear in MFROM, of > course) with the connect IP. > > All I'm saying is, don't check SPF, or at least don't reject on SPF for > alias forwarders. This is an *easy* requirement for the vast majority > of domains, which have a relatively small number of users. So if someone sets a forwarder at Gmail or Hotmail, you would exempt all mail with RFC5321.MailFrom containing gmail.com and hotmail.com from SPF checking? > > A Specific Request for 4408bis > > In section 9.3: > > 2. The middle, when E-Mail is forwarded. > ... > 3. Forwarder services SHOULD publish SPF for a domain representing > their forwarding service, so that recipients can conveniently skip SPF > checks for the forwarder, in a manner that automatically incorporates IP > changes on forwarders MTAs (assuming they update their policy properly). And how are you supposed to know the domainnames of all forwarding services world wide, to be able to _skip_ SPF checks? And wouldn't that be an incentive for spammers to start abusing those domainnames for sending their spam to circumvent SPF checks? /rolf From vesely@tana.it Wed Apr 18 07:20: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 D16B721F85C6 for ; Wed, 18 Apr 2012 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeH8UhG1+zXK for ; Wed, 18 Apr 2012 07:20:35 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 398B521F858D for ; Wed, 18 Apr 2012 07:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334758832; bh=YvZSy+ouk7WsWAA5q82A1QLdRsnWK6vGtLqACTPFkDs=; l=1355; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=O61pr/EaVGRl1jriWaXmD72mJRWof7cb2ZpuNgGGp+LhdaI8/g2Tx6VgMRXIks0iQ a3bdT4fAsolVnROq5pp8GPB6m2e33UGhBkyotllBS9l+vaNMIwYPVgDRydbvgl2OtX LSpNw3HFi/RoXOgH1z+uZkbzBK9ltr8axMlFkY7w= Received: from [192.168.8.59] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Apr 2012 16:20:31 +0200 id 00000000005DC033.000000004F8ECDB0.00006EBA Message-ID: <4F8ECDAB.7010509@tana.it> Date: Wed, 18 Apr 2012 16:20:27 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F8E184B.2030109@gathman.org> In-Reply-To: <4F8E184B.2030109@gathman.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:20:40 -0000 On Wed 18/Apr/2012 16:00:13 +0200 Stuart Gathman wrote: > on 04/05/2012 01:50 PM, Alessandro Vesely would write: >> On Thu 05/Apr/2012 19:26:19 +0200 Stuart D Gathman wrote: > >>> I repeat, unauthorized forwarding is forgery and should be rejected. >> They configure forwarding recipes through web forms. Nobody is going >> to ask and obtain authorizations, and have SPF records updated. > The authorization is informal, but it is authorized/requested. I don't see that. Assume you're the owner of example.com. I'm a user of yours and also have a mailbox at someotherdomain.org. They let me enter a forwarding recipe from there to my mailbox at your domain. If they are clever, they check that I can get mail destined to that target address. When would they ask you, formally or not? >> That is SMTP-fictional, IMHO. > Yes, too much work at present, hence the correct thing to do, if you > wish to allow informal forwarding is not reject on SPF. I think that's the case that John characterized as a "growing niche". If we discard the proposed "helo-pass prevents rejection", the SMTP compatible alternative that we're left with is to prevent rejection altogether --that's what gmail does, btw. Isn't that an even more drastic change? > SPF has this limitation, but it does not "break forwarding" unless you > do it wrong. From vesely@tana.it Wed Apr 18 07:21: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 496E021F85CF for ; Wed, 18 Apr 2012 07:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCireTqbRvnf for ; Wed, 18 Apr 2012 07:21:15 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8404D21F85DD for ; Wed, 18 Apr 2012 07:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334758861; bh=f7H5gEfyGTLYm2sjiTPJWnHnqXFN8g9qF+5K+vLEISs=; l=1021; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QltQ0f6YZbVbYdiGYwuvpr/y9J+qQEr90uOWyq5xZb5vCwz+/f0woTg7b410CkAui dyI86ReS2SIh9s6iApD5ZW1hxaQAvJ5ORfNnUInZWob45+j8I0wpF3L1ZBeVQhrj6d QIDJPDfkA2JCWCO4Nh65hvTqv5P/j+egCWpgEdJw= Received: from [192.168.8.59] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Apr 2012 16:21:00 +0200 id 00000000005DC033.000000004F8ECDCC.00006EEC Message-ID: <4F8ECDC5.4040409@tana.it> Date: Wed, 18 Apr 2012 16:20:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280F448B@exch-mbx901.corp.cloudmark.com> <4F8DAA88.9000402@tana.it> <9452079D1A51524AA5749AD23E0039280F6ACD@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F6ACD@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:21:20 -0000 On Wed 18/Apr/2012 15:37:06 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> I'd like to run an extra test [...] > > My concern with this approach is that it's not accurate. A 5yz reply to > MAIL FROM isn't guaranteed to be caused by SPF because there isn't a > specific SMTP reply code or enhanced status code that guarantees the > rejection is caused by SPF. For all you know, a DNSBL could be the cause > of the error. Yeah, it won't bring any absolute certainty. It would contribute some facts, which might help getting item #12 slightly more on focus --I see that discussing doesn't seem to bring any change of opinion. > By contrast, the survey data currently represented in the experiment > document don't have the "maybe" sort of quality to them. Well, test data is test data. If one wanted to be picky, he could claim that "v=spf1" is equivalent to "spf2.0/mfrom,pra" but shorter, so that we are unable to conclude anything by surveying that data... From spf2@kitterman.com Wed Apr 18 07:30: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 78AFB21F85C9 for ; Wed, 18 Apr 2012 07:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmvJJ8oXsaB1 for ; Wed, 18 Apr 2012 07:30:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3921A21F8575 for ; Wed, 18 Apr 2012 07:30:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 66FED20E40CC; Wed, 18 Apr 2012 10:30:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334759408; bh=mNUnEZ+NZgDy70aqUVpMT8qXPBIjFs3UAejeWAF3GvQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=XkVigJ4Jr3C4NPrJRRouPqIJdhw3Ba0bynCaWgpVKJoSN8E/tKV/anH6lwIz2IY72 Sd02FcVHeKSC2FfHRLewlFgkqXEHoxen5MKjwGOsupxFTx3XXp496gtgHI7y5v817/ Y+wxSSKBF52R20LSDeTT8AlZWBS7pKOx5q7+R0aI= Received: from scott-latitude-e6320.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 ESMTPSA id 4B8B520E4099; Wed, 18 Apr 2012 10:30:08 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 10:30:07 -0400 Message-ID: <47685701.Z6iPPE2elv@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8ECDAB.7010509@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:30:13 -0000 On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: > If we discard the proposed "helo-pass prevents rejection", the SMTP > compatible alternative that we're left with is to prevent rejection > altogether --that's what gmail does, btw. Isn't that an even more drastic > change? It's not a change. RFC 4408 doesn't say reject or don't reject. What the receiver chooses is not part of the protocol, only the mechanism for the choice (which is why there is If reject then ... language). Scott K From dotzero@gmail.com Wed Apr 18 07:32: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 74C5B21F85E3 for ; Wed, 18 Apr 2012 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOC5gv6SvUFF for ; Wed, 18 Apr 2012 07:32:38 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id CC4FC21F85DB for ; Wed, 18 Apr 2012 07:32:38 -0700 (PDT) Received: by dady13 with SMTP id y13so13730348dad.27 for ; Wed, 18 Apr 2012 07:32:38 -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=PKrMAQ6o1UOVhD0gJA/5uIOBAAV7YF7XZqjxqmXMegw=; b=zY0x2YsZ2eyHnBssySZ/PWc+4jw8ROZ2WUA3XVngJSE9ua6+2m0t75RS6PcLwF9I10 tWYe/qan3ghgXg2UpNtVFPzTexss+kZxby1KyQhLvanszBQAVX2vupcI5hiHHgTvvph4 mla/15rvRzl/V2j3l1Vv+3jcPZTFDTlY+eL7gF6yk++XlbbfoGnrMQlfiNIgNga4BLDV bHSkbl/Wwa4WebuX1pR+TCdwtYivwVy+ezjXNfOW61b3ZHnC2aQDwlFqUWAoPg8x4Tjb Iok9MnbKeT8p4HJ8yEBMxkvTQ680I3FBLT7gnLNzPvFllHV/SKbzpnYxm2XHqc+YEnPB JIaQ== MIME-Version: 1.0 Received: by 10.68.72.70 with SMTP id b6mr6900528pbv.58.1334759558585; Wed, 18 Apr 2012 07:32:38 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Wed, 18 Apr 2012 07:32:38 -0700 (PDT) In-Reply-To: <47685701.Z6iPPE2elv@scott-latitude-e6320> References: <20120324090349.15462.qmail@joyce.lan> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> <47685701.Z6iPPE2elv@scott-latitude-e6320> Date: Wed, 18 Apr 2012 10:32:38 -0400 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:32:39 -0000 On Wed, Apr 18, 2012 at 10:30 AM, Scott Kitterman wrot= e: > On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: >> If we discard the proposed "helo-pass prevents rejection", the SMTP >> compatible alternative that we're left with is to prevent rejection >> altogether --that's what gmail does, btw. =A0Isn't that an even more dra= stic >> change? > > It's not a change. =A0RFC 4408 doesn't say reject or don't reject. =A0Wha= t the > receiver chooses is not part of the protocol, only the mechanism for the > choice (which is why there is If reject then ... language). > > Scott K > +1 - Too many people focus on reject as the only answer. As Scott points out, this is not what RFC4408 says. From johnl@iecc.com Wed Apr 18 07: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 72A3A21F85B4 for ; Wed, 18 Apr 2012 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.975 X-Spam-Level: X-Spam-Status: No, score=-110.975 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1jE-WWmeV2A for ; Wed, 18 Apr 2012 07:38:17 -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 5137E21F85A1 for ; Wed, 18 Apr 2012 07:38:16 -0700 (PDT) Received: (qmail 63593 invoked from network); 18 Apr 2012 14:38:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Apr 2012 14:38:13 -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=4f8ed1d5.xn--hew.k1204; i=johnl@user.iecc.com; bh=Ze1jEAoRIoKr7ebvlwb5BMAeoTNhSfyCgAgMJufuVWE=; b=gkyNUyXYnbnr9Lt8k71ijFwaJx/606jTdAFWGqgjn1ktq0s+spn6+wrh8gbkvmotGA/C2f9EdJ4gCfTbziNic43P1tsIn4aX+Cl+gejmSNyxdCxVge7mSXKN3Um/cc2FNgH0WC1fms0N4ls2nQEuTPBmxvFPyzqdAsppdyDfDCE= 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=4f8ed1d5.xn--hew.k1204; olt=johnl@user.iecc.com; bh=Ze1jEAoRIoKr7ebvlwb5BMAeoTNhSfyCgAgMJufuVWE=; b=kEKfkZyEHHK9sESg/9vF/geH9e8A7cGiS7U5omvHVqLzqg+53JaZwF5cR98S8+gaVy71Sdkhgbsx02Q/9Rq+wtqpRojmNXQyL7U05TfZ9348g6yfld+gCLhxewxSIU2vGM/qV19IQwhQ/lft6acYKPlwiJOC4smiUJBXxHxsQns= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Apr 2012 14:37:51 -0000 Message-ID: <20120418143751.6295.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F8E7796.2080703@sonnection.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: R.E.Sonneveld@sonnection.nl Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:38:22 -0000 >And how are you supposed to know the domainnames of all forwarding >services world wide, to be able to _skip_ SPF checks? And wouldn't that >be an incentive for spammers to start abusing those domainnames for >sending their spam to circumvent SPF checks? Of course. We've been through this a bazillion times already. Domains cannot publish assertions that say to accept mail you wouldn't otherwise accept, because bad guys will lie. SPF's path authentication is funamendally broken, because SMTP mail is designed to be delivered independent of the path it takes. It happens that a lot of mail is delivered via a predictable path, enough to make SPF useful, but for the stuff that's not, it's a limitation of SPF, not a fault of the mail system, and there is nothing to fix. R's, John From vesely@tana.it Wed Apr 18 08:05: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 C006821F85B7 for ; Wed, 18 Apr 2012 08:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtkuwSBk1AeM for ; Wed, 18 Apr 2012 08:05:41 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5AB21F85E3 for ; Wed, 18 Apr 2012 08:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334761539; bh=bPDuxm74o1O2/MNJIDTBTvK3dNYI5t9TAzxz4fHKl1A=; l=691; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OdKZPhFS9wr84tyjdBGkb7s9fgTB3NwiZZu/CatKHeYtSLTAb4uu2BXi8yq0iIeHw 8mQmv+wHYI3zPqlvSZoPngfchdUH1khNr7fHR6e9390C3YtKwrGNeLbiAggKn6l0ny 6Al4aq2zfVkxUZlTMIGpc6r/EJMQVKcPqE+5kIBA= Received: from [192.168.8.59] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Apr 2012 17:05:38 +0200 id 00000000005DC044.000000004F8ED843.00007A00 Message-ID: <4F8ED83D.3060908@tana.it> Date: Wed, 18 Apr 2012 17:05:33 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> <47685701.Z6iPPE2elv@scott-latitude-e6320> In-Reply-To: <47685701.Z6iPPE2elv@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:05:46 -0000 On Wed 18/Apr/2012 16:43:03 +0200 Scott Kitterman wrote: > On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: >> If we discard the proposed "helo-pass prevents rejection", the SMTP >> compatible alternative that we're left with is to prevent rejection >> altogether --that's what gmail does, btw. Isn't that an even more drastic >> change? > > It's not a change. RFC 4408 doesn't say reject or don't reject. What the > receiver chooses is not part of the protocol, only the mechanism for the > choice (which is why there is If reject then ... language). I'm not interested in wording at this stage. Let's consider the overall meaning of what we're going to say. From vesely@tana.it Wed Apr 18 08:14: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 EF55A21F85F2 for ; Wed, 18 Apr 2012 08:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vra+LO-CGNBO for ; Wed, 18 Apr 2012 08:14:30 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E221F85F4 for ; Wed, 18 Apr 2012 08:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334762069; bh=0BN9Hq2fDslI04KSjotjrdNnrZbvV+4ypqke9ctF9aY=; l=699; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=UK7UkebaMaINcTuOINlq/kAz+lFBoPWnlpuj5Sy3exGs+C64Sy+U7xEH9DKk7QlV3 Psu1YB0SWWtEhIA+/OlkQW/r+rb6ciqUZ539+rdQH6nDHwXZ3XFdywa1QF5kbzARl3 aezkrbWfeeAlsByKIp6UyBMll4yv16dWHcnkSvsw= Received: from [192.168.8.59] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Apr 2012 17:14:29 +0200 id 00000000005DC044.000000004F8EDA55.00007C93 Message-ID: <4F8EDA47.4070200@tana.it> Date: Wed, 18 Apr 2012 17:14:15 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120418143751.6295.qmail@joyce.lan> In-Reply-To: <20120418143751.6295.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:14:35 -0000 On Wed 18/Apr/2012 17:05:41 +0200 John Levine wrote: > > SPF's path authentication is fundamentally broken, because SMTP mail is > designed to be delivered independent of the path it takes. It happens > that a lot of mail is delivered via a predictable path, enough to make > SPF useful, but for the stuff that's not, it's a limitation of SPF, > not a fault of the mail system, and there is nothing to fix. Hm... IMHO the design of SMTP mail is fundamentally broken, as it provides for no path authentication. That way it puts billions of email users at the mercy of a fistful of spammers who exploit such inability to ascertain forwarding responsibilities. That's what we have to fix. From spf2@kitterman.com Wed Apr 18 08:24: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 0D96921F85F7 for ; Wed, 18 Apr 2012 08:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2cOGSE1OwoY for ; Wed, 18 Apr 2012 08:24:47 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4321F85B8 for ; Wed, 18 Apr 2012 08:24:47 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 25A3520E40CC; Wed, 18 Apr 2012 11:24:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334762687; bh=0M+baz29vUA0HgqMTNAiflLMfbpesAdBaf7N3SrHEuU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=DpAeSqTvR6nVv3yyU0UMvIIwgHz1fdS7U6U03fETfsqNwRcLb1I8wKMchO2V0nv0v OH2gphLhqIiXQBi8ebROulDQfrWTn5mcsTTrZ95fsBQH7pRE+NJecwmqZRqll5O9h7 FJWsf/UWoiWevGPG0KgDfebQiJda6QkvvvSuE9uY= Received: from scott-latitude-e6320.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 ESMTPSA id 0769820E4099; Wed, 18 Apr 2012 11:24:46 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 11:24:46 -0400 Message-ID: <1368066.mJbxKxkNYY@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8ED83D.3060908@tana.it> References: <20120324090349.15462.qmail@joyce.lan> <47685701.Z6iPPE2elv@scott-latitude-e6320> <4F8ED83D.3060908@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:24:52 -0000 On Wednesday, April 18, 2012 05:05:33 PM Alessandro Vesely wrote: > On Wed 18/Apr/2012 16:43:03 +0200 Scott Kitterman wrote: > > On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: > >> If we discard the proposed "helo-pass prevents rejection", the SMTP > >> compatible alternative that we're left with is to prevent rejection > >> altogether --that's what gmail does, btw. Isn't that an even more > >> drastic > >> change? > > > > It's not a change. RFC 4408 doesn't say reject or don't reject. What the > > receiver chooses is not part of the protocol, only the mechanism for the > > choice (which is why there is If reject then ... language). > > I'm not interested in wording at this stage. Let's consider the overall > meaning of what we're going to say. I propose we not say stuff about receiver policy that RFC 4408 doesn't say. Scott K From spf2@kitterman.com Wed Apr 18 08:25: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 82F4A21F8607 for ; Wed, 18 Apr 2012 08:25: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeSXvN7ZXSs8 for ; Wed, 18 Apr 2012 08:25:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 478F021F85F7 for ; Wed, 18 Apr 2012 08:25:39 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D734120E40CC; Wed, 18 Apr 2012 11:25:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334762738; bh=nTTseebx6jDbSwwtpgWkwjuxc/Sz60leJ5RuLHaLCzA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=FE5PQ8iYY6RsvURKt1CSrSN+JIeJA1kXexGIwi0Q8xO0opb8ZEXEmcIhd4hqa639f /VFaQDjcZ6IKnDBHpIfMSRXD+Ih12q0oTfqRMe1DpdhLBgmRJz4FtIT96TsULvZOJo 5wfAJPBiL+H/2g1fo8ztzOD8el+aJS9lY9M19GGo= Received: from scott-latitude-e6320.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 ESMTPSA id C9A4520E4099; Wed, 18 Apr 2012 11:25:38 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 11:25:38 -0400 Message-ID: <3148968.74XcyGxE7j@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8EDA47.4070200@tana.it> References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:25:43 -0000 On Wednesday, April 18, 2012 05:14:15 PM Alessandro Vesely wrote: > On Wed 18/Apr/2012 17:05:41 +0200 John Levine wrote: > > SPF's path authentication is fundamentally broken, because SMTP mail is > > designed to be delivered independent of the path it takes. It happens > > that a lot of mail is delivered via a predictable path, enough to make > > SPF useful, but for the stuff that's not, it's a limitation of SPF, > > not a fault of the mail system, and there is nothing to fix. > > Hm... IMHO the design of SMTP mail is fundamentally broken, as it provides > for no path authentication. That way it puts billions of email users at the > mercy of a fistful of spammers who exploit such inability to ascertain > forwarding responsibilities. That's what we have to fix. The version of we that has to fix that is not this working group. Scott K From ajs@anvilwalrusden.com Wed Apr 18 08:34: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 5623521F85B9 for ; Wed, 18 Apr 2012 08:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx5UlAV8qLGn for ; Wed, 18 Apr 2012 08:33:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CD90D21F85AF for ; Wed, 18 Apr 2012 08:33:59 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id E219A1ECB41D for ; Wed, 18 Apr 2012 15:33:58 +0000 (UTC) Date: Wed, 18 Apr 2012 11:33:57 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120418153255.GH94829@mail.yitter.info> References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8EDA47.4070200@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:34:00 -0000 Dear colleagues, On Wed, Apr 18, 2012 at 05:14:15PM +0200, Alessandro Vesely wrote: > Hm... IMHO the design of SMTP mail is fundamentally broken, as it provides > for no path authentication. This is not the SMTPBIS WG, and we are not going to "fix" that problem. The extent to which it would be nice if SMTP had a radically different design is simply out of scope for this WG, and any argument that leads to the conclusion "so we need to fix SMTP" is automatically, for our purposes, a _reductio ad absurdum_. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Wed Apr 18 09:10: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 7E53521F8533 for ; Wed, 18 Apr 2012 09:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob81MIpEzKTC for ; Wed, 18 Apr 2012 09:09:57 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6F21F85E4 for ; Wed, 18 Apr 2012 09:09:57 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zU9q1i0010as01C01U9qGa; Wed, 18 Apr 2012 09:09:50 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=pAR_0WjWX8EA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=rk9VPjoXcV0SRLEvgnYA:9 a=FLeHBQ90ElT3t2sREuAA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 09:09:49 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNHTon72mZfTRjDUKp+Reb9yDsYpahHI6AgAAKK4D//5l2oA== Date: Wed, 18 Apr 2012 16:09:49 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F7C31@exch-mbx901.corp.cloudmark.com> References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> In-Reply-To: <4F8EDA47.4070200@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334765390; bh=vbPA2gpLAi6ReXIDoI3jWQgHBvmAUHUdohEd36rbc2Y=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=uoeJLp0hn8z3h1AaXhxZt1ImETXzvMZHOgsnJFm0FC+8tNig3ZYPsQyr06atMgB9B ATowIu9WadwY4HdKMC54c87S2E6EUC9o3JZF7+15Dj48O22P7LZBal2JtbzcGDl9MN K3IppYN47wIfnZQd4BZjlNj3DMarsUdHq0yopQWg= Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:10:02 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Wednesday, April 18, 2012 8:14 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 > On Wed 18/Apr/2012 17:05:41 +0200 John Levine wrote: > > SPF's path authentication is fundamentally broken, because SMTP mail > > is designed to be delivered independent of the path it takes. It > > happens that a lot of mail is delivered via a predictable path, enough > > to make SPF useful, but for the stuff that's not, it's a limitation of > > SPF, not a fault of the mail system, and there is nothing to fix. >=20 > Hm... IMHO the design of SMTP mail is fundamentally broken, as it > provides for no path authentication. That way it puts billions of > email users at the mercy of a fistful of spammers who exploit such > inability to ascertain forwarding responsibilities. That's what we > have to fix. This is straying from the topic at hand. However, I disagree with the char= acterization of SMTP mail as "fundamentally broken" merely because it can b= e abused, unless you're also prepared to put that label on anything else th= at can be abused or spoofed. It's a pretty long list, and it includes IP, = ICMP, etc. From msk@cloudmark.com Wed Apr 18 09:11: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 DB83C21F85F7 for ; Wed, 18 Apr 2012 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv1r5AnsioP9 for ; Wed, 18 Apr 2012 09:11:13 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id DE59E21F85E3 for ; Wed, 18 Apr 2012 09:11:13 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zUBX1i0020as01C01UBXUJ; Wed, 18 Apr 2012 09:11:31 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=FZaKjXq_BXoA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 09:11:13 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNCnAQrevpLEddWEGgMhE/xgvzTZaKuN0AgACVPoCAAEPxAIABd7UAgBNbTYCAANg3gIAAArSAgAAJ5oCAAAVfAP//l30Q Date: Wed, 18 Apr 2012 16:11:12 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F7C4B@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <47685701.Z6iPPE2elv@scott-latitude-e6320> <4F8ED83D.3060908@tana.it> <1368066.mJbxKxkNYY@scott-latitude-e6320> In-Reply-To: <1368066.mJbxKxkNYY@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334765491; bh=slumTN+Bx8KZCMJMJIooPPcYeB6RD39WANzoPcFGe2Y=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=MYWBPvmEH1F/l44e50X7IF1pFM/LnoeCXDdHbXBV7cZUdYFgOrEuT72Ef82y0acvY Z8891wTK/Kl5uM2tll/nemf8MbSXZ3nB6ps4s+z/wHh72YJofNtWgea+C+f/5jAG0G ptI9TkFeHShwvr3y/QOl1gSrlYjUjBk5WjbiErYs= Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:11:18 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, April 18, 2012 8:25 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 > > > It's not a change. RFC 4408 doesn't say reject or don't reject. > > > What the receiver chooses is not part of the protocol, only the > > > mechanism for the choice (which is why there is If reject then ... la= nguage). > > > > I'm not interested in wording at this stage. Let's consider the > > overall meaning of what we're going to say. >=20 > I propose we not say stuff about receiver policy that RFC 4408 doesn't sa= y. +1. -MSK From vesely@tana.it Wed Apr 18 09:29: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 A8C4121F8570 for ; Wed, 18 Apr 2012 09:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id immjrm-XtWBo for ; Wed, 18 Apr 2012 09:29:27 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7EF11E8072 for ; Wed, 18 Apr 2012 09:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334766565; bh=HpWZG9yFzViiEs5i1q/PI6w8j36pi7yS8vQQ4zF7YiI=; l=1443; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Txyq69eyE7dGZU55gN+AH4sYIHuRN5+63sieNIc5BPaITG7sbRpDmel7G+rQiwduU fk2X6dOQyhQjB9L2Xcr4ZjEYY2DfDtfB1xKBoj3wQdFIQ9Dtqh1j2MBR0mYFkoyagB bJrzywh4JONyfrmbHI1ZZDVRSPltvwAgmMOD3iII= Received: from [192.168.8.59] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Apr 2012 18:29:20 +0200 id 00000000005DC039.000000004F8EEBE1.0000105C Message-ID: <4F8EEBD8.1090707@tana.it> Date: Wed, 18 Apr 2012 18:29:12 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> In-Reply-To: <20120418153255.GH94829@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:29:31 -0000 On Wed 18/Apr/2012 17:38:14 +0200 Andrew Sullivan wrote: > On Wed, Apr 18, 2012 at 05:14:15PM +0200, Alessandro Vesely wrote: > >> Hm... IMHO the design of SMTP mail is fundamentally broken, as it provides >> for no path authentication. > > This is not the SMTPBIS WG, and we are not going to "fix" that > problem. The extent to which it would be nice if SMTP had a radically > different design is simply out of scope for this WG, and any argument > that leads to the conclusion "so we need to fix SMTP" is > automatically, for our purposes, a _reductio ad absurdum_. Isn't SPF itself an attempt at fixing SMTP? It hijacks elements of the SMTP protocol and confers them a meaning that they didn't originally bear. John holds that it is broken for this very reason. If he is right, we should somehow state that SMTP servers must not reject on spf fail, possibly except for sites where the admin personally knows all mail users. Otherwise, we may indicate a safe way, if it exists, to perform rejection, possibly compelling forwarders to publish extra SPF records as needed. Please note that when I write "we should state" or "we may indicate", above, I don't mean any formal language. I'm confident we'll be able to word the document acceptably well according to what we think. I just want to know what we think. Isn't it possible to come to a consensus? Leaving things in a half-broken status isn't good for anyone. From msk@cloudmark.com Wed Apr 18 09:34: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 5884221F8581 for ; Wed, 18 Apr 2012 09:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc2uWhypG27c for ; Wed, 18 Apr 2012 09:34:29 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 57A7421F8572 for ; Wed, 18 Apr 2012 09:34:29 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zUaU1i0020ZaKgw01UaUQ6; Wed, 18 Apr 2012 09:34:28 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=pAR_0WjWX8EA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=YnHoJpW-u1ohhERJA7MA:9 a=FPywdcp3CpkywmWnZLAA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 09:34:28 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNHTon72mZfTRjDUKp+Reb9yDsYpahHI6AgAAKK4CAAAWBgIAAD3AA//+LonA= Date: Wed, 18 Apr 2012 16:34:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F7D20@exch-mbx901.corp.cloudmark.com> References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> <4F8EEBD8.1090707@tana.it> In-Reply-To: <4F8EEBD8.1090707@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334766868; bh=LvAm+JS8Wq61nYfV3s9EGs96MEgFnbG+UdgOtv4wmOY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=VcBxUmRbHBB6gvVtG7mBcrqHV77oQTyMAa8fUOYATXa8ieUMl1Qk8Vn0/JYqifZoA B50V40MQcY/4gzDObT/uw5DhvhNU0QVWhnmuFRpYbxaJsQeVBmToqSFoKUKBZTpyzK 9td/kBMrIVbGczgN757WX7JTJUS8T0/Ofp2lB5Rk= Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:34:33 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Wednesday, April 18, 2012 9:29 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 > Isn't SPF itself an attempt at fixing SMTP? It hijacks elements of the > SMTP protocol and confers them a meaning that they didn't originally > bear. Would you say as well that greylisting is an attempt at fixing SMTP? I see SPF and its ilk as layers on top of SMTP to provide additional servic= es, not attempts at fixing it. -MSK From spf2@kitterman.com Wed Apr 18 09: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 6EA8421F85AF for ; Wed, 18 Apr 2012 09:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMJLcrRdmFI3 for ; Wed, 18 Apr 2012 09:42:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 53C5421F84CD for ; Wed, 18 Apr 2012 09:42:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E105C20E40CC; Wed, 18 Apr 2012 12:42:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334767348; bh=fBHbDjJG7oRB/bOY2I/SVK3OO5EasxR7uQrGceuueSw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=FgshL3KIQYnpZ2w+FwRs0s3KE+xAnssPhMGm0axfN2ynD0oVTKKMdT2+odQEbHBGo bm4KpVkIULwvV00FvZp7ASg+34xGlgqg8iysX2u4MVN74ET90nPf4JdwrjJMnaCkJF S0eZCWbydopItgXF37cbfQ7xRUA9X+BrSFDc4Qjg= Received: from scott-latitude-e6320.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 ESMTPSA id D3F2820E4099; Wed, 18 Apr 2012 12:42:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 12:42:28 -0400 Message-ID: <2038097.WgLEvQz0hY@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:42:36 -0000 On Monday, April 16, 2012 09:11:38 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group of > the IETF. > > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-03.txt > Pages : 10 > Date : 2012-04-16 Comments: section 1 says in part: Because Sender-ID supported use of the same policy statement as SPF, the IESG at the time was concerned that an implementation of Sender-ID might erroneously apply that statement to a message and, depending on selected recipient actions, could improperly interfere with message delivery. I think this is close but not quite right. My proposal is replace "that statement" with "a statement intended for use only with SPF". section 2.2 says in part: o A web site [SID-IMPL] dedicated to highlighting Sender-ID implementations last updated in late 2007 listed 13 implementations, which we assume means they implement the PRA checks. At least one of them is known no longer to be supported by its vendor. I think it's worth noting that there are no FOSS SenderID implementations (that I know of). While I don't want to drag the document down the IPR rathole, it's an important enough part of the ecosystem that I think it's worth mentioning. My proposal is to add two new sentences between the current two: "All listed implementations are proprietary vendor implementations. There are no known Free Software/Open Source implementations." section 3 says in part: Another notable difference between the two is that the PRA part of Sender-ID cannot be determined without proceeding to the end of the DATA phase of an SMTP session, while SPF only requires the HELO/EHLO and MAIL FROM command parameters. Because MTAs historically consume substantially more resources for a transaction once past the MAIL FROM command in the SMTP sequence, this means SPF has a substantially lower cost to evaluate. Shouldn't this be after RCPT TO? I know that SPF cares about HELO/Mail From, but it's DATA that is generally expensive, not RCPT TO (in fact Postfix by default defers all pre-DATA checks to RCPT TO due to problems with other buggy MTAs if it didn't). Section 4.1.2.2 says: 2. Of the records retrieved, fewer than 5% requested processing of messages using the PRA algorithm, which was an integral part of Sender-ID. I would propose changing integral to essential. Without PRA, SenderID is SPF2.0/mfrom which is a subset of SPF. I think essential is correct and makes the point better. Section 4.1.2.6 says: 6. The overall lack of Sender-ID adoption likely has as a contributing factor the additional cost of having to accept and process the entire message rather than just a portion of its envelope. Is there data to support this or is this speculation? If it's speculation, I would remove it (personally, I think the lack of marginal benefit over SPF and the patent issues are more important - I don't propose we add that though). Section 4.2.3 says: 3. that the absence of significant adoption of the type 99 DNS resource record, the [SUBMITTER] extension, [SENDER-ID], and [PRA], indicates that they are de facto obsolete. I know this got a lot of discussion already. My proposal is, instead of "...are de facto obsolete" say "are not worthy of consideration for the Standards Track". This mirrors exactly the previous positive statement about SPF. I think it's sufficient for our purpose and will be less controversial. Appendix A, first paragraph says: SPF was originally developed by a community of interested developers outside the IETF. It was brought to the IETF for standardization only after the specification was relatively mature and ready for the rigors of the IETF publication process. Please add to start of the second sentence, "As intended from the start of the project, ...". The current wording makes it sound to me like coming to the IETF was a late revelation. It was the plan from the beginning (as evidence, the SPF spec from very early in the project were published in the format of Internet Drafts). The second paragraph mentions a working group. RFC 4408 was an individual submission. There was no working group, so that should be reworded. Also in that paragraph "... who encouraged doing so as the preferred path toward using the DNS for storing such things as policy data" would be more accurately put "... who threatened to block publication of the document unless it contained a dedicated RR type, even though there was no transition strategy". I'll leave it to the author to determine if the current text is just a polite version of that or if the text needs changing. Finally, the word perceived ("was perceived to have high barriers to entry") bothers me. Yes. It was perceived to have high barriers to entry, but that was because it did. The perception was correct, so I'd rather just say that. Once again in Section A.1: 1. there was hesitation to make the transition because of concerns that nameservers (and, in fact, DNS-aware firewalls) would drop or reject requests for unknown RR types (see Section 2 for evidence of this), which means successful rollout of a new RR type is contingent upon widespread adoption of updated nameservers and resolver functions; It wasn't just concerns. There were real problems (and still are). At least fix this one. Please change by removing "of concerns that". These two parts as written make it sound like we were wringing our hands over nothing. It was a huge problem then and it's still a problem now. I think we're pretty close. Scott K From vesely@tana.it Wed Apr 18 09:42: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 EBE7321F84E6 for ; Wed, 18 Apr 2012 09:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXLJb6vXdgBx for ; Wed, 18 Apr 2012 09:42:53 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC2721F8498 for ; Wed, 18 Apr 2012 09:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334767372; bh=wWpXzSJv994o6MAbU3y4H7DmCIXodgSQBQz9TCRL6B8=; l=607; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=R4WfnyBkrRay5mp05bgqL6zF7G4jZ9c6RxASRBlFAgj8nfg545bLJ6CBS3lqwfxIx k1vfGioj1eqazjAuev/y4OfMEuJXC8c9eLw25kVAYsFZy8t0505QOpQJzzbRR45/O1 GQNpiG+H1+tylySqjcBAH/o2auYqMFxak2WYDVxU= Received: from [192.168.8.59] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Apr 2012 18:42:50 +0200 id 00000000005DC035.000000004F8EEF0A.000013A9 Message-ID: <4F8EEEFD.2000609@tana.it> Date: Wed, 18 Apr 2012 18:42:37 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> <4F8EEBD8.1090707@tana.it> <9452079D1A51524AA5749AD23E0039280F7D20@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F7D20@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:42:58 -0000 On Wed 18/Apr/2012 18:38:46 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> Isn't SPF itself an attempt at fixing SMTP? It hijacks elements of the >> SMTP protocol and confers them a meaning that they didn't originally >> bear. > > Would you say as well that greylisting is an attempt at fixing SMTP? Yes, albeit less invasive. > I see SPF and its ilk as layers on top of SMTP to provide additional > services, not attempts at fixing it. That's a more polite way to convey the same meaning, if you consider the nature of the service being provided. From msk@cloudmark.com Wed Apr 18 09:49: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 6BCB921F858E for ; Wed, 18 Apr 2012 09:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG70hvjwRtfq for ; Wed, 18 Apr 2012 09:48:58 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 792AA21F858A for ; Wed, 18 Apr 2012 09:48:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zUpF1i0010as01C01UpFi4; Wed, 18 Apr 2012 09:49:15 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=FZaKjXq_BXoA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=50iIAqEmVodLuLgrx9kA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 09:48:57 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNHYJRmEbgWgCP/kyEo83QWd3qIJagydbw Date: Wed, 18 Apr 2012 16:48:56 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F8181@exch-mbx901.corp.cloudmark.com> References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> <4F8EEBD8.1090707@tana.it> <9452079D1A51524AA5749AD23E0039280F7D20@exch-mbx901.corp.cloudmark.com> <4F8EEEFD.2000609@tana.it> In-Reply-To: <4F8EEEFD.2000609@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334767755; bh=5F5FCk9j7iuxjcXIhFaSi+3Xbsz2OR0VAhiHrSH0zoQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=da33KfLN9Fb2ALMQbEqM6Y/G+xcxTS5asF9YX7+DgLER/v1UXfDfuOP45W8/8x2Ex sNbsZYLWq7Uw0V3fn3aPOcgpOo4FEiN9sKuyISaHf8HLr/cNTnrGI8dkwcQw+9wGba Mk/lqWuBilj6ns+6NGp8e3aCqCJoWNBT5F2bGJ6Y= Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:49:02 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Wednesday, April 18, 2012 9:43 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 > > I see SPF and its ilk as layers on top of SMTP to provide additional > > services, not attempts at fixing it. >=20 > That's a more polite way to convey the same meaning, if you consider > the nature of the service being provided. The difference is that your view is that SMTP is broken; mine is that SMTP = works as designed without it, but has some added protection with it, and th= e consumer gets to decide which of the two modes is desirable. I'll let those more seasoned in protocol and email history take it from the= re if more information is needed. -MSK From ajs@anvilwalrusden.com Wed Apr 18 09:51: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 7EE3121F8593 for ; Wed, 18 Apr 2012 09:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzOoh46mrBA4 for ; Wed, 18 Apr 2012 09:51:14 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DB68721F858E for ; Wed, 18 Apr 2012 09:51:13 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 37EBA1ECB41D for ; Wed, 18 Apr 2012 16:51:13 +0000 (UTC) Date: Wed, 18 Apr 2012 12:51:11 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120418165111.GM94829@mail.yitter.info> References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> <4F8EEBD8.1090707@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8EEBD8.1090707@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:51:14 -0000 No hat. On Wed, Apr 18, 2012 at 06:29:12PM +0200, Alessandro Vesely wrote: > Isn't SPF itself an attempt at fixing SMTP? It hijacks elements of the SMTP > protocol and confers them a meaning that they didn't originally > bear. No. SPF is an attempt to express something about how receivers might want to treat a messge received using SMTP. The Internet works in layers, and SPF sits atop SMTP. I will cheerfully grant that it is perched there somewhat precariously, partly because it attempts to make assertions that are sometimes false. But it is not itself altering SMTP. There is an important difference between those two ways of looking at things, and I want to attend to that difference. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From SRS0=DCK5i=CY==stuart@gathman.org Wed Apr 18 09:54: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 2897D21F85B7 for ; Wed, 18 Apr 2012 09:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zczvT5ZptAm for ; Wed, 18 Apr 2012 09:54:29 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 11B1C21F8593 for ; Wed, 18 Apr 2012 09:54:28 -0700 (PDT) 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 q3IGsR6V005641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Apr 2012 12:54:27 -0400 Message-ID: <4F8EF1C3.3060906@gathman.org> Date: Wed, 18 Apr 2012 12:54:27 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> In-Reply-To: <4F8ECDAB.7010509@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:54:36 -0000 Long ago, Nostradamus foresaw that on 04/18/2012 10:20 AM, Alessandro Vesely would write: > > I repeat, unauthorized forwarding is forgery and should be rejected. >>> They configure forwarding recipes through web forms. Nobody is going >>> to ask and obtain authorizations, and have SPF records updated. >> The authorization is informal, but it is authorized/requested. > I don't see that. Assume you're the owner of example.com. I'm a user of > yours and also have a mailbox at someotherdomain.org. They let me enter a > forwarding recipe from there to my mailbox at your domain. If they are > clever, they check that I can get mail destined to that target address. > When would they ask you, formally or not? If you expect to get your mail addressed to someotherdomain.org at your example.com mailbox (which I run in your example), *you* need to tell me so I can add someotherdomain.org to the authorized forwarder list (or you can do it yourself - as a small domain, I gave you and other users access to tools to do so should you be interested). If someotherdomain.org publishes an SPF record, that is the end of the story (unless they relay a lot of spam and I have to block them). If they don't publish an SPF record, I have to put my mail admin hat on and go over logs to figure out a reasonable local SPF record (i.e. not an official SPF record, but one my mail servers use for that domain) that covers IPs someotherdomain.org sends from. For an alias forwarder, that usually ends up being something like "v=spf1 ptr:someotherdomain.org -all". On the other hand, if somejerkdomain.org decides to start alias forwarding some random mailbox "for your convenience" that you have no knowledge of, that is *forgery*, and will get rejected (and the IP banned if persistent) for any domain I administer if the sender published an SPF record with -all (which thankfully for banks and credit card companies, they generally do). From WebMaster@Commerco.Net Wed Apr 18 10:06: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 B737011E8072 for ; Wed, 18 Apr 2012 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxCxa4DmWUtS for ; Wed, 18 Apr 2012 10:06:24 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6D01111E8083 for ; Wed, 18 Apr 2012 10:06:24 -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=ITRqjvMIA7GJs0Aq+4mkPw67CHdCx3pxwbtBxBv11dyriyxSATIBzevkGmasYj0d8A0yR8BnJs7bdoVmVCD+BUU4NZJHD9gs1IDC77rQ86eKZCPbRXn3++AtvSnCPqkCGSPivcpqIwtpPpR0ZSNtWXK8bL83HvQMxg/fvqXQ5i0= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Wed, 18 Apr 2012 17:06:20 +0000 Message-ID: <4F8EF485.3010102@Commerco.Net> Date: Wed, 18 Apr 2012 11:06:13 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> <4F8EEBD8.1090707@tana.it> In-Reply-To: <4F8EEBD8.1090707@tana.it> 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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 17:06:28 -0000 On 4/18/2012 10:29 AM, Alessandro Vesely wrote: > On Wed 18/Apr/2012 17:38:14 +0200 Andrew Sullivan wrote: >> On Wed, Apr 18, 2012 at 05:14:15PM +0200, Alessandro Vesely wrote: >> >>> Hm... IMHO the design of SMTP mail is fundamentally broken, as it provides >>> for no path authentication. >> >> This is not the SMTPBIS WG, and we are not going to "fix" that >> problem. The extent to which it would be nice if SMTP had a radically >> different design is simply out of scope for this WG, and any argument >> that leads to the conclusion "so we need to fix SMTP" is >> automatically, for our purposes, a _reductio ad absurdum_. > > Isn't SPF itself an attempt at fixing SMTP? It hijacks elements of the SMTP In a sense, yes, though at least from the perspective of an implementer, the true value of SPF seems mostly linked to its primary reason for being. That is, a mechanism to reasonably authoritatively tie domain names to specific outbound email servers, such that the overall integrity of the domain name's reputation can be preserved and so that others cannot misuse these domain names in spam email. So in that spirit, it is sort of a wrapper to the way SMTP works, so more of an upgrade than a fix per se. I think, kind of along the lines of what Murray was talking to in his point about greylisting. We have had a lot of activity on this list over the past day or so which seems to exceed the WG charter scope. Many of the things said appear as simply truisms which cannot be fixed in SPFbis. I tend to agree with John Levine's statements which I interpret as indicating a desire to move on past some of the things we cannot address here, even though they may well be interesting to the technical minds here. Best, Alan M. From hsantos@isdg.net Wed Apr 18 10:16: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 1959B11E8081 for ; Wed, 18 Apr 2012 10:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsmGiMNIk2OZ for ; Wed, 18 Apr 2012 10:16:47 -0700 (PDT) Received: from mail.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BEB1621F854D for ; Wed, 18 Apr 2012 10:16:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2418; t=1334769396; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=GsJ+8N+ppAQM+G4R/wGeBIKev7Y=; b=RbPeDlZTpuzd4VxGxdMP tjXg+/Q5Dye9NntVbC/Y0lJtW0cra8MbOi8+Luj2bVDlfOlN+G7ZRzzFMjbR+E74 fJ+/vKhT4FOCZbwA2Yhx0nyD+K0SPKyHjB1elhZ3CvxQ6zb0RaYs64QrMzb9Lr5I LcvdJlQ3aVYTI/V2HYQyAq0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 13:16: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3676218680.30007.5612; Wed, 18 Apr 2012 13:16:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2418; t=1334769063; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=eH8lnWq p0SzYfbBFmpVIgjTykm2GcSmjMiR3EMSaC1g=; b=bwcoxzcRz/r4s0kfzOxLR/w 0dIMUwsKBdjA3OWeiOkbSDs7qoOZh73rpxH22ViQ6ZZdETp2wTruZEtQKoDN9CtY vrizEHqAK+ktjRs0JYwmAKw4myDaenvvh8r3vg1GjcMdFQ47urUB6JSEHXJB9css iPKtADsPFOlXr+H9xtuA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 13:11:03 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4275118612.2029.4844; Wed, 18 Apr 2012 13:11:02 -0400 Message-ID: <4F8EF6CF.5010907@isdg.net> Date: Wed, 18 Apr 2012 13:15:59 -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: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> In-Reply-To: <4F8EDA47.4070200@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 17:16:52 -0000 Hi, SMTP is not "broken" - it has relaxed provisions by design. It has all the requirements and expectations for validity, but it is relaxed enforcement. You can see the mindset here, with 2821: 7.1 Mail Security and Spoofing .. This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail. With 5321, what changed is that the user is no longer ignorant! :) The first thing to fix is this mindset! There are strong forces to ACCEPT all mail and let the user decide and passing the buck to the user is seriously abused and dangerous. More system level filtering is required and SPF helps in that areas. Its a domain policy, not a domain user policy. For SPF, honor the domain policy for -ALL. Its means bad mail - get rid of it! Regardless if you don't believe the domain meant it, that is what the RULES is. -ALL means REJECT. Instead what we see? More relaxed provisions and we wonder whether "anything" can work without abuse, but we do our best to make sure its abused? Also, gmail.com is not a MODEL for everyone to use. Not everyone is a ESP, plus google has more interest and seeing and accepting ALL traffic - good or bad for its form of BI (Business Intelligence) data warehousing. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com Alessandro Vesely wrote: > On Wed 18/Apr/2012 17:05:41 +0200 John Levine wrote: >> SPF's path authentication is fundamentally broken, because SMTP mail is >> designed to be delivered independent of the path it takes. It happens >> that a lot of mail is delivered via a predictable path, enough to make >> SPF useful, but for the stuff that's not, it's a limitation of SPF, >> not a fault of the mail system, and there is nothing to fix. > > Hm... IMHO the design of SMTP mail is fundamentally broken, as it provides > for no path authentication. That way it puts billions of email users at the > mercy of a fistful of spammers who exploit such inability to ascertain > forwarding responsibilities. That's what we have to fix. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From msk@cloudmark.com Wed Apr 18 10:31: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 9164411E8081 for ; Wed, 18 Apr 2012 10:31:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FoLhuVHSKZT for ; Wed, 18 Apr 2012 10:31:44 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1C11E8074 for ; Wed, 18 Apr 2012 10:31:44 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zVY11i0020as01C01VY13M; Wed, 18 Apr 2012 10:32:01 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=DT6a4BtRxdAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=VAN6WsZI-BVcTGLbWQ8A:9 a=e0kDQDUaP3RO1GTK-8oA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 10:31:43 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt Thread-Index: AQHNHFAzU6UbIC23j0+O47qTsnarm5ahQTMA//+PWtA= Date: Wed, 18 Apr 2012 17:31:42 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F8267@exch-mbx901.corp.cloudmark.com> References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> <2038097.WgLEvQz0hY@scott-latitude-e6320> In-Reply-To: <2038097.WgLEvQz0hY@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334770321; bh=8S+jjU70XaOWO71NztRa8BHg98T7or5yNYZkrsJhScc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=V6oG0szx14+m/KeTBX2FJwmlfxFti1y3ioHvk8lej3EVLkpQz5pCAVc0BMKWYginU dUqo4Rc+Bf6b+F3TBhIhNBPPMbVBUpAID6qy5z3EckJ/vSR9eDQP2Ab5yvCTBrr6oL 5o8aq8iDHB61Z/FbQGGvXYmnX7bPGLw3zfC0kLbU= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 17:31:48 -0000 Thanks for the review, Scott. > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, April 18, 2012 9:42 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt >=20 > section 1 says in part: >=20 > Because Sender-ID supported use of the same policy statement as SPF, > the IESG at the time was concerned that an implementation of > Sender-ID might erroneously apply that statement to a message and, > depending on selected recipient actions, could improperly interfere > with message delivery. >=20 > I think this is close but not quite right. My proposal is replace > "that statement" with "a statement intended for use only with SPF". Is that an important distinction to make? That is, given the goal of this = document is merely to indicate which protocol got more adoption, making thi= s point doesn't advance that goal. > section 2.2 says in part: >=20 > o A web site [SID-IMPL] dedicated to highlighting Sender-ID > implementations last updated in late 2007 listed 13 > implementations, which we assume means they implement the PRA > checks. At least one of them is known no longer to be supported > by its vendor. >=20 > I think it's worth noting that there are no FOSS SenderID > implementations (that I know of). While I don't want to drag the > document down the IPR rathole, it's an important enough part of the > ecosystem that I think it's worth mentioning. I agree that this is worth pointing out, especially without mentioning the = "why". People can do their own investigation on that point if desired. > My proposal is to add two new sentences between the current two: >=20 > "All listed implementations are proprietary vendor implementations. > There are no known Free Software/Open Source implementations." I've added a slight variant of this, and also mentioned that the [OPENSPF] = reference included a mix of the two. > section 3 says in part: >=20 > Another notable difference between the two is that the PRA part of > Sender-ID cannot be determined without proceeding to the end of the > DATA phase of an SMTP session, while SPF only requires the HELO/EHLO > and MAIL FROM command parameters. Because MTAs historically consume > substantially more resources for a transaction once past the MAIL > FROM command in the SMTP sequence, this means SPF has a substantially > lower cost to evaluate. >=20 > Shouldn't this be after RCPT TO? I know that SPF cares about HELO/Mail > From, but it's DATA that is generally expensive, not RCPT TO (in fact > Postfix by default defers all pre-DATA checks to RCPT TO due to > problems with other buggy MTAs if it didn't). I struck the paragragh. It speculates about why the results are what they = are, rather than merely presenting results. > Section 4.1.2.2 says: >=20 > 2. Of the records retrieved, fewer than 5% requested processing of > messages using the PRA algorithm, which was an integral part of > Sender-ID. >=20 > I would propose changing integral to essential. Without PRA, SenderID > is SPF2.0/mfrom which is a subset of SPF. I think essential is correct > and makes the point better. Done. > Section 4.1.2.6 says: >=20 > 6. The overall lack of Sender-ID adoption likely has as a > contributing factor the additional cost of having to accept and > process the entire message rather than just a portion of its > envelope. >=20 > Is there data to support this or is this speculation? If it's > speculation, I would remove it (personally, I think the lack of > marginal benefit over SPF and the patent issues are more important - I > don't propose we add that though). Nope; also struck this one. > Section 4.2.3 says: >=20 > 3. that the absence of significant adoption of the type 99 DNS > resource record, the [SUBMITTER] extension, [SENDER-ID], and > [PRA], indicates that they are de facto obsolete. >=20 > I know this got a lot of discussion already. My proposal is, instead > of "...are de facto obsolete" say "are not worthy of consideration for > the Standards Track". This mirrors exactly the previous positive > statement about SPF. I think it's sufficient for our purpose and will > be less controversial. I actually prefer the current wording, because it is precisely correct. Th= e word "worthy" is a little bit subjective. But, of course, I'm happy to d= efer to consensus. > Appendix A, first paragraph says: >=20 > SPF was originally developed by a community of interested developers > outside the IETF. It was brought to the IETF for standardization > only after the specification was relatively mature and ready for the > rigors of the IETF publication process. >=20 > Please add to start of the second sentence, "As intended from the start > of the project, ...". The current wording makes it sound to me like > coming to the IETF was a late revelation. It was the plan from the > beginning (as evidence, the SPF spec from very early in the project > were published in the format of Internet Drafts). I've reworked it slightly to include your point. > The second paragraph mentions a working group. RFC 4408 was an > individual submission. There was no working group, so that should be > reworded. Fixed; there was a WG, but its charter was to pick a proposal and advance i= t, which it never did. Clarified to indicate such. > Also in > that paragraph "... who encouraged doing so as the preferred path > toward using > the DNS for storing such things as policy data" would be more > accurately put "... who threatened to block publication of the document > unless it contained a dedicated RR type, even though there was no > transition strategy". I'll leave it to the author to determine if the > current text is just a polite version of that or if the text needs > changing. I'll do some worsdmithing that part of the appendix to cover this better. = I think this needs to relay relevant history, but without sounding too frus= trated. > Finally, the word perceived ("was perceived to have high > barriers to entry") bothers me. Yes. It was perceived to have high > barriers to entry, but that was because it did. The perception was > correct, so I'd rather just say that. Fixed. > Once again in Section A.1: >=20 > 1. there was hesitation to make the transition because of concerns > that nameservers (and, in fact, DNS-aware firewalls) would drop > or reject requests for unknown RR types (see Section 2 for > evidence of this), which means successful rollout of a new RR > type is contingent upon widespread adoption of updated > nameservers and resolver functions; >=20 > It wasn't just concerns. There were real problems (and still are). At > least fix this one. Please change by removing "of concerns that". Fixed. Thanks again, -MSK From hsantos@isdg.net Wed Apr 18 10:53: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 E5CCA11E8081 for ; Wed, 18 Apr 2012 10:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byRz3DMnl7Lh for ; Wed, 18 Apr 2012 10:52:59 -0700 (PDT) Received: from listserv.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B94B611E8088 for ; Wed, 18 Apr 2012 10:52:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1641; t=1334771556; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=GFkenxkRFcUo10zkZvDJDItpwQ4=; b=rbaxEXYWKXizB9SECG5O +daPh5ru2D8q9rN5mh/YiiSN8x+g+A9TGb6VEAa3XCRm5KcdL2V0xqRo4KmLBDlg jwyxwMQmwSksJEPH0cdZGejdEztJZIDOu13iu3DYRZb9d91Kwqcu46R6MacfqpBk PkKaloRXU3uMxV3oXigrrGo= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 13:52: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3678378888.30007.4796; Wed, 18 Apr 2012 13:52:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1641; t=1334771225; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=wd+5r1+ roHYt1FhP88qWD/DZepliNVKrjzeeclpKaM0=; b=KD/pvL/tC6kOhdWeloSZRap tyONh8CHH15iBhbCs50QWdZkn9bXjQwhJsIBNm/ZS/C0mxV2w/Ns4/2qNkRq8h/0 VWyPQqTM9r1MPzM+G/S8bThWdnwIvtzBYCQqvFeDsg88q5Qbs+w7vtvDZguPp0CX OkZ99psLGNiYPKqfH9pU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 13:47:05 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4277280096.2035.1304; Wed, 18 Apr 2012 13:47:03 -0400 Message-ID: <4F8EFF3C.3020802@isdg.net> Date: Wed, 18 Apr 2012 13:51:56 -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: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> <4F8EEBD8.1090707@tana.it> <20120418165111.GM94829@mail.yitter.info> In-Reply-To: <20120418165111.GM94829@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 17:53:05 -0000 I always classified this multi-network problem as Developer vs Administrator philosophical differences. (note, that does not mean its distinct) Adhering to strong SMTP compliancy vs relaxation. When it comes to SPF, it simply tries to re-introduce a form of validation that for relaxed requirement that is is already there. It raises the bar for expected compliancy and by following it, you remove the legacy problems related to relaxation. But if we continue with even more relaxed provisions for a protocol designed to remove it, well, we defeat the propose of the protocol and the legacy problem remains - no incentive to legacy bad guys to adapt or even try to fake it. Just do nothing and simply target systems that behave with relaxed provisions. Andrew Sullivan wrote: > No hat. > > On Wed, Apr 18, 2012 at 06:29:12PM +0200, Alessandro Vesely wrote: > >> Isn't SPF itself an attempt at fixing SMTP? It hijacks elements of the SMTP >> protocol and confers them a meaning that they didn't originally >> bear. > > No. SPF is an attempt to express something about how receivers might > want to treat a messge received using SMTP. The Internet works in > layers, and SPF sits atop SMTP. I will cheerfully grant that it is > perched there somewhat precariously, partly because it attempts to > make assertions that are sometimes false. But it is not itself > altering SMTP. > > There is an important difference between those two ways of looking at > things, and I want to attend to that difference. > > Best, > > A -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From internet-drafts@ietf.org Wed Apr 18 11: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 2D5C221F8470; Wed, 18 Apr 2012 11:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13LOdsB9+HEy; Wed, 18 Apr 2012 11:58:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A559521F846F; Wed, 18 Apr 2012 11:58:30 -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.00 Message-ID: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2012 11:58:30 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 18:58:35 -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 : Resolution of The SPF/Sender-ID Experiment Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-04.txt Pages : 10 Date : 2012-04-18 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender-ID, two proposed email authentication protocols. Because of interoperability concerns created by simultaneous use of the two protocols by a receiver, and some concerns with Sender-ID and compatibility with existing standards, the IESG required them to have Experimental status and invited the community to observe their deployments for a period of time, hoping convergence would be possible later. After six years, sufficient experience and evidence have been collected that the experiment thus created can be considered concluded, and a single protocol can be advanced. This memo presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-04.txt From msk@cloudmark.com Wed Apr 18 12:03: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 9C65D11E808D for ; Wed, 18 Apr 2012 12:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOJ+eDOGXyPC for ; Wed, 18 Apr 2012 12:03:47 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7BE11E808C for ; Wed, 18 Apr 2012 12:03:47 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zX3u1i0010as01C01X3uYE; Wed, 18 Apr 2012 12:03:54 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=o14DKhkNj3IA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=Rd5Yb6o52Ot60XRv5osA:9 a=-RRqkKGwBKE4lXlbD88A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 12:03:36 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: I-D Action: draft-ietf-spfbis-experiment-04.txt Thread-Index: AQHNHZVHj/Q2iIoS+EGc/vtwwcFlO5ag72oA Date: Wed, 18 Apr 2012 19:03:35 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F850A@exch-mbx901.corp.cloudmark.com> References: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> In-Reply-To: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334775834; bh=UT6aUgneWQsCgOVHkiXHS589VQs0l63TQO4PAZXei/Q=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ZekIy7y3f6w1kXGHOp4JsLcfwNnYgZAES9gBm+KmzLkSThlIL8nTfZyFsffPB0gn0 7lTS4gkMUucEuaZV5MigGANAvtA1d5bBSxaQlS7mLpYx/YvMrQO+li+OqP0QDOYA54 aDZ53gEvqOG0OjZeXqF3c8MefJMRw7x5+rBCBhcA= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 19:03:51 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, April 18, 2012 11:59 AM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: I-D Action: draft-ietf-spfbis-experiment-04.txt >=20 > 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. >=20 > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-04.txt > Pages : 10 > Date : 2012-04-18 > [...] Changes in this version: - present DNS reports in tabular format, suggested by John Leslie - reorganize "analysis" and "conclusions" into their own top-level sections - rewrite conclusions so they don't sound/look like IESG instructions - corrections and suggestions from Scott Kitterman - update TDP survey numbers - remove text that speculates on the "why" part of the outcome, and some ot= her non-neutral text -MSK From spf2@kitterman.com Wed Apr 18 12:10: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 160DB21F848F for ; Wed, 18 Apr 2012 12:10: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSJp-kj2Oi0i for ; Wed, 18 Apr 2012 12:10:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 739D521F8464 for ; Wed, 18 Apr 2012 12:10:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5F43820E40CC; Wed, 18 Apr 2012 15:09:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334776199; bh=3FVMNW4Na20Qi30zWE4ILbuddatqhFtLrKmDATytDuY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=HuwRwgbVNKgeiwuSHodTKmmNxviPw31xtxoyq5IklS+6+8qZ+QD4K3OxwUw/70pfk SQG8wUFtzoYgjzwapN+XVRADdzxFE+h+4YwrwrpIOYgzxeqH3oQYI1dVpqbvXnp6bf B7glkX9Ydh+L3/peXKmnr2IDebTbFTn1b2qGLP00= Received: from scott-latitude-e6320.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 ESMTPSA id 4283420E4099; Wed, 18 Apr 2012 15:09:59 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 15:09:58 -0400 Message-ID: <1354515.fh9SkpSJJm@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> References: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 19:10:10 -0000 On Wednesday, April 18, 2012 11:58:30 AM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group of > the IETF. > > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-04.txt > Pages : 10 > Date : 2012-04-18 Ship It! Scott K From WebMaster@Commerco.Net Wed Apr 18 12:52: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 B175811E8091 for ; Wed, 18 Apr 2012 12:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvohuxcMfAK0 for ; Wed, 18 Apr 2012 12:52:44 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9F111E8089 for ; Wed, 18 Apr 2012 12:52: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=1B8GhZel2p1i4uZ3/FawkaAU9OTntwm9qmnx9GoWuMFMNzU7TU0lTtN2C7JVUJZD1jZY9W+3hfr9+PwWjVmDBAugbBuKs0kx4Wda/5FfCBMGWxmivTM6i+akHW5ZDy/tQzp1HfNSgLlDeh18xfcNxu7Dhp3gZiBYC4s/BQCLjJw= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Wed, 18 Apr 2012 19:52:43 +0000 Message-ID: <4F8F1B84.40805@Commerco.Net> Date: Wed, 18 Apr 2012 13:52:36 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280F850A@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F850A@exch-mbx901.corp.cloudmark.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] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 19:52:48 -0000 Murray, Looks good. Alan M. On 4/18/2012 1:03 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Wednesday, April 18, 2012 11:59 AM >> To: i-d-announce@ietf.org >> Cc: spfbis@ietf.org >> Subject: I-D Action: draft-ietf-spfbis-experiment-04.txt >> >> 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 : Resolution of The SPF/Sender-ID Experiment >> Author(s) : Murray S. Kucherawy >> Filename : draft-ietf-spfbis-experiment-04.txt >> Pages : 10 >> Date : 2012-04-18 >> [...] > > Changes in this version: > > - present DNS reports in tabular format, suggested by John Leslie > > - reorganize "analysis" and "conclusions" into their own top-level sections > > - rewrite conclusions so they don't sound/look like IESG instructions > > - corrections and suggestions from Scott Kitterman > > - update TDP survey numbers > > - remove text that speculates on the "why" part of the outcome, and some other non-neutral text > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From hsantos@isdg.net Wed Apr 18 12:54: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 5F06811E8094 for ; Wed, 18 Apr 2012 12:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljr3T4sqm15L for ; Wed, 18 Apr 2012 12:54:34 -0700 (PDT) Received: from secure.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0779011E8089 for ; Wed, 18 Apr 2012 12:54:33 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3594; t=1334778867; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=pLjkNk6GWn4/RZSG4wrMrdxfg5c=; b=VIejR2lrFuSArMlw+VxV 4XYx+sdKD8mAmr4MvtywviGfm6thmcE6m5kkz2Wpvvt4lY3Fp2gB0nvG760H37JG vjNeWqCyZ0udnrkdz35oPgf7oboX3atdiDQBbxPQpExpjyk/J11bJd5crn9b1U7F VhSNb1a6+FXBJSF8YxZxuIU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 15:54:27 -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 v6.4.454.1) with ESMTP id 3685689048.30007.2420; Wed, 18 Apr 2012 15:54:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3594; t=1334778535; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Shq5jtM Qc/sM1OZNMCIF77RTNUUqXvdhginiJ8IAfX0=; b=M9I5R06zhs0ffhZVNKezRH4 MO6r2HdhtOJO/v+hKM0+GA7gdsYlMSEmRppFpRNTsAtJXs5p0fFTt6pzemgSxqro pMHFEHK258klYgsf25dEIkVebaUFgRGnPxQ9cC6VU8acc8+B55R4cKTnsO6vqbiV EctQ2z3tmh1/wyvmsIYQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 15:48:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4284591533.2049.2040; Wed, 18 Apr 2012 15:48:55 -0400 Message-ID: <4F8F1BD0.40803@isdg.net> Date: Wed, 18 Apr 2012 15:53:52 -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: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> In-Reply-To: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 19:54:39 -0000 Other than the following two comments, this report draft appears to acceptable. The following are related: In section 5, item 2, I continue to believe the use of "de facto" obsolete is incorrectly applied (because its not true) and wish another technical term can used - perhaps - LOW USAGE. - By using "de facto obsolete" it implies that VENDORS have activated deprecated or stop using it, or removed it as an option for operators. I don't see any evidence of that nor do I believe its true because that will also means they don't no longer care about the high corporate branding value the term "Sender ID" had, despite the fact that in reality it was piggy backing on SPF. That is what Meng Wong wanted - the Corporate Branding and Sponsorship of Microsoft "Sender ID" benefiting SPF world wide adoption. He told me so directly when I asked why did he allow MS get the sole patent disclosure credit without any prior art mentioning of SPF or himself. So please do not underestimate how serious this "de facto obsolete" has or in fact will be ignored, or even make this report less trustworthy to accept as a whole. In other words, why even go there when you don't need to? Related In section 3, it must be emphasize that it was ALWAYS expected that the SIDF and SPF v1.0 domains will match and the SIDF only covered certain use cases that was certainly LESS than the majority. The reports says "at least 50% of the time," I may suggest to change the to "at least 50% and has high as over 80% of the time" but regardless if its 50, 80, or 95%, the point remains - it was always expected to be a LOW VOLUME (when they did not match) and the empirical data showing the high equality is evidence confirmation of the original design expectation. So if anything, I would suggest that this section or else where make light of that protocol expectation for PRA. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SPF Update Working Group of the IETF. > > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-04.txt > Pages : 10 > Date : 2012-04-18 > > In 2006 the IETF published a suite of protocol documents comprising > SPF and Sender-ID, two proposed email authentication protocols. > Because of interoperability concerns created by simultaneous use of > the two protocols by a receiver, and some concerns with Sender-ID and > compatibility with existing standards, the IESG required them to have > Experimental status and invited the community to observe their > deployments for a period of time, hoping convergence would be > possible later. > > After six years, sufficient experience and evidence have been > collected that the experiment thus created can be considered > concluded, and a single protocol can be advanced. This memo presents > those findings. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-04.txt > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From spf2@kitterman.com Wed Apr 18 13:03: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 C6B4C11E80A4 for ; Wed, 18 Apr 2012 13:03: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaeWJvw2hXdL for ; Wed, 18 Apr 2012 13:03:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 90F7321F844C for ; Wed, 18 Apr 2012 13:03:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1AE3E20E40CC; Wed, 18 Apr 2012 16:03:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334779413; bh=WDlr4jswbYaYqj2aN23zIDAoWs7TXjKXGtLPIOjn06o=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=apZjAp+96DKPlRue+quK3DXWyoUyqq6r5kmak5lvJHeKxdAoJgxutlm4cRkDiFhPF nrUnh0yi+FT36BQBHM5s9zDuXWBv57WRFdRZzOvsvsPzG/XxWwEGNskrJkn5eakem5 jLW7NAP2diArSryhBkQX773mt3eYWSWZ5UF9j6H8= Received: from scott-latitude-e6320.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 ESMTPSA id EEBF420E4099; Wed, 18 Apr 2012 16:03:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 16:03:32 -0400 Message-ID: <2188716.LIo2ntVapr@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8F1BD0.40803@isdg.net> References: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <4F8F1BD0.40803@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] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:03:37 -0000 On Wednesday, April 18, 2012 03:53:52 PM Hector Santos wrote: > - By using "de facto obsolete" it implies that VENDORS have activated > deprecated or stop using it, or removed it as an option for > operators. > I don't see any evidence of that nor do I believe its true because > that will also means they don't no longer care about the high > corporate > branding value the term "Sender ID" had, despite the fact that > in reality > it was piggy backing on SPF. That is what Meng Wong wanted - > the Corporate > Branding and Sponsorship of Microsoft "Sender ID" benefiting SPF > world wide > adoption. He told me so directly when I asked why did he allow > MS get > the sole patent disclosure credit without any prior art > mentioning of > SPF or himself. So please do not underestimate how serious this > "de facto obsolete" has or in fact will be ignored, or even make > this > report less trustworthy to accept as a whole. In other words, why > even go there when you don't need to? This is not about branding, so I think your related comments are off topic. This is a technical forum. I also think that whatever Meng Wong may have wanted when he agreed to the SPF/Caller ID For Email merger for MARID, it's equally irrelevant. None of these documents are products of that working group. Personally I prefer we just say that they should not be advanced onto standards track as that's all we need to do to finish the experiment, but I don't think branding has any place in the discussion. Scott K From hsantos@isdg.net Wed Apr 18 13:25: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 75FC311E8085 for ; Wed, 18 Apr 2012 13:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycmx5ewU2lLF for ; Wed, 18 Apr 2012 13:25:47 -0700 (PDT) Received: from secure.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBB11E80A4 for ; Wed, 18 Apr 2012 13:25:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2895; t=1334780737; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=oTXzw31niim9xIeXP9FGsbXCifo=; b=THzovaTleVtknUzcLnRI P2SKYkjSExXmOeKLa/MfEYy0PBsjTbJTH7/dsDA+6dbdxl6C02pvQt3zjXbqZEAj MV/YeoTWACj/cJDFOxnJqsC+WriTOc4v/TXmLx4T90EVek5ZoUheA97UBt3XtCo5 voqyre4md8qYy0pMLmE85ys= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 16:25: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 v6.4.454.1) with ESMTP id 3687559141.30007.2440; Wed, 18 Apr 2012 16:25:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2895; t=1334780406; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=MSJbQtx QJNcwxbF2JO96AuD7ygCz64Fw2Oa/qLh7pkc=; b=i9fIStK6EE64l1qayf3R1z+ r6br1PYbOifTYu8V8LIEN6oineCFhymHO/ZnaQLvIl/pntRPcnNoxeW9OcBC7Yn7 KmbqHsF0KyHQjueCORZzw1oX1WfAvnQUClX7YF86Fq410klpNq7PlXLxXmPnI54N di9K9kyxlyiQeAICk4Cc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 16:20:06 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4286461440.2053.5136; Wed, 18 Apr 2012 16:20:05 -0400 Message-ID: <4F8F231E.7090401@isdg.net> Date: Wed, 18 Apr 2012 16:25:02 -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: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <4F8F1BD0.40803@isdg.net> <2188716.LIo2ntVapr@scott-latitude-e6320> In-Reply-To: <2188716.LIo2ntVapr@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] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:25:52 -0000 Scott Kitterman wrote: > On Wednesday, April 18, 2012 03:53:52 PM Hector Santos wrote: >> By using "de facto obsolete" it implies that VENDORS have activated >> deprecated or stop using it, or removed it as an option for >> operators. I don't see any evidence of that nor do I believe its true because >> that will also means they don't no longer care about the high >> corporate branding value the term "Sender ID" had, despite the fact >> that in reality it was piggy backing on SPF. That is what Meng Wong >> wanted - the Corporate Branding and Sponsorship of Microsoft "Sender ID" >> benefiting SPF world wide adoption. He told me so directly when I asked >> why did he allow MS get the sole patent disclosure credit without >> any prior art mentioning of SPF or himself. So please do not >> underestimate how serious this "de facto obsolete" has or in fact >> will be ignored, or even make this report less trustworthy to accept >> as a whole. In other words, why even go there when you don't need to? > > This is not about branding, so I think your related comments are off topic. > This is a technical forum. I also think that whatever Meng Wong may have > wanted when he agreed to the SPF/Caller ID For Email merger for MARID, it's > equally irrelevant. None of these documents are products of that working > group. > > Personally I prefer we just say that they should not be advanced onto > standards track as that's all we need to do to finish the experiment, but I > don't think branding has any place in the discussion. I was never seeking to be discussed - its should of been a natural consideration overall engineering mindset, because at the end of the day, the technical outcome of what is essentially a "Product Update" will have an impact on the production (where markeing and branding exist) side, or maybe not depending if its viewed with non-convincing, bias justifications with it product impacting conclusions. Thats just reality Scott, its like saying that all of sudden everyone's documenations and web site will be expected to remove all their "branding" using Sender ID as the technology in play even thought between you, me and that gatepost, we know its all about SPF. How about technology promotion sites citing large groups of "Corporate Brand" vendors support, like: http://www.microsoft.com/mscorp/safety/technologies/senderid/support.mspx Nonetheless, the branding comment was a sub-note. the real issue is that is not true, de facto obsolete is not correct for the other reasons stated. Do you disagree it was never expected to be a high volume? That PRA was only be a low percentage of use cases? You can't use this confirmed observation to suggest it was low usage, therefore by "de facto" obsolete. It isn't correct. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From spf2@kitterman.com Wed Apr 18 13:43: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 8B28B11E8091 for ; Wed, 18 Apr 2012 13:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc1B4BxOEt9w for ; Wed, 18 Apr 2012 13:43:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDBA11E80AC for ; Wed, 18 Apr 2012 13:43:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 845C620E40CC; Wed, 18 Apr 2012 16:43:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334781816; bh=d1cj0X9Up62P/oBQci6sdBdTHWmU6QkTJwFvUfyYvOU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=dURr3sVdEf0PWqa8ra6Feo/48emw+Ij1ZvEVKIgsjmknSSDjS8beoEdTbvL5TYwln znjn/VlLtXvjQHcoUHAzBkI2ObxMfqtcjcuyEo6NN9OFj5Jogbhdq/02vTVfruQRUS eL1uKpfbMUzfr/C+BgJXYyL7jgxD0FPfKkItafQ0= Received: from scott-latitude-e6320.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 ESMTPSA id 65BCE20E4099; Wed, 18 Apr 2012 16:43:36 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 16:43:35 -0400 Message-ID: <95370437.hRjGPMH75Q@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8F231E.7090401@isdg.net> References: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <2188716.LIo2ntVapr@scott-latitude-e6320> <4F8F231E.7090401@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] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:43:41 -0000 On Wednesday, April 18, 2012 04:25:02 PM Hector Santos wrote: > Scott Kitterman wrote: > > On Wednesday, April 18, 2012 03:53:52 PM Hector Santos wrote: > >> By using "de facto obsolete" it implies that VENDORS have activated > >> deprecated or stop using it, or removed it as an option for > >> operators. I don't see any evidence of that nor do I believe its true > >> because that will also means they don't no longer care about the high > >> corporate branding value the term "Sender ID" had, despite the fact > >> that in reality it was piggy backing on SPF. That is what Meng Wong > >> wanted - the Corporate Branding and Sponsorship of Microsoft "Sender ID" > >> benefiting SPF world wide adoption. He told me so directly when I asked > >> why did he allow MS get the sole patent disclosure credit without > >> any prior art mentioning of SPF or himself. So please do not > >> underestimate how serious this "de facto obsolete" has or in fact > >> will be ignored, or even make this report less trustworthy to accept > >> as a whole. In other words, why even go there when you don't need to? > > > > This is not about branding, so I think your related comments are off > > topic. > > This is a technical forum. I also think that whatever Meng Wong may have > > wanted when he agreed to the SPF/Caller ID For Email merger for MARID, > > it's > > equally irrelevant. None of these documents are products of that working > > group. > > > > Personally I prefer we just say that they should not be advanced onto > > standards track as that's all we need to do to finish the experiment, but > > I > > don't think branding has any place in the discussion. > > I was never seeking to be discussed - its should of been a natural > consideration overall engineering mindset, because at the end of the > day, the technical outcome of what is essentially a "Product Update" > will have an impact on the production (where markeing and branding > exist) side, or maybe not depending if its viewed with non-convincing, > bias justifications with it product impacting conclusions. > > Thats just reality Scott, its like saying that all of sudden > everyone's documenations and web site will be expected to remove all > their "branding" using Sender ID as the technology in play even > thought between you, me and that gatepost, we know its all about SPF. > How about technology promotion sites citing large groups of > "Corporate Brand" vendors support, like: > > http://www.microsoft.com/mscorp/safety/technologies/senderid/support.mspx > > Nonetheless, the branding comment was a sub-note. the real issue is > that is not true, de facto obsolete is not correct for the other > reasons stated. Do you disagree it was never expected to be a high > volume? That PRA was only be a low percentage of use cases? You > can't use this confirmed observation to suggest it was low usage, > therefore by "de facto" obsolete. > > It isn't correct. I'm trying to stay out of the how you measure it discussion. I think it's clear where the industry momentum is and I'm not concerned about if we're getting it wrong. As I said, I'd prefer "do not advance" over "defacto obsolete", but I don't think it makes a lot of difference. Vendors are free to support obsolete protocols as long as they care to and do (witness how long it's taking to get rid of SSL V2). That's a separate discussion. Scott K From dotis@mail-abuse.org Wed Apr 18 13:49: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 4240011E80AA for ; Wed, 18 Apr 2012 13:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LoZ0fyffCKe for ; Wed, 18 Apr 2012 13:49:14 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4A11E80A2 for ; Wed, 18 Apr 2012 13:49:14 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 33DBD1740622 for ; Wed, 18 Apr 2012 20:49:14 +0000 (UTC) Message-ID: <4F8F28C9.7000605@mail-abuse.org> Date: Wed, 18 Apr 2012 13:49:13 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <47685701.Z6iPPE2elv@scott-latitude-e6320> <4F8ED83D.3060908@tana.it> <1368066.mJbxKxkNYY@scott-latitude-e6320> In-Reply-To: <1368066.mJbxKxkNYY@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:49:15 -0000 On 4/18/12 8:24 AM, Scott Kitterman wrote: > On Wednesday, April 18, 2012 05:05:33 PM Alessandro Vesely wrote: >> On Wed 18/Apr/2012 16:43:03 +0200 Scott Kitterman wrote: >>> On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: >>>> If we discard the proposed "helo-pass prevents rejection", the SMTP >>>> compatible alternative that we're left with is to prevent rejection >>>> altogether --that's what gmail does, btw. Isn't that an even more >>>> drastic >>>> change? >>> It's not a change. RFC 4408 doesn't say reject or don't reject. What the >>> receiver chooses is not part of the protocol, only the mechanism for the >>> choice (which is why there is If reject then ... language). >> I'm not interested in wording at this stage. Let's consider the overall >> meaning of what we're going to say. > I propose we not say stuff about receiver policy that RFC 4408 doesn't say. Dear Scott, It would be appropriate to assert "should reject" for SPF failures referenced by the EHLO identity, and "should not reject" when referenced by the bounce address. In other words, SPF can assure hop-by-hop path authentication when referenced by the EHLO. Regards, Douglas Otis From spf2@kitterman.com Wed Apr 18 13:57: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 3D08611E80AF for ; Wed, 18 Apr 2012 13:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR3l0Oj-OxBy for ; Wed, 18 Apr 2012 13:57:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 004F711E8095 for ; Wed, 18 Apr 2012 13:57:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8D22320E40CC; Wed, 18 Apr 2012 16:57:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334782641; bh=09We1bzJA1947lBbUfUeg28yB+qV/7s+bdCujgOCpnQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=cIqFcHXwOLwyJX1E/rc0qEQr+e809KzFyc/xpeZ0PC4bJibUOukCRcMxk9vVWQBgM DjkAIWL6CCvj+K/Cw57Req8gKOynA0fxGO+AEu+XtSE151wquwHDV8KcEw7LRzK54w jR1HAYshCLKtfxV98wrE3N9oQto/a5IooeOVwyx4= Received: from scott-latitude-e6320.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 ESMTPSA id 6E89720E4099; Wed, 18 Apr 2012 16:57:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 16:57:20 -0400 Message-ID: <1479729.G39EARoN3C@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8F28C9.7000605@mail-abuse.org> References: <20120324090349.15462.qmail@joyce.lan> <1368066.mJbxKxkNYY@scott-latitude-e6320> <4F8F28C9.7000605@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:57:26 -0000 On Wednesday, April 18, 2012 01:49:13 PM Douglas Otis wrote: > On 4/18/12 8:24 AM, Scott Kitterman wrote: > > On Wednesday, April 18, 2012 05:05:33 PM Alessandro Vesely wrote: > >> On Wed 18/Apr/2012 16:43:03 +0200 Scott Kitterman wrote: > >>> On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: > >>>> If we discard the proposed "helo-pass prevents rejection", the SMTP > >>>> compatible alternative that we're left with is to prevent rejection > >>>> altogether --that's what gmail does, btw. Isn't that an even more > >>>> drastic > >>>> change? > >>> > >>> It's not a change. RFC 4408 doesn't say reject or don't reject. What > >>> the > >>> receiver chooses is not part of the protocol, only the mechanism for the > >>> choice (which is why there is If reject then ... language). > >> > >> I'm not interested in wording at this stage. Let's consider the overall > >> meaning of what we're going to say. > > > > I propose we not say stuff about receiver policy that RFC 4408 doesn't > > say. > > Dear Scott, > > It would be appropriate to assert "should reject" for SPF failures > referenced by the EHLO identity, and "should not reject" when referenced > by the bounce address. > > In other words, SPF can assure hop-by-hop path authentication when > referenced by the EHLO. Do you have evidence this is in widespread use? If not, it's outside the scope of the charter, IMO. Scott K From SRS0=DCK5i=CY==stuart@gathman.org Wed Apr 18 14:14: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 1EFF911E8094 for ; Wed, 18 Apr 2012 14:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpK3wXXX1fSn for ; Wed, 18 Apr 2012 14:14:13 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAA411E8091 for ; Wed, 18 Apr 2012 14:14:13 -0700 (PDT) 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 q3ILEC7h011258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Apr 2012 17:14:12 -0400 Message-ID: <4F8F2EA4.9050206@gathman.org> Date: Wed, 18 Apr 2012 17:14:12 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <47685701.Z6iPPE2elv@scott-latitude-e6320> <4F8ED83D.3060908@tana.it> <1368066.mJbxKxkNYY@scott-latitude-e6320> <4F8F28C9.7000605@mail-abuse.org> In-Reply-To: <4F8F28C9.7000605@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 21:14:14 -0000 Long ago, Nostradamus foresaw that on 04/18/2012 04:49 PM, Douglas Otis would write: > On 4/18/12 8:24 AM, Scott Kitterman wrote: >> On Wednesday, April 18, 2012 05:05:33 PM Alessandro Vesely wrote: >>> On Wed 18/Apr/2012 16:43:03 +0200 Scott Kitterman wrote: >>>> On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: >>>>> If we discard the proposed "helo-pass prevents rejection", the SMTP >>>>> compatible alternative that we're left with is to prevent rejection >>>>> altogether --that's what gmail does, btw. Isn't that an even more >>>>> drastic >>>>> change? >>>> It's not a change. RFC 4408 doesn't say reject or don't reject. >>>> What the >>>> receiver chooses is not part of the protocol, only the mechanism >>>> for the >>>> choice (which is why there is If reject then ... language). >>> I'm not interested in wording at this stage. Let's consider the >>> overall >>> meaning of what we're going to say. >> I propose we not say stuff about receiver policy that RFC 4408 >> doesn't say. > > It would be appropriate to assert "should reject" for SPF failures > referenced by the EHLO identity, and "should not reject" when > referenced by the bounce address. > +1 for SHOULD reject on EHLO fail - I've been doing that for years. Any MTAs that had problems had *many* problems due to general cluelessness. I did talk to a mail admin who insisted on using the same EHLO name for all of his (dozen or so) MTAs, and the IP of the name did not match any of them (and he was not open to listing multiple IPs for the name in DNS), and the SPF record was for a MFROM which (for some reason) used a completely different set of servers, and he was mad at me for checking SPF for his EHLO and rejecting his connections. I don't think his policies were very RFC compliant. In fact, I would love it if SMTP were updated to "SHOULD reject when connect IP != EHLO FQDN IP" - no SPF is required. But people have been abusing EHLO for years (not using a FQDN that matches the connect IP), and publishing an SPF record for EHLO makes it crystal clear that you do it right and EHLO forgeries should be rejected. -1 for SHOULD NOT reject on MFROM unless qualified by "from an authorized (by the recipient) alias forwarder". From msk@cloudmark.com Wed Apr 18 14:34: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 6A2C411E8097 for ; Wed, 18 Apr 2012 14:34:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWW5UPgRcla5 for ; Wed, 18 Apr 2012 14:34:07 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6044D11E8095 for ; Wed, 18 Apr 2012 14:34:07 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zZZw1i0010ZaKgw01ZZwye; Wed, 18 Apr 2012 14:33:56 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=-L_zILLHU_EA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=0VoaxLBkJV8Xp0bh5SIA:9 a=OCyh8aQupq7jSQBLJVQA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=itN0gf3QovWeh0zd:21 a=STOq2sYoYz5zlSkm:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 14:33:53 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt Thread-Index: AQHNHZVHj/Q2iIoS+EGc/vtwwcFlO5ahdCMAgAACswCAAAYCAIAABS+A//+TlHA= Date: Wed, 18 Apr 2012 21:33:53 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F886B@exch-mbx901.corp.cloudmark.com> References: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <2188716.LIo2ntVapr@scott-latitude-e6320> <4F8F231E.7090401@isdg.net> <95370437.hRjGPMH75Q@scott-latitude-e6320> In-Reply-To: <95370437.hRjGPMH75Q@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334784836; bh=vVqzMqK/Phhavnl64eCKG1RQp0IsBslJ/RUPjMdnXRg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=jMX1Ch2wTw56+OW/Qnvg5cCeRnmnuSanPOfOZYSFNh8D1r0zKMZ4dhlzl6sulhWkO Xtuj+ovYgcmv/KJoy/Jc/TKqhT2pYbLeVUMBUNfMUF6VT4eJA3zmnIoBarH74htlGO q64Nee1xQbeM/KNuXfzhaFY2oUtpTEY7UbgAY5ic= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 21:34:11 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, April 18, 2012 1:44 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt >=20 > > Nonetheless, the branding comment was a sub-note. the real issue is > > that is not true, de facto obsolete is not correct for the other > > reasons stated. Do you disagree it was never expected to be a high > > volume? That PRA was only be a low percentage of use cases? You > > can't use this confirmed observation to suggest it was low usage, > > therefore by "de facto" obsolete. >=20 > I'm trying to stay out of the how you measure it discussion. I think > it's clear where the industry momentum is and I'm not concerned about > if we're getting it wrong. As I said, I'd prefer "do not advance" over > "defacto obsolete", but I don't think it makes a lot of difference. The Sender-ID suite positioned itself to handle the 20% of cases that SPF g= ot "wrong" (namely stuff like forwarding). That's not the same as saying i= t would only get used 20% of the time, because that then means its intended= use was as a fallback mechanism only evaluated when SPF didn't say "pass",= and I don't see that in any documentation anywhere. So I claim the cited = premise is incorrect. In 2006 when these things were rolled out, there was an industry push for S= ender-ID adoption. It has faded to less than 5%, as multiple surveys have = now demonstrated. That is the very dictionary definition of "de facto obso= lete". "Low usage in favor of something else, as shown by these surveys" is just a= long-winded way of saying "de facto obsolete". > Vendors are free to support obsolete protocols as long as they care to > and do (witness how long it's taking to get rid of SSL V2). That's a > separate discussion. Right, and I don't think we need to be concerned with marketing or branding= either. That's for a community separate from this one. -MSK From dotis@mail-abuse.org Wed Apr 18 14:34: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 56CAA11E8097 for ; Wed, 18 Apr 2012 14:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0QmMvQ0X2fj for ; Wed, 18 Apr 2012 14:34:56 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8612A11E8094 for ; Wed, 18 Apr 2012 14:34:56 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 70D881740629 for ; Wed, 18 Apr 2012 21:34:56 +0000 (UTC) Message-ID: <4F8F3380.8090509@mail-abuse.org> Date: Wed, 18 Apr 2012 14:34:56 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <1368066.mJbxKxkNYY@scott-latitude-e6320> <4F8F28C9.7000605@mail-abuse.org> <1479729.G39EARoN3C@scott-latitude-e6320> In-Reply-To: <1479729.G39EARoN3C@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 21:34:57 -0000 On 4/18/12 1:57 PM, Scott Kitterman wrote: > On Wednesday, April 18, 2012 01:49:13 PM Douglas Otis wrote: >> On 4/18/12 8:24 AM, Scott Kitterman wrote: >>> On Wednesday, April 18, 2012 05:05:33 PM Alessandro Vesely wrote: >>>> On Wed 18/Apr/2012 16:43:03 +0200 Scott Kitterman wrote: >>>>> On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: >>>>>> If we discard the proposed "helo-pass prevents rejection", the SMTP >>>>>> compatible alternative that we're left with is to prevent rejection >>>>>> altogether --that's what gmail does, btw. Isn't that an even more >>>>>> drastic >>>>>> change? >>>>> It's not a change. RFC 4408 doesn't say reject or don't reject. What >>>>> the >>>>> receiver chooses is not part of the protocol, only the mechanism for the >>>>> choice (which is why there is If reject then ... language). >>>> I'm not interested in wording at this stage. Let's consider the overall >>>> meaning of what we're going to say. >>> I propose we not say stuff about receiver policy that RFC 4408 doesn't >>> say. >> Dear Scott, >> >> It would be appropriate to assert "should reject" for SPF failures >> referenced by the EHLO identity, and "should not reject" when referenced >> by the bounce address. >> >> In other words, SPF can assure hop-by-hop path authentication when >> referenced by the EHLO. > Do you have evidence this is in widespread use? If not, it's outside the > scope of the charter, IMO. Dear Scott, SPF RR referenced by bounce addresses must consider usage as this element might be modified during exchanges between administrative domains. Those referenced by the EHLO however pertain to a single administrative domain publishing their own SPF RRs. For receivers expending resources to process EHLO referenced SPF RRs, describe a scenario where it would be wrong to reject messages where EHLO/SPF fails. Logically it should not matter whether there is only one or millions of administrative domains publishing SPF RRs for their own EHLO. Regards, Douglas Otis From spf2@kitterman.com Wed Apr 18 15:03: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 CB7A611E809D for ; Wed, 18 Apr 2012 15:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyAQo6iXUhnN for ; Wed, 18 Apr 2012 15:03:43 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8B98B11E80AE for ; Wed, 18 Apr 2012 15:03:43 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id C5162956002; Wed, 18 Apr 2012 17:03:42 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334786622; bh=VU7tmkV6SD9fKdsEm6D8oXu5FXjfVUD7Ie0/lzTliis=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=jAptxNyVSY/zDmLKUxeYnfy2RhKS3B9hxaDKiCIkdfG1lN+Lr+MQWI9w17jUH65Ga z1oxPziF8i7Q3/WCz5LYNsgNjYOJTSJoqSR0Jxu+V31XAaEJDUPfBaPwj9NiwutRw8 J10jGEYa9cxT2gpbG4kScJEOpzekpmiNJiWuXGdM= Received: from 91.sub-97-1-191.myvzw.com (91.sub-97-1-191.myvzw.com [97.1.191.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 47AF9956001; Wed, 18 Apr 2012 17:03:42 -0500 (CDT) References: <20120324090349.15462.qmail@joyce.lan> <1368066.mJbxKxkNYY@scott-latitude-e6320> <4F8F28C9.7000605@mail-abuse.org> <1479729.G39EARoN3C@scott-latitude-e6320> <4F8F3380.8090509@mail-abuse.org> User-Agent: K-9 Mail for Android In-Reply-To: <4F8F3380.8090509@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 18 Apr 2012 18:03:48 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] =?utf-8?q?=2312=3A_RFC_4408_Section_9_-=09Forwarding=09a?= =?utf-8?q?nd=09helo=09identities?= X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 22:03:47 -0000 Douglas Otis wrote: >On 4/18/12 1:57 PM, Scott Kitterman wrote: >> On Wednesday, April 18, 2012 01:49:13 PM Douglas Otis wrote: >>> On 4/18/12 8:24 AM, Scott Kitterman wrote: >>>> On Wednesday, April 18, 2012 05:05:33 PM Alessandro Vesely wrote: >>>>> On Wed 18/Apr/2012 16:43:03 +0200 Scott Kitterman wrote: >>>>>> On Wednesday, April 18, 2012 04:20:27 PM Alessandro Vesely wrote: >>>>>>> If we discard the proposed "helo-pass prevents rejection", the >SMTP >>>>>>> compatible alternative that we're left with is to prevent >rejection >>>>>>> altogether --that's what gmail does, btw. Isn't that an even >more >>>>>>> drastic >>>>>>> change? >>>>>> It's not a change. RFC 4408 doesn't say reject or don't reject. >What >>>>>> the >>>>>> receiver chooses is not part of the protocol, only the mechanism >for the >>>>>> choice (which is why there is If reject then ... language). >>>>> I'm not interested in wording at this stage. Let's consider the >overall >>>>> meaning of what we're going to say. >>>> I propose we not say stuff about receiver policy that RFC 4408 >doesn't >>>> say. >>> Dear Scott, >>> >>> It would be appropriate to assert "should reject" for SPF failures >>> referenced by the EHLO identity, and "should not reject" when >referenced >>> by the bounce address. >>> >>> In other words, SPF can assure hop-by-hop path authentication when >>> referenced by the EHLO. >> Do you have evidence this is in widespread use? If not, it's outside >the >> scope of the charter, IMO. >Dear Scott, > >SPF RR referenced by bounce addresses must consider usage as this >element might be modified during exchanges between administrative >domains. Those referenced by the EHLO however pertain to a single >administrative domain publishing their own SPF RRs. For receivers >expending resources to process EHLO referenced SPF RRs, describe a >scenario where it would be wrong to reject messages where EHLO/SPF >fails. Logically it should not matter whether there is only one or >millions of administrative domains publishing SPF RRs for their own >EHLO. > That's theorizing, not providing evidence of use, so it's not what the charter requires. Scott K From hsantos@isdg.net Wed Apr 18 16: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 CBCBB11E808C for ; Wed, 18 Apr 2012 16:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBGDkKINN28j for ; Wed, 18 Apr 2012 16:38:16 -0700 (PDT) Received: from pop3.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7F21F84AA for ; Wed, 18 Apr 2012 16:38:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1480; t=1334792286; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=D/JBtXhFg7qVm3fr1j2COhajY4Y=; b=eyaqBqwB/vhlELpuIOwK U4C5wF/W2d9qhMwekvu27Jo+uwTX9LUTKr2vjVwRXjgcBi8txUF3FASALTTBndoR R5uRasd7XtopVGIpttZzOaxQVs01n3bA7o3LpgQDuDOmW7Sovhw8+UQ5Du5BSVTN ne5AeO/Gqc+2kfyJQFazsdA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 19:38: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3699109331.30007.5160; Wed, 18 Apr 2012 19:38:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1480; t=1334791955; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0+IYN+k WchHLuTI4zxEi0NCjBLtb8N9Fqe092lf18Ow=; b=aAB8xtHkYS4nSfGCoQxv1Ld Gpra4njpAdfSA4sQlxri2JYDmEUc5afAuIWIofLpJphjzvyk+HeuUPvUKOb5h+36 Edhqddd5J3Zm7E+rw4IkOlf4mZo/qPiMKxG9TclfEk8Qakfa5C4agqK7Pi3NYq4D K8Jc12ceQrZyeOrAr+Vk= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 19:32:35 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3043019.2071.7236; Wed, 18 Apr 2012 19:32:34 -0400 Message-ID: <4F8F503B.9010707@isdg.net> Date: Wed, 18 Apr 2012 19:37:31 -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: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <2188716.LIo2ntVapr@scott-latitude-e6320> <4F8F231E.7090401@isdg.net> <95370437.hRjGPMH75Q@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280F886B@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F886B@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 23:38:21 -0000 Hi, In the interest of moving forward, I will accept the report but I will make a recorded objection during LC regarding the specific "de facto obsolete" points I made. Thanks for your consideration of my report inputs, your work effort is admirable and appreciated. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com Murray S. Kucherawy wrote: > The Sender-ID suite positioned itself to handle the 20% of cases that SPF got "wrong" (namely stuff like forwarding). That's not the same as saying it would only get used 20% of the time, because that then means its intended use was as a fallback mechanism only evaluated when SPF didn't say "pass", and I don't see that in any documentation anywhere. So I claim the cited premise is incorrect. > > In 2006 when these things were rolled out, there was an industry push for Sender-ID adoption. It has faded to less than 5%, as multiple surveys have now demonstrated. That is the very dictionary definition of "de facto obsolete". > > "Low usage in favor of something else, as shown by these surveys" is just a long-winded way of saying "de facto obsolete". > >> Vendors are free to support obsolete protocols as long as they care to >> and do (witness how long it's taking to get rid of SSL V2). That's a >> separate discussion. > > Right, and I don't think we need to be concerned with marketing or branding either. That's for a community separate from this one. > > -MSK From hsantos@isdg.net Wed Apr 18 17:09: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 07F2911E8097 for ; Wed, 18 Apr 2012 17:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qX9L0oeduc5 for ; Wed, 18 Apr 2012 17:09:10 -0700 (PDT) Received: from pop3.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BAAAB11E808C for ; Wed, 18 Apr 2012 17:09:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2176; t=1334794147; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=IsnXOUhkxeS6eThagywZNiEjsc4=; b=Vi39dKwZ/1tr/YSWSTYj Unh2y9wwfRlkJczIqqdkqOKXrGvnmDO4FM4FrfdEdXIIz6EFOX5WoS3ZlUSSZoh1 uuBKp5dC8IuNVlsfbHraLVzBLH+nePZmC1fYYcuFvXrwnsOuiYkiYOf54iYMfMkX jFW/drrDjAKCqkwFjQCyz1E= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 20:09:07 -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 v6.4.454.1) with ESMTP id 3700969471.30007.2808; Wed, 18 Apr 2012 20:09:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2176; t=1334793815; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VEXrt7Z +0i4AT37GOsiZh/ePTlarWg5pIaoRmB5gE24=; b=L92XZZJnFnbra131Y+Ka2u6 U5WLSzsccLttKZf5bvjtsSdw7o2piNDKzxAcjCva8s1N5rU4bZueiwnN9q7Kx64e Hjtba1LG+JVB6au4quSMwgBvqUz0gpMTgNo8cnRSkE7G9gdNA13DO6m5bq2bcOAU jPEL70hjTw3Ct82xMT/c= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 20:03:35 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4902425.2075.7452; Wed, 18 Apr 2012 20:03:33 -0400 Message-ID: <4F8F577E.4070503@isdg.net> Date: Wed, 18 Apr 2012 20:08:30 -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: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <2188716.LIo2ntVapr@scott-latitude-e6320> <4F8F231E.7090401@isdg.net> <95370437.hRjGPMH75Q@scott-latitude-e6320> In-Reply-To: <95370437.hRjGPMH75Q@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 00:09:15 -0000 Scott Kitterman wrote: > I'm trying to stay out of the how you measure it discussion. But you're not. :) We are all measuring it at some level and when you (speaking in general) use terms like Wide Deployment, Widespread, Large Scale or throw out data points like 5%, low usage and "de factor Obsolete", etc, you are inherently using Big Wheel, "Branding", Who's Who using What matters most concepts and overall the old General Motors corporate mantra of "What's good for GM, is good for America!" :) > I think it's clear where the industry momentum is.. Case in point! :) > and I'm not concerned about if we're getting it wrong. Maybe there is a reason for that I am not catching, but I do admit I have always been cursed with corporate QA methodology: "Getting it right... the first time!" Its not about perfection, but doing your best to avoid the obvious that in the end don't require you to redo, repeat or revisit something that could of avoided in the first place, especially when it was known upfront but some reason was ignored or thrown aside. Doing it right, the first time is about producing results with higher customer satisfaction and minimizing cost across the aboard. > Vendors are free to support obsolete protocols as long as they care to and do > (witness how long it's taking to get rid of SSL V2). That's a separate > discussion. Well, I personally believe that when the all issues are considered, better decisions are made that doesn't or lowers the need to revisit it latter. With this specific "de facto obsolete", in my view will have a ripple effort, and quite frankly will trouble the people who are using it, even they are just among the so called "5%" as its claimed to be. Just consider, the SPF web site will be among the first to HIGHLIGHT in whatever fashion or words, SENDER-ID was DEAD and officially disclaimed OBSOLETE by the IETF and no longer something any domain should to think about or bother with. I doubt the web site will be able to resist it. Thats all part of marketing and branding! :) -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From spf2@kitterman.com Wed Apr 18 17:47: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 DC18C21F846D for ; Wed, 18 Apr 2012 17:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7VJ9L7YxMdl for ; Wed, 18 Apr 2012 17:47:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F48A21F8450 for ; Wed, 18 Apr 2012 17:47:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5D4BF20E40CC; Wed, 18 Apr 2012 20:47:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334796430; bh=Sdnehd5tWFC8rQgisVU526wOUsQYmBcUw/cMGFsNQ7Y=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=oIDeMCBK+fmjRPXFNzO+Uf8XGbMdtflOwiAPH03eTY2/OH6n/llpXvWlNpZWxDpev hzqto3qNB3ssTfBj6GbiMDQpm5U0zo5jLY34BgfQGH6BK7MGjr59GYmeTdtMfL6i1k cpfdyEp5uRwrX5W75lQFCiAORPprmyErzRs63t6c= Received: from scott-latitude-e6320.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 ESMTPSA id 3F46220E4099; Wed, 18 Apr 2012 20:47:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Apr 2012 20:47:09 -0400 Message-ID: <2057445.Rk22vZFEzR@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F8F577E.4070503@isdg.net> References: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <95370437.hRjGPMH75Q@scott-latitude-e6320> <4F8F577E.4070503@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] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 00:47:16 -0000 On Wednesday, April 18, 2012 08:08:30 PM Hector Santos wrote: > Scott Kitterman wrote: > > I'm trying to stay out of the how you measure it discussion. > > But you're not. :) We are all measuring it at some level and when you > (speaking in general) use terms like Wide Deployment, Widespread, > Large Scale or throw out data points like 5%, low usage and "de factor > Obsolete", etc, you are inherently using Big Wheel, "Branding", Who's > Who using What matters most concepts and overall the old General > Motors corporate mantra of "What's good for GM, is good for America!" :) I said I was trying to stay out of it. I wasn't speaking in general. I was speaking specifically. I'm mostly interested in reviewing the draft to make sure it doesn't mis-state the history. Writing it is a hard problem and I'm glad it's not me doing it. > > I think it's clear where the industry momentum is.. > > Case in point! :) That is my opinion. I don't think it would be reasonable to put that in the draft, so I'm not sure what it's a case in point of. > > and I'm not concerned about if we're getting it wrong. > > Maybe there is a reason for that I am not catching, but I do admit I > have always been cursed with corporate QA methodology: Because I'm confident the basic thrust is right. > "Getting it right... the first time!" > > Its not about perfection, but doing your best to avoid the obvious > that in the end don't require you to redo, repeat or revisit something > that could of avoided in the first place, especially when it was known > upfront but some reason was ignored or thrown aside. Doing it right, > the first time is about producing results with higher customer > satisfaction and minimizing cost across the aboard. If the IETF had done this in this area with that in mind, then it would have been approached very differently in my opinion. > > Vendors are free to support obsolete protocols as long as they care to and > > do (witness how long it's taking to get rid of SSL V2). That's a > > separate discussion. > > Well, I personally believe that when the all issues are considered, > better decisions are made that doesn't or lowers the need to revisit > it latter. With this specific "de facto obsolete", in my view will > have a ripple effort, and quite frankly will trouble the people who > are using it, even they are just among the so called "5%" as its > claimed to be. > > Just consider, the SPF web site will be among the first to HIGHLIGHT > in whatever fashion or words, SENDER-ID was DEAD and officially > disclaimed OBSOLETE by the IETF and no longer something any domain > should to think about or bother with. I doubt the web site will be > able to resist it. Thats all part of marketing and branding! :) It won't even try. It'll probably be me that writes the text. In this working group we need to stay focused on the technical aspects of the problem. In the broader sense there are lots of opinions and perspectives, but they don't help here. I don't think any of the points about marketing are relevant to the chartered work of the group. I also don't think it matters much in the end if the draft says "de facto obsolete" or "should not be advanced" or anything other than "standards track" for Sender ID. The result will be roughly the same SPF is advanced in this working group and Sender ID is not. People will draw logical conclusions from that independent of the precise words in the draft, so I'd encourage you to not get too wrapped up in the exact wording. Scott K From hsantos@isdg.net Wed Apr 18 18:42: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 F407C11E80B2 for ; Wed, 18 Apr 2012 18:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtk6D48AFfri for ; Wed, 18 Apr 2012 18:42:09 -0700 (PDT) Received: from groups.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B11F511E80AD for ; Wed, 18 Apr 2012 18:42:08 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2149; t=1334799727; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=gv0EaCLiazK0tdA8waB4X5Ag2UY=; b=FmpdI7DFP5tJC9zJ1zAO f2xDtOQRaIF1GW82TMJDQJm0U8+mt4afnL2wgs8FzQXe59lVtHsk3uZ+j2GwwJBv dQBgjd16WHGCr5t1crPTiwFusm/2X/ZFXc/DrWw5YMYHkmNyT9zQOr724Ozi6Cd3 xBjxyaetSgI8ulpg1Kw4FlQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 21:42:07 -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 v6.4.454.1) with ESMTP id 3706549627.30007.5012; Wed, 18 Apr 2012 21:42:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2149; t=1334799395; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=Mmij4wQ JeLsD2rJSn5DL9VwHK6QXWPfAyANGQhNUPjU=; b=PRp75haoblPzhHnWoW/acy9 73QJL0w4ViWTNB++sm2w3PdWWdJ3T26+aFKAdIHpsW8m1QVxdoCuI2jTzQmng5l6 XFh6RQl8XGdj5eSQR3tqaZYnDceU/TgYrGIJ5tN91KD6DsUOqivbaxHiNk1tNqoH ffq/7sMspOCgTZypMP/Q= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Apr 2012 21:36:35 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 10483300.2083.8008; Wed, 18 Apr 2012 21:36:34 -0400 Message-ID: <4F8F6D4A.2060906@isdg.net> Date: Wed, 18 Apr 2012 21:41:30 -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: <20120418185830.18406.58572.idtracker@ietfa.amsl.com> <95370437.hRjGPMH75Q@scott-latitude-e6320> <4F8F577E.4070503@isdg.net> <2057445.Rk22vZFEzR@scott-latitude-e6320> In-Reply-To: <2057445.Rk22vZFEzR@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] I-D Action: draft-ietf-spfbis-experiment-04.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 01:42:14 -0000 Scott Kitterman wrote: >> "Getting it right... the first time!" >> >> Its not about perfection, but doing your best to avoid the obvious >> that in the end don't require you to redo, repeat or revisit something >> that could of avoided in the first place, especially when it was known >> upfront but some reason was ignored or thrown aside. Doing it right, >> the first time is about producing results with higher customer >> satisfaction and minimizing cost across the aboard. > > If the IETF had done this in this area with that in mind, then it would have > been approached very differently in my opinion. Well, I think it has for the most part. But in my opinion, its been different though the last few years with predictable outcomes that is now for the most part, proved to be costly endeavors yielding little payoff, with high barriers and expense to revisit. > In this working group we need to stay focused on the technical aspects of the > problem. Sure, but unfortunately strategic product reframing is being done. > In the broader sense there are lots of opinions and perspectives, > but they don't help here. And thats because they don't match your Os and Ps? :) > I don't think any of the points about marketing are > relevant to the chartered work of the group. But it is about Marketing. What you believe should be the technical aspects of the Problem, the opinions and perspective is all about how you think the PRODUCT should be written, should work and operate to do something useful is all about marketing the results to people who will end up using it. Been thing again I may be also cursed with another corporate QA motto and poster I still hanging on my wall: What comes first? Marketing or Technology? Do I need to explain it? :) > I also don't think it matters much in the end if the draft says "de facto > obsolete" Unfortunately, with uncertainly someone in the future will use it to throw the proverbial book at someone - "SenderID is obsolete so stop talking about it." -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From john@jlc.net Thu Apr 19 05:13: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 335DE21F848F for ; Thu, 19 Apr 2012 05:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.928 X-Spam-Level: X-Spam-Status: No, score=-105.928 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjrDkKk6K2X1 for ; Thu, 19 Apr 2012 05:13:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9B27721F8493 for ; Thu, 19 Apr 2012 05:13:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E865233C23; Thu, 19 Apr 2012 08:13:39 -0400 (EDT) Date: Thu, 19 Apr 2012 08:13:39 -0400 From: John Leslie To: spfbis@ietf.org Message-ID: <20120419121339.GI99904@verdi> References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.1i Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 12:13:41 -0000 internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SPF Update Working Group of the IETF. > > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-03.txt > Pages : 10 > Date : 2012-04-16 I want to congratulate Murray on his work here. I think it is nearly ready to send to the IESG. However... I do believe the document would be stronger with a clearer separation of data, analysis, and conclusions; and I believe the data would be much easier for the IESG to assimilate were it in table form. (Did I just volunteer to help?) ;^) -- John Leslie From spf2@kitterman.com Thu Apr 19 05: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 BE48E21F84A5 for ; Thu, 19 Apr 2012 05: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr5LIhOySIYL for ; Thu, 19 Apr 2012 05:19:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFEF21F84A0 for ; Thu, 19 Apr 2012 05:19:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8651E20E40CC; Thu, 19 Apr 2012 08:19:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334837968; bh=ClCwmpPKbSwlQI6oN6DJCyvBT7DWC1ESAo2Ii/N15Bg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=C7n2KUaNINJOnf4c/G0eSer2bNmae8B3hBQU/dbJYGC97Xj2ht80HRFTctf+MWCDf U6KQrNea8lQ1tfeSAitfOVf+hrcxOFSDrrD2t+0XyR5V9KIrVuHgLLXuPENpvgJJxU KfUsmm4abCi/XSdWtQ56MYJU60PKtNgcCiYM1l6k= Received: from scott-latitude-e6320.localnet (153.sub-97-10-78.myvzw.com [97.10.78.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3464020E408F; Thu, 19 Apr 2012 08:19:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 08:19:23 -0400 Message-ID: <3659246.TeluIKqSE4@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120419121339.GI99904@verdi> References: <20120417041138.26772.22792.idtracker@ietfa.amsl.com> <20120419121339.GI99904@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] I-D Action: draft-ietf-spfbis-experiment-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 12:19:33 -0000 On Thursday, April 19, 2012 08:13:39 AM John Leslie wrote: > internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the SPF Update Working Group of > > the IETF.> > > Title : Resolution of The SPF/Sender-ID Experiment > > Author(s) : Murray S. Kucherawy > > Filename : draft-ietf-spfbis-experiment-03.txt > > Pages : 10 > > Date : 2012-04-16 > > I want to congratulate Murray on his work here. I think it is nearly > ready to send to the IESG. > > However... > > I do believe the document would be stronger with a clearer separation > of data, analysis, and conclusions; and I believe the data would be much > easier for the IESG to assimilate were it in table form. > > (Did I just volunteer to help?) ;^) If you look at 04, I think he's a step ahead of you. Scott K From vesely@tana.it Thu Apr 19 08:26: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 D66BE21F8642 for ; Thu, 19 Apr 2012 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCqLYVGCHXQu for ; Thu, 19 Apr 2012 08:25:57 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBD121F864C for ; Thu, 19 Apr 2012 08:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334849154; bh=+leceEXINL4vEMkOhxCd9/mVW8qh12yrTItFAqCXzZw=; l=2798; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cI6R4geleltUORk+ObcVwJFHARjxEPgULi9HqE/rA2n53OXsZp2h4HG0/6Kjz7gGC ZshDuC9MavkrHbq2id7b0hywfFgYEi6aNOHimbE+TYo+ilJI0BRHSYUqE4VycgD8WL Ly6Yy+qxZgpdAU76A/6VnQKotXORzyJvDugt+Avg= 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; Thu, 19 Apr 2012 17:25:54 +0200 id 00000000005DC035.000000004F902E82.00005A76 Message-ID: <4F902E82.8080606@tana.it> Date: Thu, 19 Apr 2012 17:25:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> <4F8EF1C3.3060906@gathman.org> In-Reply-To: <4F8EF1C3.3060906@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 15:26:04 -0000 On Thu 19/Apr/2012 16:51:23 +0200 Stuart D Gathman wrote: > on 04/18/2012 10:20 AM, Alessandro Vesely would write: > >> I don't see that. Assume you're the owner of example.com. I'm >> a user of yours and also have a mailbox at someotherdomain.org. >> They let me enter a forwarding recipe from there to my mailbox at >> your domain. If they are clever, they check that I can get mail >> destined to that target address. When would they ask you, >> formally or not? > > If you expect to get your mail addressed to someotherdomain.org at > your example.com mailbox (which I run in your example), *you* need to > tell me so I can add someotherdomain.org to the authorized forwarder > list (or you can do it yourself - as a small domain, I gave you and > other users access to tools to do so should you be interested). Fair enough. That explains it perfectly clear, thank you. In one sentence, I'd summarize that as A mail server who opts to reject on fail needs to track all forwarders and whitelist them. I don't mean to propose that wording for a document, just to make the point clear. From such statement, the responsibility for breaking mail delivery seems to stay on the receiver who missed to track a forwarder. > If someotherdomain.org publishes an SPF record, that is the end of the > story (unless they relay a lot of spam and I have to block them). If > they don't publish an SPF record, I have to put my mail admin hat on > and go over logs to figure out a reasonable local SPF record (i.e. not > an official SPF record, but one my mail servers use for that domain) > that covers IPs someotherdomain.org sends from. For an alias > forwarder, that usually ends up being something like "v=spf1 > ptr:someotherdomain.org -all". That looks like a whitelisting technique. You could use any other authentication method, e.g. DKIM, depending on the forwarder and the amount of cooperation they are willing to put into it. OTOH it is yet another use of SPF: for whitelisting. > On the other hand, if somejerkdomain.org decides to start alias > forwarding some random mailbox "for your convenience" that you have no > knowledge of, that is *forgery*, and will get rejected (and the IP > banned if persistent) for any domain I administer if the sender > published an SPF record with -all (which thankfully for banks and > credit card companies, they generally do). For example, if you happen to write an I-D and publish it on the IETF site, you would get mail redirected to the address used in the I-D. That feature is probably written and fully explained somewhere, but you might happen to have missed it. If the original sender publishes a strict SPF policy, you would reject the forwarded message. Would that be your fault, then? From vesely@tana.it Thu Apr 19 08:35: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 5FD0221F86BB for ; Thu, 19 Apr 2012 08:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl4fZK1beE9q for ; Thu, 19 Apr 2012 08:35:02 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8C16021F86B8 for ; Thu, 19 Apr 2012 08:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334849700; bh=I3NCy0DJS9DEZV7GM+ZegMWHogBqh+CT5h9ItChFcTE=; l=1055; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=S5+bvy7JEdPBWnkIwDmvXng+cD22JdLH+MjMgGpQSvqlYNfGOIXdM/PPJGwz1lJiE Og6atwm8qy9tskg3UpsvnyNce61LLvJmMNd4YB1RGjwoKHpxBAUJkcDkSN21qD/lvk rUd8tFFtBdZTEma2LXeoKbOJO6xLJOVsH03Lo8DQ= 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; Thu, 19 Apr 2012 17:35:00 +0200 id 00000000005DC035.000000004F9030A4.00005CAD Message-ID: <4F9030A4.6070509@tana.it> Date: Thu, 19 Apr 2012 17:35:00 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <47685701.Z6iPPE2elv@scott-latitude-e6320> <4F8ED83D.3060908@tana.it> <1368066.mJbxKxkNYY@scott-latitude-e6320> <4F8F28C9.7000605@mail-abuse.org> <4F8F2EA4.9050206@gathman.org> In-Reply-To: <4F8F2EA4.9050206@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 15:35:06 -0000 On Thu 19/Apr/2012 17:31:07 +0200 Stuart D Gathman wrote: > on 04/18/2012 04:49 PM, Douglas Otis would write: >> >> It would be appropriate to assert "should reject" for SPF failures >> referenced by the EHLO identity, and "should not reject" when >> referenced by the bounce address. >> > +1 for SHOULD reject on EHLO fail - I've been doing that for years. > Any MTAs that had problems had *many* problems due to general > cluelessness. I did talk to a mail admin who insisted on using the > same EHLO name for all of his (dozen or so) MTAs, and the IP of the > name did not match any of them (and he was not open to listing > multiple IPs for the name in DNS), and the SPF record was for a MFROM > which (for some reason) used a completely different set of servers, > and he was mad at me for checking SPF for his EHLO and rejecting his > connections. I don't think his policies were very RFC compliant. +1 as well. (Note that a receiver has to check the helo identity before it can see whether it fails, which is already a SHOULD.) From vesely@tana.it Thu Apr 19 08:47: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 057A921F85AC for ; Thu, 19 Apr 2012 08:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xJv8yySg4Ko for ; Thu, 19 Apr 2012 08:47:17 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 637C021F861D for ; Thu, 19 Apr 2012 08:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334850436; bh=XB0OwqrCkZ/c7GS92KDo7mZR1670uh8nVHaGUuhSEfQ=; l=1189; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Rv3hQi2yunvG9/LRr2QL1vX3bw+r/pI7Yb93au2tdNnqffdUYwkS6Acl8ltJstefr nQH9bL6qe8GkqXKSNC1C/1/7CqadKR6LPG+exKneFZAREtJNtThK560x9EJKzss4dv 2nvwBlfTTwsgU30B8QkA4Xw5R94ugwTk17hfC560= 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; Thu, 19 Apr 2012 17:47:16 +0200 id 00000000005DC039.000000004F903384.00005FFA Message-ID: <4F903384.8020103@tana.it> Date: Thu, 19 Apr 2012 17:47:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> <4F8EEBD8.1090707@tana.it> <20120418165111.GM94829@mail.yitter.info> In-Reply-To: <20120418165111.GM94829@mail.yitter.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 15:47:22 -0000 On Thu 19/Apr/2012 17:37:11 +0200 Andrew Sullivan wrote: > On Wed, Apr 18, 2012 at 06:29:12PM +0200, Alessandro Vesely wrote: > >> Isn't SPF itself an attempt at fixing SMTP? It hijacks elements of the SMTP >> protocol and confers them a meaning that they didn't originally >> bear. > > No. SPF is an attempt to express something about how receivers might > want to treat a messge received using SMTP. The Internet works in > layers, and SPF sits atop SMTP. I will cheerfully grant that it is > perched there somewhat precariously, partly because it attempts to > make assertions that are sometimes false. But it is not itself > altering SMTP. Reject-on-fail was the initially proposed use of SPF. Later on, SPF results started to be used to adjust messages' score. Your description above seems to refer to the latter mode only. > There is an important difference between those two ways of looking at > things, and I want to attend to that difference. As a matter of fact, RFC 4408 openly considers legitimate to reject on fail. Thus, SPF can (and does) affect SMTP functioning. IMHO, moving from experimental to standard track must imply clarifying such issue. From hsantos@isdg.net Thu Apr 19 09:02: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 AF0B221F8531 for ; Thu, 19 Apr 2012 09:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QMkMoGMaztw for ; Thu, 19 Apr 2012 09:02:32 -0700 (PDT) Received: from mail.santronics.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1464821F856A for ; Thu, 19 Apr 2012 09:02:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2360; t=1334851339; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PhURucP5dNGP+vpdQQSp/FNujyo=; b=dxLXbepsO/7y2Zo7+dJP 24hdHp+HKWrfEZCbOW4lDcoeFs61CV83ogzb2uTJXAMIcDYwK9aWIG/kTAq9QnUW d5A6r5+7BnaGleV6OC0rGdVO4eR9YoyDFX0YoG594yGw3q2HiGXJfVfJHE/6QYI4 fQYR3LUAy4Dtn1ru8s/CyTk= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 12:02:19 -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 v6.4.454.1) with ESMTP id 3758160139.30828.4212; Thu, 19 Apr 2012 12:02:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2360; t=1334851005; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GtECydS qSwK5oJ9/slnTOlOpKYPMoPj/AF1OtjyZSWk=; b=iH6v/zyDrXwsn3NBwR+mA0T GNnAEqxKg49RC+IfVkILCmRZODThuiuCYqrjTRk3yQYfP5+Up+eau8gyXwdnmhEx 7Lnh4/isQId2gqWHiVdHukLVBcvW6+DDOBx7MqtI2+F1qSipZwciG8enBdFxKpVm /rGvFaGVaV13cu3zH7do= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 11:56:45 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 62092659.2143.3404; Thu, 19 Apr 2012 11:56:43 -0400 Message-ID: <4F9036D8.2050105@isdg.net> Date: Thu, 19 Apr 2012 12:01:28 -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: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> <4F8EF1C3.3060906@gathman.org> <4F902E82.8080606@tana.it> In-Reply-To: <4F902E82.8080606@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 16:02:37 -0000 Alessandro Vesely wrote: > On Thu 19/Apr/2012 16:51:23 +0200 Stuart D Gathman wrote: >> If you expect to get your mail addressed to someotherdomain.org at >> your example.com mailbox (which I run in your example), *you* need to >> tell me so I can add someotherdomain.org to the authorized forwarder >> list (or you can do it yourself - as a small domain, I gave you and >> other users access to tools to do so should you be interested). > > Fair enough. That explains it perfectly clear, thank you. In one > sentence, I'd summarize that as > > A mail server who opts to reject on fail needs to track all > forwarders and whitelist them. Hasn't that been the case - for any system with mail filtering methods? The one thing to remember is that BAD GUYS do not complain - only GOOD GUYS. From our experience, it happens but very rare which, for the most part, justifies the actions because the payoff is high to reject the bad guys with zero-false positive rejects. Nonetheless, there are people do use either SPF wrong or specific streams are being sent to a host for relaying and real false positives occur. But in our experience, you whitelist them as they are reported. Rest assured, if this was a BIG problem or just bothersome, I would never had supported SPF and doubt it would of gotten wide support. But the fact is, at least in our experience and lack of reports from customers experience, its a rare issue. Also it doesn't pay to get into the blame game - just tell them to whitelist whoever the "important" sender that is failing and problem solved. There have been many customers that had problem and just turned SPF off or another filter off and almost always the spams always went up and they turned it back on, but paid attention in fine tuning the settings and doing a lot more in the area of whitelisting. One tip which has proved very useful. For our system, we have an auto white listing method where if the site account users sends out email to people, the expectation is that they known the target address and the target address is auto white listed for the FROM::TO pair. So when I did my first offlist email to you, your address was automatically whitelisted and the SPF, GREYLISTING crap is skipped! -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Thu Apr 19 09:13: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 6626721F84D8 for ; Thu, 19 Apr 2012 09:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfJEMLva2+aT for ; Thu, 19 Apr 2012 09:13:21 -0700 (PDT) Received: from mail.santronics.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1D21F84D5 for ; Thu, 19 Apr 2012 09:13:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2139; t=1334851994; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=KXxTRdgf6dT1F/VPy/AWrHwivxA=; b=wK/Ft+dej5kDmjiRMSJe D/7Coc3j0qVGAVIOeihGSjTSDHUsGPMJlxafZOcWaqNd0FnlN6nhUlX2q/YZNhdn 0UlICHpZKuYOdGFxwbp77EYIm9G0WHceqRbpAZBDwnFHeP7g+odJ77rImayxQXZZ Yp4hIw1JsQr7T8H6G8kXZsg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 12:13:14 -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 v6.4.454.1) with ESMTP id 3758815266.30828.6128; Thu, 19 Apr 2012 12:13:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2139; t=1334851661; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=RNEAhYf sEmInwvEdzsIhhPRUAu6JLxA3Qy2enKLVyi8=; b=IWBNqymhcKsTgApRhNtidvx aJU+l1KbpAzohZ+M4M0P8Nizaw0ECF204+GudYfTExizOhF+X4DW0Q/78FKbtdMI q27tcOpeVqbfm4NGR8S0T65KEG9aDB7jdMVolfInUZ8XB5gHcKnYUnZGWgqV92L0 m25EShN6J5O4R5mK57Hg= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 12:07:41 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 62749159.2145.5500; Thu, 19 Apr 2012 12:07:40 -0400 Message-ID: <4F90396E.4040700@isdg.net> Date: Thu, 19 Apr 2012 12:12:30 -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: <20120418143751.6295.qmail@joyce.lan> <4F8EDA47.4070200@tana.it> <20120418153255.GH94829@mail.yitter.info> <4F8EEBD8.1090707@tana.it> <20120418165111.GM94829@mail.yitter.info> <4F903384.8020103@tana.it> In-Reply-To: <4F903384.8020103@tana.it> 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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 16:13:26 -0000 Alessandro Vesely wrote: > On Thu 19/Apr/2012 17:37:11 +0200 Andrew Sullivan wrote: >> On Wed, Apr 18, 2012 at 06:29:12PM +0200, Alessandro Vesely wrote: >> >>> Isn't SPF itself an attempt at fixing SMTP? It hijacks elements of the SMTP >>> protocol and confers them a meaning that they didn't originally >>> bear. >> No. SPF is an attempt to express something about how receivers might >> want to treat a messge received using SMTP. The Internet works in >> layers, and SPF sits atop SMTP. I will cheerfully grant that it is >> perched there somewhat precariously, partly because it attempts to >> make assertions that are sometimes false. But it is not itself >> altering SMTP. > > Reject-on-fail was the initially proposed use of SPF. And still is. > Later on, SPF > results started to be used to adjust messages' score. Isolated solutions, heuristic methods not not univerisal standards material and more importantly only for relayed policies where there was no REJECT-ON-FAIL policy condition to process. > Your description above seems to refer to the latter mode only. And I hope that mindset does not continue to permeate the framework to alter the purpose of REJECT-ON-FAIL deterministic nature of SPF. That would be a major show or endorsement and adoption stopper. Please stop trying to make it into worthless protocol with relaxed provisions that will do nothing more but add more overhead to DNS and the receiver and foremost does NOTHING to solve the abuse of domains and the major abuse the receivers gets are targets of the junk mail. > As a matter of fact, RFC 4408 openly considers legitimate to reject on > fail. Thus, SPF can (and does) affect SMTP functioning. Only on the positive side in allowing what it could not do before. Its like 4409, if you connect to a SUBMIT server, on purpose via port 587, knowing full well you are required to have an account to login, then that ACTION authorizes the MSA SMTP server to do a lot more it could not do before on a public port 25 server. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Thu Apr 19 09:40: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 A4E1C21F86D1 for ; Thu, 19 Apr 2012 09:40:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM1QoLFqkP+4 for ; Thu, 19 Apr 2012 09:40:00 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 90C9721F86CB for ; Thu, 19 Apr 2012 09:40:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zsg01i0020ZaKgw01sg0kd; Thu, 19 Apr 2012 09:40:00 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=FZaKjXq_BXoA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=A6i4I0diIpbzHeUZ0z0A:9 a=Zgi3CB3oyJzY-0NdZSYA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 09:40:00 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNCnAQrevpLEddWEGgMhE/xgvzTZaKuN0AgACVPoCAAEPxAIABd7UAgBNbTYCAANg3gIAAKweAgAF5mAD//53TgA== Date: Thu, 19 Apr 2012 16:39:59 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FACEE@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> <4F8EF1C3.3060906@gathman.org> <4F902E82.8080606@tana.it> In-Reply-To: <4F902E82.8080606@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334853600; bh=/bg5uRXU8sppy46TQ5EB6UluxlrGq7PAR3UnYGf63/A=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=b2Le12btXiMApDESKeuJNqpulMOrfmQCZF5iPcZcLt3oOHxo/7c1fSPo4QLa1G4mi 6MCLDa2SmLDKbflG/k42IpJJdK+lK/5QMhZqeudhJDcygT2WT/MsEjnXJK5z+tzql1 maAZW7/96cRkcX9JFw/Ayd5D6KdeNn0vEV6+/TbQ= Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 16:40:04 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Thursday, April 19, 2012 8:26 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 > A mail server who opts to reject on fail needs to track all > forwarders and whitelist them. For this to appear in a standards document, you'll need to categorize exact= ly how one would identify a forwarder in a reliable way. Mostly though it seems like we're hinting at some heuristics to improve on = SPF's general accuracy. I suspect a collection of these might be useful to= document someplace but I'm skeptical about putting them in SPFbis itself (= though see also my suggestion about appendices and a separate operations do= cument). -MSK From spf2@kitterman.com Thu Apr 19 09:45: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 498CD21F86F6 for ; Thu, 19 Apr 2012 09:45:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRk6hYp0N-vX for ; Thu, 19 Apr 2012 09:45:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0442121F85B1 for ; Thu, 19 Apr 2012 09:45:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5B47720E40CC; Thu, 19 Apr 2012 12:45:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334853942; bh=GT6mLNC+dkZVUirlZvPJX8kMdHNctpitQKGeK3Y3WmQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=EK8JLiPj/vFe1UsN6PfyiztOmx6TrCURU1jMI9vtkvAYYejZVyKhGLb3qRnFrbiib LdhvRd/Ef9se0hZ7qBTAHFFSnLkrcb6FUe/WhjSTWoVOorVW00NBWAArBE7jMP8kC7 T4+VHdIbwVAbt3fT1/cAsxYpgttVLj/PeFnfm62s= Received: from scott-latitude-e6320.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 ESMTPSA id 41DC320E408F; Thu, 19 Apr 2012 12:45:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 12:45:41 -0400 Message-ID: <1411716.v9dQfoyIUs@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FACEE@exch-mbx901.corp.cloudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <4F902E82.8080606@tana.it> <9452079D1A51524AA5749AD23E0039280FACEE@exch-mbx901.corp.cloudmark.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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 16:45:47 -0000 On Thursday, April 19, 2012 04:39:59 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Alessandro Vesely Sent: Thursday, April 19, 2012 8:26 AM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo > > identities> > > A mail server who opts to reject on fail needs to track all > > forwarders and whitelist them. > > For this to appear in a standards document, you'll need to categorize > exactly how one would identify a forwarder in a reliable way. > > Mostly though it seems like we're hinting at some heuristics to improve on > SPF's general accuracy. I suspect a collection of these might be useful to > document someplace but I'm skeptical about putting them in SPFbis itself > (though see also my suggestion about appendices and a separate operations > document). It's in RFC 4408 9.3.3.1 already. Scott K From johnl@iecc.com Thu Apr 19 09:48: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 9FC5D21F8557 for ; Thu, 19 Apr 2012 09:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.989 X-Spam-Level: X-Spam-Status: No, score=-110.989 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh6bNuezebfz for ; Thu, 19 Apr 2012 09:48:07 -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 3FD9921F8559 for ; Thu, 19 Apr 2012 09:48:05 -0700 (PDT) Received: (qmail 65933 invoked from network); 19 Apr 2012 16:48:03 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Apr 2012 16:48:03 -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=4f9041c3.xn--30v786c.k1204; i=johnl@user.iecc.com; bh=ZdQkBW2bxkaAGdEBjSMcvxksvxt0tgZ49bY8SWHTth8=; b=DN37p0caDmwb+ZSZhSPuEx3LLYX68Qkm1L9R9XXeuw2io7cxiIUaSoo6o0RL2qx8P+AQoDCnqGas0nM8qeDCLKVo1yNzsdtThsgxI9/Q0pUL+8bdUZyEJ+8goaKIRWeo0WocySR6Vh6pZm9gp7AZMO/wuTkV0aPfMCA9EEDP0K0= 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=4f9041c3.xn--30v786c.k1204; olt=johnl@user.iecc.com; bh=ZdQkBW2bxkaAGdEBjSMcvxksvxt0tgZ49bY8SWHTth8=; b=SdGkfjaYmgk+PtVjmda9SaxLln4GwFGHhNdKLVRScn+B0G9XqPzhlq5MxwHnm/Yu4LpNuCOaeBruTNBh+e9wHovkbUdrzUjjyLLPVk+ABAhIO8dq7OgKcmxLamlUQXqArYbxxswBi7vzina7Oek5V7XxyVANV7912tKe+EPlRSU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Apr 2012 16:47:41 -0000 Message-ID: <20120419164741.60726.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F9030A4.6070509@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 16:48:14 -0000 >> +1 for SHOULD reject on EHLO fail Absolutely not. The SPF spec is about how you come up with an SPF result given envelope information. It does not say anything about what you do with the result. Should this group be so ill-advised as to start putting MTA design advice into 4408bis, I doubt that I would be the only one to object. Since the charter makes it abundanrly clear that we're not going to do that, I will stop saying anything more on this topic, and I really wish that other people would, too. R's, John From hsantos@isdg.net Thu Apr 19 10:05: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 CCD2F21F8647 for ; Thu, 19 Apr 2012 10:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRZz8HrDm2WD for ; Thu, 19 Apr 2012 10:05:11 -0700 (PDT) Received: from ntbbs.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7796321F863C for ; Thu, 19 Apr 2012 10:05:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=960; t=1334855108; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PMouFvF6m+VXE84GTOUw25IWF6I=; b=f2KbBCuObh3YJLpEy+uw 8JR8UaQS4U1Ap4ANr5kvpxK12xQ96VntCDL1e7bO2zqRfqnAwBqdwIzsqN974+MM zauMNNI+oLmeKABtB/c/rmH+psXHhW0+N6gK/K1Vi08RZXpNoEHPL3AlyXyNhFwx AicV12Uzz/iKP2USnYJaGPw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 13:05:08 -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 v6.4.454.1) with ESMTP id 3761930325.30828.6044; Thu, 19 Apr 2012 13:05:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=960; t=1334854777; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6HeUaou ZbllNvR5kEJyv5IVaFkj+gzeWk0+cSIlxcZ4=; b=INins9m4a/jSSBPjS7bnwdA +kUlkFoWQr7Ce4n7IYhafpeol4g4o6f+bfMvL6cmoVScANYj6YS7RTKZgTg30ctK tfpLFUiYZtyecT7UOrl7sIjhrZVGGgVnc3YBZbMOE1vMqJs0GtAlOr6uQ9hdtWr5 hGpUHjJI+MH2YzCA48lo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 12:59:37 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 65864722.2149.2076; Thu, 19 Apr 2012 12:59:35 -0400 Message-ID: <4F9045AF.9020403@isdg.net> Date: Thu, 19 Apr 2012 13:04:47 -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: <20120419164741.60726.qmail@joyce.lan> In-Reply-To: <20120419164741.60726.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 17:05:16 -0000 John Levine wrote: >>> +1 for SHOULD reject on EHLO fail > > Absolutely not. The SPF spec is about how you come up with an SPF > result given envelope information. It does not say anything about > what you do with the result. Should this group be so ill-advised > as to start putting MTA design advice into 4408bis, I doubt that I > would be the only one to object. Hmmm, but you always did object since day one. The SPF specs was always very clear about actionable recommendations: SHOULD REJECT ON A DOMAIN POLICY HARDFAIL (-ALL) We know you and others in the same camp didn't like that, believing domains didn't know what they were doing since day one, but the super vast majority disagreed and SPF was wildly and widely endorsed and deployed with the REJECT-ON-FAIL logic despite the MX receiver possibly forwarding the mail to outside its network. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From ajs@anvilwalrusden.com Thu Apr 19 10:17: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 2685721F86B8 for ; Thu, 19 Apr 2012 10:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k8YLaC5bDJR for ; Thu, 19 Apr 2012 10:16:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89921F86B6 for ; Thu, 19 Apr 2012 10:16:59 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id EE0A01ECB41D for ; Thu, 19 Apr 2012 17:16:58 +0000 (UTC) Date: Thu, 19 Apr 2012 13:16:57 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120419171652.GB94829@mail.yitter.info> References: <20120419164741.60726.qmail@joyce.lan> <4F9045AF.9020403@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9045AF.9020403@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 17:17:00 -0000 No hat. Please forgive the intrusion by someone who doesn't know anything, but On Thu, Apr 19, 2012 at 01:04:47PM -0400, Hector Santos wrote: > Hmmm, but you always did object since day one. The SPF specs was > always very clear about actionable recommendations: > > SHOULD REJECT ON A DOMAIN POLICY HARDFAIL (-ALL) I am unable to find in section 2.5, "Interpreting the result", of RFC 4408 the idea of a policy hardfail. Maybe you mean "Fail", section 2.5.4. If so, then that section is not consistent with what you say. It says this: A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright. There is no SHOULD there, and there is no RFC 2119 language at all. This is, according to that text at least, purely a matter of local policy. Now, with my chair hat on (I haven't discussed this with SM, but it's not like he hasn't said similar things recently): Unless I see some argument _based on the text in RFC 4408_, and quoting it, that any of this rejection stuff is in fact on-charter, I have to ask people to stop discussing it. Our charter is very clear: we need to alter the specification as little as possible except to clarify things, and to specify widely-adopted variations (either explaining widely-adopted features or leaving out unused things). In effect, changes should be uncontroversially rooted in empirical data. Since there is, AFAICT, empirical disagreement about what people are doing, SHOULD reject is a modification of the protocol and won't meet the test. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Thu Apr 19 11:15: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 2951721F85D1 for ; Thu, 19 Apr 2012 11:15:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZYFr3f5LHvA for ; Thu, 19 Apr 2012 11:15:51 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 72AAC21F85F0 for ; Thu, 19 Apr 2012 11:15:51 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zuFJ1i0010ZaKgw01uFJET; Thu, 19 Apr 2012 11:15:18 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=lz1Bw0MJaowA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=C18EASGpfdAD27lHOxMA:9 a=R6cv8nIGzp4Y66f6CwYA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 11:15:18 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNHk6mP4XsbbYFKECUBYiUFRHGr5ai2S2A//+W/GA= Date: Thu, 19 Apr 2012 18:15:18 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FAF6E@exch-mbx901.corp.cloudmark.com> References: <20120419164741.60726.qmail@joyce.lan> <4F9045AF.9020403@isdg.net> <20120419171652.GB94829@mail.yitter.info> In-Reply-To: <20120419171652.GB94829@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334859318; bh=lfObca5Q2OF51nWl3SEq3t5mBFAuNgiRrYbxUSOJP2g=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=kE3DfVpYAQi2T3NKtOSYdygTPiJPXYCEegisyV0Oe4YkRHjZbfZvU7YNNaFLLU/tr e6UnTSQXXyh4+W/wNwknA1vKkV/JVLb/mHxViKsR5Dnua3UfE0vAu8fOm7mFjrdZYR /aOkyNuHJ5yk8fw2bGJv8gfEMMvbmHgtOWaZYoQM= Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 18:15:52 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Thursday, April 19, 2012 10:17 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo ident= ities >=20 > I am unable to find in section 2.5, "Interpreting the result", of RFC > 4408 the idea of a policy hardfail. Maybe you mean "Fail", section > 2.5.4. If so, then that section is not consistent with what you say. > It says this: >=20 > A "Fail" result is an explicit statement that the client is not > authorized to use the domain in the given identity. The checking > software can choose to mark the mail based on this or to reject the > mail outright. >=20 > There is no SHOULD there, and there is no RFC 2119 language at all. > This is, according to that text at least, purely a matter of local > policy. I checked all the way back to the original Meng Weng Wong document (thanks = for the link, Scott). Rejection on fail was never a MUST or even a SHOULD. SPF is input to local policy only. It could be one's local policy to do ex= actly what SPF says, and it may even be almost doctrine for some people tha= t the whole Internet should work that way, but that's not what the document= has ever said. The same goes for DNSBLs (RFC5782) and ADSP (RFC5617). DKIM even goes the = opposite way, saying a failed signature isn't grounds for rejection. -MSK From sm@resistor.net Thu Apr 19 11:41: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 1A12811E80C6 for ; Thu, 19 Apr 2012 11:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pUR9-IuwHbF for ; Thu, 19 Apr 2012 11:41: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 46A8711E80C4 for ; Thu, 19 Apr 2012 11:41:25 -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 q3JIfKwO005244 for ; Thu, 19 Apr 2012 11:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334860884; i=@resistor.net; bh=bxm4ssg9cZ2ADRQKbkZNQfqAYxez3sCHveO/2df55s8=; h=Date:To:From:Subject:Cc; b=c/c97GYwZV/iDtIlBUwyIPWCVqwmibjmKMW87DGa9FQUMvFc/yftn4X8keF+xgClk +6z19x3LsTqT9jmCMOUrusoxvLuo1f1hQT5n2Pg6cIj4TZ5i2f0iOXSVm88tfdkoZL cnsh01EaDdBjaOmArktw75a4VsyniPoknmY3QugA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334860884; i=@resistor.net; bh=bxm4ssg9cZ2ADRQKbkZNQfqAYxez3sCHveO/2df55s8=; h=Date:To:From:Subject:Cc; b=tB/E1a+ULNXL/i4qClZ2+tWKcjenp3R28o0gKGzqg0uQos4/tC8NQK208VJrSC/hn pci6AzsaGBEkXM5IzEyj3Emc6dB4Ww6JRCHk+NVb9GzErn4m/vxeb/G1ph/BwYgKwr RMSUxdDesPpPFP8XImMADTIFbTOGGrxoNH1/nmYc= Message-Id: <6.2.5.6.2.20120419110129.09902380@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Apr 2012 11:40:57 -0700 To: spfbis@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 18:41:29 -0000 Hello, These comments on draft-ietf-spfbis-experiment-04 are merely editorial. It's not a review. In Section 1: "over a period of two years from publication in order to determine a" I suggest: from the date of publication. In Section 2.1: "Two large-scale DNS surveys were run that looked for the two" I suggest adding a reference to RFC 1035. BTW, DNS RR Type could be used throughout the draft for consistency. In Section 2.2: "It is likely impossible to determine from a survey which MTAs (Mail Transfer Agents)" Reverse the MTAs and the term in full (expand on first use). In Section 2.2: "The [OPENSPF] web site maintains a list of known implementations" I would drop known as it cannot list what is unknown. In Section 2.3: "An unknown number of clients implement SUBMITTER." I suggest: SMTP clients. "An active survey was done of a large number of running and publicly reachable MTAs." What is an active survey? "The vast majority of the MTAs advertising SUBMITTER were different instances of one MTA. That MTA was a mail filtering service, which reports that about 11% of all observed SMTP sessions involve clients that make use of SUBMITTER." I suggest The vast majority of the MTAs advertising the SUBMITTER SMTP extension were different instances of one MTA. It was reported by the mail filtering service operating that MTA that about 11% of all observed SMTP sessions involved SMTP clients that make use of the SUBMITTER SMTP extension. In Section 5: "It is standard procedure within the IETF to document as standard those protocols and practices that have come into sufficient common use as to become part of the basic infrastructure." I would drop this. The charter already allows 4408bis to be published on the Standards Track. "In light of the this and the analysis in the previous section, the working group recommends to the IESG the following:" We are not talking as a working group or to the IESG here. This is an IETF document. "The experiment comprising the series of RFCs defining the SUBMITTER SMTP extension, the Sender-ID mechanism, the Purported Responsible address algorithm, and SPF, should be considered concluded." I would rewrite this as: The experiments documented in RFC 4405, RFC 4406, RFC 4407 and RFC 4408 are considered as concluded. In Appendix A: "the rigors of the RFC publication process." I suggest "Internet Standards Process". "Later, after type 99 was assigned" I would say publication of RFC 4408 (Andrew might know about the procedure at that time). "document, in fact), a plan was put into place to effect a gradual" Why the plan is not documented? It would be easier to say that (DNS) RR Type 99 did not see widespread adoption for: 3. the substantial deployed base was already using RR Type 16, and it was working just fine, leading to inertia; And move (3) to the top. "[SPF] itself included a faulty transition plan, likely because of the late addition of a requirement to develop one: It said a server SHOULD publish both types and MUST publish at least one, while a client can query either or both, which means both can claim to be fully compliant while failing utterly to interoperate." I would put this to lack of IETF review. "It is likely that this will happen again if the bar to creating new RR types even for experimental development purposes is not lowered" Why? :-) Regards, -sm From WebMaster@Commerco.Net Thu Apr 19 12:55: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 EC51E21F867B for ; Thu, 19 Apr 2012 12:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRlpWa7c3mWR for ; Thu, 19 Apr 2012 12:55:27 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0967B21F8671 for ; Thu, 19 Apr 2012 12:55:26 -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=bfy+A5XMK1VCHlrCFIuSih/iTZDL8fQxrVhXGZ5JYdviSgfCEuUBFEoVH9CMKyILOwtIIWd07F3G0j+gEJzDTTBIOWyCbyrb/mhCGUY5CKs8otSkft1UJrekkMXhiPzoUoBj/YWxwq8aOqgB9lphlLjzfGl7IE16eShxp1hMIB0= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Thu, 19 Apr 2012 19:55:25 +0000 Message-ID: <4F906DA7.3020604@Commerco.Net> Date: Thu, 19 Apr 2012 13:55:19 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120419164741.60726.qmail@joyce.lan> <4F9045AF.9020403@isdg.net> <20120419171652.GB94829@mail.yitter.info> <9452079D1A51524AA5749AD23E0039280FAF6E@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FAF6E@exch-mbx901.corp.cloudmark.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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 19:55:28 -0000 On 4/19/2012 12:15 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Andrew Sullivan >> Sent: Thursday, April 19, 2012 10:17 AM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities >> >> I am unable to find in section 2.5, "Interpreting the result", of RFC >> 4408 the idea of a policy hardfail. Maybe you mean "Fail", section >> 2.5.4. If so, then that section is not consistent with what you say. >> It says this: >> >> A "Fail" result is an explicit statement that the client is not >> authorized to use the domain in the given identity. The checking >> software can choose to mark the mail based on this or to reject the >> mail outright. >> >> There is no SHOULD there, and there is no RFC 2119 language at all. >> This is, according to that text at least, purely a matter of local >> policy. > > I checked all the way back to the original Meng Weng Wong document (thanks for the link, Scott). Rejection on fail was never a MUST or even a SHOULD. > > SPF is input to local policy only. It could be one's local policy to do exactly what SPF says, and it may even be almost doctrine for some people that the whole Internet should work that way, but that's not what the document has ever said. > > The same goes for DNSBLs (RFC5782) and ADSP (RFC5617). DKIM even goes the opposite way, saying a failed signature isn't grounds for rejection. > > -MSK True. What is actually done with any email message received at the receiver end is (rightly so) really up to the receiver. That said, there is an expectation that basic SMTP standards are being followed. From an SPF RR publisher's point of view, I think that there are really two major SPF behavioral cases which are generally hoped for and indeed, from experience, generally work well in SPF. In the first case, if a publisher states that a domain under the publisher's control is not a sender of email - [e.g., example.com publishes TXT "v=spf1 -all"] - then the publisher has done their job saying that the domain, under the publisher's control, does not send email. Logically, if a receiver is SPF aware and respects what SPF is all about, then the receiver of a message (who actually checks for an SPF TXT/SPF RR) probably wants to destroy that message as soon as possible, because, as per the domain name publisher, it is bogus. However a receiver can do as they choose with the message, as long as, if their receiving software is SPF aware, that they never deliver it to the recipient with the publisher's domain name, as it damages the reputation of the publisher's domain name, which is why publishers elected to publish the DNS record in the first place. In the second case, if a publisher states that a domain under its control [e.g., example.net] is a sender of email - [e.g., TXT "v=spf1 ip4:192.168.123.10 ip4:192.168.111.20 -all"] - or other domains under the publisher's control have included another domain the publisher uses to send its messages [e.g., the case of example.org publishing TXT "v=spf1 include:example.net -all"] - then the publisher hopes the receiver will accept the message and process it in whatever way the receiver chooses to do so (e.g., checking for spam, virus checks, SMTP and other BL checks, etc). Again, logically, in this case, the receiver has the power to deliver the message after whatever predetermined steps are taken or not taken after receiving the message. As a publisher, we don't care at that point, except obviously, at the time of the SMTP exchange, to be told if the message was accepted for delivery or not (and just as obviously, if not, why not). We are all painfully aware that the above logic won't work in some specific situations (e.g., some forwarding cases), but in most cases, it will work just fine (and has for many years at least around here). Alan M. From msk@cloudmark.com Thu Apr 19 13:38: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 C4A0D11E80A3 for ; Thu, 19 Apr 2012 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSP9Iv9QqD4p for ; Thu, 19 Apr 2012 13:38:29 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 01AAD21F862F for ; Thu, 19 Apr 2012 13:38:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zwem1i0020as01C01wemyb; Thu, 19 Apr 2012 13:38:46 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=TiCrV9Jd9rwA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=jy50taidhFGA8XVBTrgA:9 a=CjuIK1q_8ugA:10 a=syFo6lixPLWwgHKA1x0A:9 a=tNgwR4x9EFoY5U9RkxoA:7 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 13:38:28 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: Proposed IESG Statement on the Conclusion of Experiments Thread-Index: Ac0ea1trQ6bEEENVRsKUUaoiCTZbygAAPnpw Date: Thu, 19 Apr 2012 20:38:28 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FB328@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/mixed; boundary="_002_9452079D1A51524AA5749AD23E0039280FB328exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334867926; bh=fI6ml4m4aD15eugb8NyIHrt9NPIshLZvoiE99GWb22A=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=fjVFuUew2Ocp5h9CHJBHjWy1OlxrbkEtD43ezuG5tuRQBJBKxLjpgJ0YiZWX4Oj6s MnoNe4wRAxJff1vGlKkbcwckJLw1aOjc6LCo9bB9WZCGyBDlipLzw4N04qAdZehM00 5s2bcl8ICvivZVVGei6ecDSaUx1MYUGULlr38uhY= Subject: [spfbis] FW: Proposed IESG Statement on the Conclusion of Experiments X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 20:38:29 -0000 --_002_9452079D1A51524AA5749AD23E0039280FB328exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps some of this is relevant to what we're doing in the experiment docu= ment. Timely... -MSK --_002_9452079D1A51524AA5749AD23E0039280FB328exchmbx901corpclo_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Thu, 19 Apr 2012 20:38:26 GMT"; modification-date="Thu, 19 Apr 2012 20:38:26 GMT" Received: from mail.cloudmark.com (208.83.136.25) by ht2.cloudmark.com (172.22.10.81) with Microsoft SMTP Server id 14.1.355.2; Thu, 19 Apr 2012 13:31:29 -0700 Received: from mail.ietf.org ([12.22.58.30]) by mail.cloudmark.com with bizsmtp id zwXn1i0020f7nZY01wXnwC; Thu, 19 Apr 2012 13:31:47 -0700 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8393211E80B7; Thu, 19 Apr 2012 13:31:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83C911E80A3; Thu, 19 Apr 2012 13:31:17 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byglG3TIFGEL; Thu, 19 Apr 2012 13:31:17 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0690C11E808D; Thu, 19 Apr 2012 13:31:16 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3JKVFo5008539; Thu, 19 Apr 2012 21:31:15 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3JKVA9d008506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Apr 2012 21:31:12 +0100 From: Adrian Farrel To: "ietf@ietf.org" , "wgchairs@ietf.org" CC: "iesg@ietf.org" Subject: Proposed IESG Statement on the Conclusion of Experiments Thread-Topic: Proposed IESG Statement on the Conclusion of Experiments Thread-Index: Ac0ea1trQ6bEEENVRsKUUaoiCTZbyg== Sender: "ietf-bounces@ietf.org" Date: Thu, 19 Apr 2012 20:31:14 +0000 Message-ID: <0f6601cd1e6b$5ff2e420$1fd8ac60$@olddog.co.uk> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "adrian@olddog.co.uk" Content-Language: en-GB X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: exch-htcas902.corp.cloudmark.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334867507; bh=ikbPNPj62dxzW6PUaQci9xYI4kU93W5A7luRXfg1ypg=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:Cc:Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Sender; b=fNLfUHPID5XdHMEpE7uxDbn1+jerM4zbpNjje5JNfyixPW2l2+/cpWx23P2u8BDOA 9eC4c/MQfrwk8jnZez3RQMa8QpV4Z2h3RVVtIFItB3YqWzKBV0mfmt/+JHY2N8kwOh iygZLuGxXrFuA8siYrDtvlhbUpkDbeINxIcF8JmA= list-id: IETF-Discussion x-mailman-version: 2.1.12 x-beenthere: ietf@ietf.org errors-to: ietf-bounces@ietf.org list-post: list-archive: x-spam-status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] x-spam-score: -2.351 x-virus-scanned: amavisd-new at amsl.com x-spam-level: x-original-to: ietf@ietfa.amsl.com delivered-to: ietf@ietfa.amsl.com x-spam-flag: NO authentication-results: mail.cloudmark.com; dkim=pass header.d=ietf.org header.b=X3fA39OX x-cmae-score: 0.00 x-cmae-analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=GU4rwa5YvsQnE15YQEkOQw==:17 a=6HwGycsNtxwA:10 a=tlou1PItP6UA:10 a=_kglsCk_fKQA:10 a=wPDyFdB5xvgA:10 a=3kmRFdHsXxAA:10 a=kj9zAlcOel0A:10 a=syFo6lixPLWwgHKA1x0A:9 a=tNgwR4x9EFoY5U9RkxoA:7 a=CjuIK1q_8ugA:10 a=GU4rwa5YvsQnE15YQEkOQw==:117 Content-Type: text/plain; charset="us-ascii" Content-ID: <8B51B1A8D87E254691F40B3AEAB3CDD7@cloudmark.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 All, The IESG has been discussing how to tidy up after Experimental RFCs. We have developed the following draft IESG statement. This does not=20 represent a change in process, and continues to value Experimental RFCs as an important part of the IETF process. It does, however, seek to=20 encourage documentation of the conclusion of experiments. We are aware that there may be other discussion points around=20 Experimental RFCs, and we would like to discuss these, but we also believe that there is merit in making small, incremental improvements. The IESG would welcome your thoughts on this draft before they approve the final text on April 26th. Thanks, Adrian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IESG Statement on Conclusion of IETF Experiments Experiments are an established and valuable part of the IETF process. A number of core Internet protocols were first published as Experimental RFCs while the community gathered experience and carefully investigated the consequences of deploying new mechanisms within the Internet. In the case where an experiment leads on to the development of a =20 Standards Track RFC documenting a protocol, the new RFC obsoletes the=20 old Experimental RFC and there is a clear conclusion to the experiment. However, many experiments do not lead to the development of Standards Track RFCs. Instead, the work may be abandoned through lack of interest or because important lessons have been learned. It is currently hard to distinguish between an experiment that is still being investigated, and an old experiment that has ceased to be of interest to the community. In both cases an Experimental RFC exists in the repository and newcomers might easily be misled into thinking that it would be helpful to conduct more research into an abandoned experiment. In view of this, the original proponents of experiments (that is,=20 authors of Experimental RFCs, and Working Groups that requested the publication of Experimental RFCs) are strongly encouraged to document the termination of experiments that do not result in subsequent Standards Track work by publishing an Informational RFC that: - very briefly describes the results of the experiment - obsoletes the Experimental RFC - if appropriate, deprecate any IANA code points allocated for the=20 experiment - may request that the Experimental RFC is moved to Historic status. If there is no energy in the community for the producing such an Informational RFC, if the authors have moved on to other things, or if the Working Group has been closed down, Area Directors should author or seek volunteers to author such an Informational RFC. --_002_9452079D1A51524AA5749AD23E0039280FB328exchmbx901corpclo_-- From msk@cloudmark.com Thu Apr 19 14:09: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 BAD7311E80BA for ; Thu, 19 Apr 2012 14:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnpRI26T2E10 for ; Thu, 19 Apr 2012 14:08:57 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC4C11E8089 for ; Thu, 19 Apr 2012 14:08:57 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zx8w1i0010ZaKgw01x8w4b; Thu, 19 Apr 2012 14:08:56 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=8Ubwy9MkvaUA:10 a=VCNWc_7EECYA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=EggRjUoFa_RzXwChjO4A:9 a=_AozAdkJ1_kc61WCtHgA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=rGmYq1oxbIa4mHxE:21 a=8VD8uBpxh76qf-5y:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 14:08:56 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Comments on draft-ietf-spfbis-experiment-04 Thread-Index: AQHNHlwPBAjSL+wn80usOh3DX4DEbpainlhg Date: Thu, 19 Apr 2012 21:08:55 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> In-Reply-To: <6.2.5.6.2.20120419110129.09902380@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334869736; bh=eNHiX4BIwSRMmVcK8CCe0P+VlMpYGgwp0BuCdJqYWP4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=fmhj5zmIUvxrtkFIuIo3Eh+VnFdYJMK/J/iaeEjHGT3bnv/+iiLChgJHQtXfNK5zK E2n+ZNF4El/38IyOYkokQiwSXybvXv8canRAzja986B1D0dryQ6Ifd8HqZ9GyGS2XB ckWt77M5vvRWvZxjg5RLSAuGqY/jlUv5p+dBhGQw= Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 21:09:00 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of SM > Sent: Thursday, April 19, 2012 11:41 AM > To: spfbis@ietf.org > Subject: [spfbis] Comments on draft-ietf-spfbis-experiment-04 >=20 > Hello, >=20 > These comments on draft-ietf-spfbis-experiment-04 are merely editorial. > It's not a review. >=20 > In Section 1: >=20 > "over a period of two years from publication in order to determine > a" >=20 > I suggest: from the date of publication. OK. > In Section 2.1: >=20 > "Two large-scale DNS surveys were run that looked for the two" >=20 > I suggest adding a reference to RFC 1035. OK (though done earlier, since that's not the first reference to the DNS). > BTW, DNS RR Type could be used throughout the draft for consistency. I've seen the nomenclature "RRtype" used a lot. For now I've changed it to= this throughout the document. Andrew, you read a lot of DNS stuff, what's= the current popular favourite? > In Section 2.2: >=20 > "It is likely impossible to determine from a survey which MTAs (Mail > Transfer Agents)" >=20 > Reverse the MTAs and the term in full (expand on first use). OK. > In Section 2.2: >=20 > "The [OPENSPF] web site maintains a list of known implementations" >=20 > I would drop known as it cannot list what is unknown. OK. > In Section 2.3: >=20 > "An unknown number of clients implement SUBMITTER." >=20 > I suggest: SMTP clients. I think that's obvious from the context, but OK. > "An active survey was done of a large number of running and publicly > reachable MTAs." >=20 > What is an active survey? "active" means you initiated the contact; "passive" is the opposite, meanin= g you waited for something to contact you. Thus, an active survey of MTAs = is one where a bunch of connections to MTAs in the wild are made and the re= sults observed. > "The vast majority of the MTAs advertising SUBMITTER were different > instances of one MTA. That MTA was a mail filtering service, > which reports that about 11% of all observed SMTP sessions involve > clients that make use of SUBMITTER." >=20 > I suggest >=20 > The vast majority of the MTAs advertising the SUBMITTER SMTP extensi= on > were different instances of one MTA. It was reported by the mail fil= tering > service operating that MTA that about 11% of all observed SMTP sessi= ons > involved SMTP clients that make use of the SUBMITTER SMTP extension. OK, with slight tweaks of my own. > In Section 5: >=20 > "It is standard procedure within the IETF to document as standard > those protocols and practices that have come into sufficient common > use as to become part of the basic infrastructure." >=20 > I would drop this. The charter already allows 4408bis to be published > on the Standards Track. I don't think the charter comes into play here. The reason this text is th= ere is to set up the rest, especially the part where we think SPF deserves = advancement to the standards track. > "In light of the this and the analysis in the previous section, the > working group recommends to the IESG the following:" >=20 > We are not talking as a working group or to the IESG here. This is an > IETF document. Many IETF documents act as communications to or within the IETF; BCPs for e= xample, and I suspect some Informational ones as well. I think what we have is reasonable because the IESG Note basically gave an = assignment to the community. The response can reasonably be addressed to t= hem. Either way, I think there has to be a sentence or two that sets up the majo= r conclusions list. Do you have an alternative to propose? > "The experiment comprising the series of RFCs defining the > SUBMITTER SMTP extension, the Sender-ID mechanism, the Purported > Responsible address algorithm, and SPF, should be considered > concluded." >=20 > I would rewrite this as: >=20 > The experiments documented in RFC 4405, RFC 4406, RFC 4407 and RFC = 4408 are > considered as concluded. We didn't list the RFC numbers elsewhere, but only listed references. I co= uld re-insert the references here if you prefer. > In Appendix A: >=20 > "the rigors of the RFC publication process." >=20 > I suggest "Internet Standards Process". How about "IETF standards track process"? > "Later, after type 99 was assigned" >=20 > I would say publication of RFC 4408 (Andrew might know about the > procedure at that time). I believe the assignment came a short while before publication. Scott woul= d know that history better than me, short of going back to look at the mxco= mp archive. > "document, in fact), a plan was put into place to effect a gradual" >=20 > Why the plan is not documented? It was, as part of RFC4408, namely the MUST publish one and SHOULD publish = both stuff referenced later. > It would be easier to say that (DNS) > RR Type 99 did not see widespread adoption for: >=20 > 3. the substantial deployed base was already using RR Type 16, and it > was working just fine, leading to inertia; >=20 > And move (3) to the top. Are the other things in that list not valid? Why is that reordering easier? > "[SPF] itself included a faulty transition plan, likely because of > the late addition of a requirement to develop one: It said a > server SHOULD publish both types and MUST publish at least one, > while a client can query either or both, which means both can > claim to be fully compliant while failing utterly to > interoperate." >=20 > I would put this to lack of IETF review. How about adding: "Publication occurred without proper IETF review, so this= was not detected prior to publication." ? > "It is likely that this will happen again if the bar to creating new > RR types even for experimental development purposes is not lowered" >=20 > Why? :-) "Insanity is doing the same thing over and over again but expecting differe= nt results." I'm sure we haven't seen the last policy idea that will try to use the DNS = for transport. -MSK From spf2@kitterman.com Thu Apr 19 14:39: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 CEDF511E80D7 for ; Thu, 19 Apr 2012 14:39: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEMU2hwcIAe4 for ; Thu, 19 Apr 2012 14:39:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D40E311E80D2 for ; Thu, 19 Apr 2012 14:39:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 19E5E20E40CC; Thu, 19 Apr 2012 17:39:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334871562; bh=vQ6Y6xzftj2e6cGvQ2UdpSbb/gdXg3kWQ8zF7WzaEJE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=aYlJy4uiV1Dt4jN3CVu/LgY3TH9lp/EVy43fKVaz9yqltC4JhLRQOWbjvygdZWQ1F pV5TLDaR89ZGVdKtlQt6wz+EBDujTONvmn4ucf8bZnZfO3Ew+diOQIdzc43Nn0V7ne ZUh/Tma+B6a/goWJ951uJXg3RrtHW3blsuheIjkk= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EB80320E408F; Thu, 19 Apr 2012 17:39:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 17:39:21 -0400 Message-ID: <16688050.aCoyt2HCST@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.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] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 21:39:23 -0000 On Thursday, April 19, 2012 09:08:55 PM Murray S. Kucherawy wrote: > > "Later, after type 99 was assigned" > > > > > > I would say publication of RFC 4408 (Andrew might know about the > > procedure at that time). > > I believe the assignment came a short while before publication. Scott would > know that history better than me, short of going back to look at the mxcomp > archive. The assignment came shortly before the AUTH48. IIRC, we had a week or so two experiment with having two types and still be able to impact what became RFC 4408 (there were some significant AUTH48 changes as a result). Scott K From spf2@kitterman.com Thu Apr 19 14:43: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 218E611E80D2 for ; Thu, 19 Apr 2012 14:43: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5KVNgRnQDc1 for ; Thu, 19 Apr 2012 14:43:18 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB7711E809A for ; Thu, 19 Apr 2012 14:43:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0663920E40CC; Thu, 19 Apr 2012 17:43:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334871798; bh=tdg29wugiFPHn3+ngWd6TyLQkDJ1YV6rcFug0iHzuc8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=HMKBODskp34E44rI8TpO2KaxB5Ek5vBa53tHVhq4nbM7zsTJpbdFDOdxFihRKMsNi yaBRQskFiKU4O8IDvNglov3GC4jTo2+SHJBYQiCTk5rYprdc2CmCaW+vmYuswK3mOv kb4B7EM/jgn84Zn/EIJl43aJME0YWAOGMrlejNvM= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D804B20E408F; Thu, 19 Apr 2012 17:43:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 17:43:17 -0400 Message-ID: <1472279.B2BZqouseP@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20120419110129.09902380@elandnews.com> References: <6.2.5.6.2.20120419110129.09902380@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] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 21:43:19 -0000 On Thursday, April 19, 2012 11:40:57 AM SM wrote: > Hello, > > These comments on draft-ietf-spfbis-experiment-04 are merely > editorial. It's not a review. > > In Section 1: > > "over a period of two years from publication in order to determine a" > > I suggest: from the date of publication. The IESG note in RFC 4408 includes: The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future. I'd suggest "during the two years following publication" I.e. use the IESG wording here exactly. Scott K From SRS0=4W+TN=CZ==stuart@gathman.org Thu Apr 19 14:47: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 F357311E80A2 for ; Thu, 19 Apr 2012 14:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRC+W9xo6vuS for ; Thu, 19 Apr 2012 14:47:35 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id E149211E808F for ; Thu, 19 Apr 2012 14:47:34 -0700 (PDT) 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 q3JLlWMV002270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Apr 2012 17:47:33 -0400 Message-ID: <4F9087F4.6050103@gathman.org> Date: Thu, 19 Apr 2012 17:47:32 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> <4F8EF1C3.3060906@gathman.org> <4F902E82.8080606@tana.it> In-Reply-To: <4F902E82.8080606@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 21:47:56 -0000 Long ago, Nostradamus foresaw that on 04/19/2012 11:25 AM, Alessandro Vesely would write: > On Thu 19/Apr/2012 16:51:23 +0200 Stuart D Gathman wrote: >> on 04/18/2012 10:20 AM, Alessandro Vesely would write: >> >> >> If you expect to get your mail addressed to someotherdomain.org at >> your example.com mailbox (which I run in your example), *you* need to >> tell me so I can add someotherdomain.org to the authorized forwarder >> list (or you can do it yourself - as a small domain, I gave you and >> other users access to tools to do so should you be interested). > Fair enough. That explains it perfectly clear, thank you. In one > sentence, I'd summarize that as > > A mail server who opts to reject on fail needs to track all > forwarders and whitelist them. > > I don't mean to propose that wording for a document, just to make the > point clear. From such statement, the responsibility for breaking > mail delivery seems to stay on the receiver who missed to track a > forwarder. Yes, you get what I've been trying to say. Someone else complained that "forwarder" has to then be defined, but it is the recipient that defines it, not the RFC. It the recipient email admin hates alias forwarders and is an activist, he can refuse to whitelist anyone and always reject on FAIL. That doesn't help the SPF cause, because senders are tempted to try and work around this on their end. One technique that I played with was using exists: to verify a BATV style MFROM signature - this goes through alias forwarders just fine with 100% accuracy. But imposes a higher DNS overhead. >> If someotherdomain.org publishes an SPF record, that is the end of the >> story (unless they relay a lot of spam and I have to block them). If >> they don't publish an SPF record, I have to put my mail admin hat on >> and go over logs to figure out a reasonable local SPF record (i.e. not >> an official SPF record, but one my mail servers use for that domain) >> that covers IPs someotherdomain.org sends from. For an alias >> forwarder, that usually ends up being something like "v=spf1 >> ptr:someotherdomain.org -all". > That looks like a whitelisting technique. You could use any other > authentication method, e.g. DKIM, depending on the forwarder and the > amount of cooperation they are willing to put into it. True. The key is that you don't want to manually maintain a list of IPs. Either SPF or DKIM would work for the purpose. I would find it odd, however, if a forwarder went to effort of DKIM signing alias forwards, when rewriting MFROM would be much cheaper and easier. >> On the other hand, if somejerkdomain.org decides to start alias >> forwarding some random mailbox "for your convenience" that you have no >> knowledge of, that is *forgery*, and will get rejected (and the IP >> banned if persistent) for any domain I administer if the sender >> published an SPF record with -all (which thankfully for banks and >> credit card companies, they generally do). > For example, if you happen to write an I-D and publish it on the IETF > site, you would get mail redirected to the address used in the I-D. > That feature is probably written and fully explained somewhere, but > you might happen to have missed it. If the original sender publishes > a strict SPF policy, you would reject the forwarded message. Would > that be your fault, then? Probably, since I am implicitly authorizing the alias forward by submitting the I-D. But IETF really ought to be using "webmail" semantics and rewriting MFROM for that application. (Are you sure they don't?) From spf2@kitterman.com Thu Apr 19 14:51: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 CFA1711E80BF for ; Thu, 19 Apr 2012 14:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykzwRdhmmVyl for ; Thu, 19 Apr 2012 14:51:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6F11E808F for ; Thu, 19 Apr 2012 14:51:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E406620E40CC; Thu, 19 Apr 2012 17:51:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334872286; bh=hrmTkSgTqbHdiaLtceZKKbw5Ssj59pFnRgfkmxu+ZpU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Ska8qzFGVNRXqcnWbLHyBtHeYjn/LX+ieeEJiFkBp7OdVair+3grhcojuwx9SdMln JSFEhFEmHYeNRD86QQPfjv2s5uOH7tQNaQhaCPQterm/XGTk8aduq1DG4SevHRFS53 7EO6XxPpOLGeJ65reoNki89EjQWFwv3UHft7ZDvc= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DCD8020E408F; Thu, 19 Apr 2012 17:51:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 17:50:52 -0400 Message-ID: <1830748.75dlm12hFV@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20120419110129.09902380@elandnews.com> References: <6.2.5.6.2.20120419110129.09902380@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] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 21:51:35 -0000 On Thursday, April 19, 2012 11:40:57 AM SM wrote: > In Appendix A: > > "the rigors of the RFC publication process." > > I suggest "Internet Standards Process". > > "Later, after type 99 was assigned" > > I would say publication of RFC 4408 (Andrew might know about the > procedure at that time). > > "document, in fact), a plan was put into place to effect a gradual" > > Why the plan is not documented? It would be easier to say that (DNS) > RR Type 99 did not see widespread adoption for: > > 3. the substantial deployed base was already using RR Type 16, and it > was working just fine, leading to inertia; > > And move (3) to the top. > > "[SPF] itself included a faulty transition plan, likely because of > the late addition of a requirement to develop one: It said a > server SHOULD publish both types and MUST publish at least one, > while a client can query either or both, which means both can > claim to be fully compliant while failing utterly to > interoperate." Why should this be moved to the top. From the perspective of the lack of transition, it is the least important point listed. This is an interoperability bug, not a transition bug. It might be better to say RFC 4408 included no transition plan. The only fix that would have made any operational sense when RFC 4408 was published would have been to make publishing and checking TXT mandatory. That would be made the already vanishingly small chance of transition even that much smaller. > I would put this to lack of IETF review. What lack of IETF review? Even though there was not a consensus call for the draft that became SPF, Wayne Schlitt was very careful to solicit reviews from the relevant IETF experts, including getting reviews on namedroppers. The real problem is that the RR Type for Type SPF was only assigned very shortly before AUTH48 so there was virtually no time to experiment with using both TXT and SPF toghether. The multiple RR type design we have is a paper design plus a week of playing around with code. It is much, much less mature than the basic protocol and it shows. Scott K From SRS0=4W+TN=CZ==stuart@gathman.org Thu Apr 19 14: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 B0C3C11E80BB for ; Thu, 19 Apr 2012 14:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBEeiVWFao7O for ; Thu, 19 Apr 2012 14:52:09 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id E16BE11E80A4 for ; Thu, 19 Apr 2012 14:52:06 -0700 (PDT) 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 q3JLq5QY002398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Apr 2012 17:52:06 -0400 Message-ID: <4F908905.9070109@gathman.org> Date: Thu, 19 Apr 2012 17:52:05 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> <4F8EF1C3.3060906@gathman.org> <4F902E82.8080606@tana.it> <4F9087F4.6050103@gathman.org> In-Reply-To: <4F9087F4.6050103@gathman.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 21:52:12 -0000 Long ago, Nostradamus foresaw that on 04/19/2012 05:47 PM, Stuart D Gathman would write: > >> >> A mail server who opts to reject on fail needs to track all >> forwarders and whitelist them. >> >> I don't mean to propose that wording for a document, just to make the >> point clear. From such statement, the responsibility for breaking >> mail delivery seems to stay on the receiver who missed to track a >> forwarder. > > Yes, you get what I've been trying to say. Someone else complained > that "forwarder" has to then be defined, but it is the recipient that > defines it, not the RFC. It the recipient email admin hates alias > forwarders and is an activist, he can refuse to whitelist anyone and > always reject on FAIL. That doesn't help the SPF cause, because > senders are tempted to try and work around this on their end. One > technique that I played with was using exists: to verify a BATV style > MFROM signature - this goes through alias forwarders just fine with > 100% accuracy. But imposes a higher DNS overhead. This is the killer app for the localpart macro that Doug Otis hates. It enables SPF to pass through alias forwarding with no issues - except that DNS caching is defeated. From sm@resistor.net Thu Apr 19 15:10: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 1D07721F85B4 for ; Thu, 19 Apr 2012 15:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9v8AiXRmvea for ; Thu, 19 Apr 2012 15:10:11 -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 4222C21F85A7 for ; Thu, 19 Apr 2012 15:10:11 -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 q3JM9hra029665; Thu, 19 Apr 2012 15:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334873388; i=@resistor.net; bh=x66ivxXmpF8oNsjnNWYcm9sFFXTJvOyiSbz0lZMP4KM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GNLDhbnIc6yLsRWjJqUjLZUQU5paziOLvcRO1jja3RJcThBqb80NXgBrtfGPpaRDd enIRu0uKs30VRjGR1jaGjDCDwOEEsiFRhsFmY0gNZ15kgd3nzislcvj5jynZkMIFx/ nm2a7qmLxnv2Gt5ZEJOXub2/0hH8LR1/2Mt2QLd0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334873388; i=@resistor.net; bh=x66ivxXmpF8oNsjnNWYcm9sFFXTJvOyiSbz0lZMP4KM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W68OiWLPZePE/RAC61/5pfYcrwahiBUt6UwJssXdej7ZU+tk8eFAtz0XWjh8UEOeE O+U0WM54/xoXk3x0yKVi5hdELiZxOY3LXwQ0XgvQXHx3kldk/mkwWVTu9pl82W+QUZ UmVBMGtTdbNTJeaS5Xc4T8+AYZqi7C/2Oe/Zrm40= Message-Id: <6.2.5.6.2.20120419142151.0b54b2f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Apr 2012 14:34:07 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cl oudmark.com> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 22:10:13 -0000 Hi Murray, At 14:08 19-04-2012, Murray S. Kucherawy wrote: >OK (though done earlier, since that's not the first reference to the DNS). I haven't given sufficient consideration to the references section as this was not a review. >I've seen the nomenclature "RRtype" used a lot. For now I've >changed it to this throughout the document. Andrew, you read a lot >of DNS stuff, what's the current popular favourite? I'll defer to Andrew. >"active" means you initiated the contact; "passive" is the opposite, >meaning you waited for something to contact you. Thus, an active >survey of MTAs is one where a bunch of connections to MTAs in the >wild are made and the results observed. I see. It's not clear to the reader. >I don't think the charter comes into play here. The reason this >text is there is to set up the rest, especially the part where we >think SPF deserves advancement to the standards track. Ok (as my comments were editorial). >Many IETF documents act as communications to or within the IETF; >BCPs for example, and I suspect some Informational ones as well. Yes, but it doesn't fit this WG unless it is using pre-evaluation I-Ds. >I think what we have is reasonable because the IESG Note basically >gave an assignment to the community. The response can reasonably be >addressed to them. > >Either way, I think there has to be a sentence or two that sets up >the major conclusions list. Do you have an alternative to propose? I'll do that during a review. >We didn't list the RFC numbers elsewhere, but only listed >references. I could re-insert the references here if you prefer. I'll defer to you. This is probably a matter of style. >How about "IETF standards track process"? No, it's better not to invent that. :-) >I believe the assignment came a short while before >publication. Scott would know that history better than me, short of >going back to look at the mxcomp archive. I probably did not explain the point correctly. Please ignore my comment. >It was, as part of RFC4408, namely the MUST publish one and SHOULD >publish both stuff referenced later. I'll leave this for a review. >Are the other things in that list not valid? Yes, as editorial. >Why is that reordering easier? It starts with the main point. >How about adding: "Publication occurred without proper IETF review, >so this was not detected prior to publication." ? I'll leave this for a review if it is ok with you. >"Insanity is doing the same thing over and over again but expecting >different results." > >I'm sure we haven't seen the last policy idea that will try to use >the DNS for transport. The point was RR assignments. :-) There was some discussion about this on another list. Regards, -sm From hsantos@isdg.net Thu Apr 19 15:33: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 6572921F853B for ; Thu, 19 Apr 2012 15:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFh8Ux905Vny for ; Thu, 19 Apr 2012 15:33:07 -0700 (PDT) Received: from news.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E034221F8539 for ; Thu, 19 Apr 2012 15:33:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3631; t=1334874779; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=uQxzE0vPEVBrLv67oUClqKmFS/c=; b=gfLevqdGM1QPD2AijfgH LflmzdAbcmnpx+AEkkWRJZ4Xd66N35g012FAl+bL01pdwbpNmKSTEDYniiI7rylp 1n06N+QMdnGuQSQ3zKTyZy29SBb/WVogE6X4cTB/yXQIFr4QyRZDV09aSOgiU1uE lLgFJVMVjA2A8P2xnDgdcE4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 18:32:59 -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 v6.4.454.1) with ESMTP id 3781600772.30828.5804; Thu, 19 Apr 2012 18:32:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3631; t=1334874446; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tNENPqQ qG8r0eS48j6juafTf9i7z/NI3p1zmUuP5Cxw=; b=icHdaNkO1IUQ2UkfQKl6qJk Sg1/2Pr+L5VXckjHojGOHy8lWF5FyZOW8dSTADHmUjoI6uzzeCUqfvkLlfBIKMZ9 b2XYOSLizaUHFwl62y5CmTaAQrF0XUxeqRvaz3XbWl67mqbHu71RVIbTcj7LtNNn mHTFAvplF+o+Tg6IjLyc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 18:27:26 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 85534550.2431.5440; Thu, 19 Apr 2012 18:27:25 -0400 Message-ID: <4F90926D.7050107@isdg.net> Date: Thu, 19 Apr 2012 18:32:13 -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: <20120419164741.60726.qmail@joyce.lan> <4F9045AF.9020403@isdg.net> <20120419171652.GB94829@mail.yitter.info> In-Reply-To: <20120419171652.GB94829@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 22:33:08 -0000 This is EXACTLY one of the concerns about the establishment of this SPFBIS that pitted the differences between those that used SPF in strong deterministic manner with those who wanted HEURISTIC or REPUTATION, including overall pushing the solution to DKIM. It was the central issue back then when CSV/DNA was also a proposal on the MARID table - but dropped and it remained throughout the years with the same people MILITANTLY against SPF now in control of the specification. Since day one, SPF was about rejection the abusive domain spoofer which was the #1 problem and still is. The permissive authorization to SHOULD REJECT is pretty clear in section 2.5.4 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. The checking software can choose to mark the mail based on this or to reject the mail outright. If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification (DSN) code (see [RFC3464]), in addition to an appropriate reply text. The check_host() function may return either a default explanation string or one from the domain that published the SPF records (see Section 6.2). If the information does not originate with the checking software, it should be made clear that the text is provided by the sender's domain. For example: 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 I really and sincerely really HOPE that the cogs in charge QUIT trying to change the framework. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com Andrew Sullivan wrote: > No hat. > > Please forgive the intrusion by someone who doesn't know anything, but > > On Thu, Apr 19, 2012 at 01:04:47PM -0400, Hector Santos wrote: >> Hmmm, but you always did object since day one. The SPF specs was >> always very clear about actionable recommendations: >> >> SHOULD REJECT ON A DOMAIN POLICY HARDFAIL (-ALL) > > I am unable to find in section 2.5, "Interpreting the result", of RFC > 4408 the idea of a policy hardfail. Maybe you mean "Fail", section > 2.5.4. If so, then that section is not consistent with what you say. > It says this: > > A "Fail" result is an explicit statement that the client is not > authorized to use the domain in the given identity. The checking > software can choose to mark the mail based on this or to reject the > mail outright. > > There is no SHOULD there, and there is no RFC 2119 language at all. > This is, according to that text at least, purely a matter of local > policy. > > Now, with my chair hat on (I haven't discussed this with SM, but it's > not like he hasn't said similar things recently): > > Unless I see some argument _based on the text in RFC 4408_, and > quoting it, that any of this rejection stuff is in fact on-charter, I > have to ask people to stop discussing it. Our charter is very clear: > we need to alter the specification as little as possible except to > clarify things, and to specify widely-adopted variations (either > explaining widely-adopted features or leaving out unused things). In > effect, changes should be uncontroversially rooted in empirical data. > Since there is, AFAICT, empirical disagreement about what people are > doing, SHOULD reject is a modification of the protocol and won't meet > the test. > > Best regards, > > A From spf2@kitterman.com Thu Apr 19 15:40: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 8267211E80A0 for ; Thu, 19 Apr 2012 15:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW-lPpIJJJNl for ; Thu, 19 Apr 2012 15:40:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9238811E8087 for ; Thu, 19 Apr 2012 15:40:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BBF5F20E40CC; Thu, 19 Apr 2012 18:40:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334875242; bh=hrmkeD55LvLQGhC9EhzEcOwHR8tRgewfQXrj5LhB/oE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=J+nBKuvnIWOPM9tJ2fho1ec5VAJbQxqv2kTSZGi17+8G54iXrODIuPNIS5784e7Oe QLDUlsgr8ov5k3DJuK/BhmRvpbCGVQPk3+zYKtF/M2PglyaW1iw7gXJQRaaNlvEZZM Di1AL+lE20M5x3MXkkOVR+RO3v5xIpD4ij7qnJws= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8862720E408F; Thu, 19 Apr 2012 18:40:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 18:40:41 -0400 Message-ID: <2438059.eHrchuiRM4@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F90926D.7050107@isdg.net> References: <20120419164741.60726.qmail@joyce.lan> <20120419171652.GB94829@mail.yitter.info> <4F90926D.7050107@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 22:40:44 -0000 Hector, You are arguing that someone is taking over and changing something, but the words you want have never been in any SPF draft. Continuing not to say what has never been said is not a change. Scott K On Thursday, April 19, 2012 06:32:13 PM Hector Santos wrote: > This is EXACTLY one of the concerns about the establishment of this > SPFBIS that pitted the differences between those that used SPF in > strong deterministic manner with those who wanted HEURISTIC or > REPUTATION, including overall pushing the solution to DKIM. It was > the central issue back then when CSV/DNA was also a proposal on the > MARID table - but dropped and it remained throughout the years with > the same people MILITANTLY against SPF now in control of the > specification. > > Since day one, SPF was about rejection the abusive domain spoofer > which was the #1 problem and still is. The permissive authorization > to SHOULD REJECT is pretty clear in section 2.5.4 > > 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. The checking > software can choose to mark the mail based on this or to reject the > mail outright. > > If the checking software chooses to reject the mail during the SMTP > transaction, then it SHOULD use an SMTP reply code of 550 (see > [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification > (DSN) code (see [RFC3464]), in addition to an appropriate reply text. > The check_host() function may return either a default explanation > string or one from the domain that published the SPF records (see > Section 6.2). If the information does not originate with the > checking software, it should be made clear that the text is provided > by the sender's domain. For example: > > 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 > > > I really and sincerely really HOPE that the cogs in charge QUIT trying > to change the framework. > > > No hat. > > > > Please forgive the intrusion by someone who doesn't know anything, but > > > > On Thu, Apr 19, 2012 at 01:04:47PM -0400, Hector Santos wrote: > >> Hmmm, but you always did object since day one. The SPF specs was > >> > >> always very clear about actionable recommendations: > >> SHOULD REJECT ON A DOMAIN POLICY HARDFAIL (-ALL) > > > > I am unable to find in section 2.5, "Interpreting the result", of RFC > > 4408 the idea of a policy hardfail. Maybe you mean "Fail", section > > 2.5.4. If so, then that section is not consistent with what you say. > > > > It says this: > > A "Fail" result is an explicit statement that the client is not > > authorized to use the domain in the given identity. The checking > > software can choose to mark the mail based on this or to reject the > > mail outright. > > > > There is no SHOULD there, and there is no RFC 2119 language at all. > > This is, according to that text at least, purely a matter of local > > policy. > > > > Now, with my chair hat on (I haven't discussed this with SM, but it's > > not like he hasn't said similar things recently): > > > > Unless I see some argument _based on the text in RFC 4408_, and > > quoting it, that any of this rejection stuff is in fact on-charter, I > > have to ask people to stop discussing it. Our charter is very clear: > > we need to alter the specification as little as possible except to > > clarify things, and to specify widely-adopted variations (either > > explaining widely-adopted features or leaving out unused things). In > > effect, changes should be uncontroversially rooted in empirical data. > > Since there is, AFAICT, empirical disagreement about what people are > > doing, SHOULD reject is a modification of the protocol and won't meet > > the test. > > > > Best regards, > > > > A > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Thu Apr 19 16:00: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 D798311E8083 for ; Thu, 19 Apr 2012 16:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USk-2eeexiUS for ; Thu, 19 Apr 2012 16:00:40 -0700 (PDT) Received: from news.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE8A411E8081 for ; Thu, 19 Apr 2012 16:00:39 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3285; t=1334876434; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/03Ovk2IdaTcbl0aEQlLM977Rsc=; b=brQmrAChwgWh6cfARMYR 4MoxLtMRqqrcIJ1cYjJOCi3sXorjQyxE+zXA2RFWmLzXRgVgTXWQzLzDFwVnBaYM Qy/XFpATn6+IayndJNQ+n3FzI+WHSbUkDh5gR0iQDXPJ+D7nz3LBjJixP140IZCn 9T4ks3p54ERwYdmfjR+EFps= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 19:00:34 -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 v6.4.454.1) with ESMTP id 3783255817.30828.3204; Thu, 19 Apr 2012 19:00:33 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3285; t=1334876100; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CCcoyhW eNUr6EKdZ/9NmaFQz1qFLgxOx5bPxcocIs0Y=; b=eUTg6zLWXgQp9tAl8XdQ4Ox 5mj/V1CioqhufVDQOorJFaOoP0cJjOYBfgQKY6Xtw3VUVJNLxh8gNdmh7vCgHI5Q GSSr3d5kH3Gt2VtxCqysdPCVaFMVyQ66uHHYTnOo1aQqMapS94CxHIlOk3F4WAOc TFVshXyuON2voSYUrHXA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 18:55:00 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 87188550.2436.2516; Thu, 19 Apr 2012 18:54:59 -0400 Message-ID: <4F9098E3.7030608@isdg.net> Date: Thu, 19 Apr 2012 18:59:47 -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: <20120419164741.60726.qmail@joyce.lan> <20120419171652.GB94829@mail.yitter.info> <4F90926D.7050107@isdg.net> <2438059.eHrchuiRM4@scott-latitude-e6320> In-Reply-To: <2438059.eHrchuiRM4@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 23:00:41 -0000 Scott Kitterman wrote: > Hector, > > You are arguing that someone is taking over and changing something, but the > words you want have never been in any SPF draft. Continuing not to say what > has never been said is not a change. > > Scott K SOFTFAIL has a SHOULD NOT. NEUTRAL says nothing other than treat it as a NONE. For FAIL, the backend has two chooses - mark it - reject it If you choose to reject, you SHOULD use 550. How can this any more clear? Maybe the problem is what does "mark it" means? I suggest its generally some formm of negative classification and stream splitting that doesn't HARM the users. That could be a SPAM BIN folder on the online MUA, but for those that don't split or worst for the OFFLINE MUA POP3 user - they are hosed, they are harmed and the only real backend "choosing" is to REJECT. Either way - you need to mark/reject the messages, and thats pretty clear. Its peppered in many areas and it wasn't too hard to find: RFC4406 (SenderID) also has it explicitly stated: 5.3. Fail When performing the Sender ID test during an SMTP transaction, an MTA that chooses to reject a message receiving this result SHOULD reject the message with a "550 5.7.1 Sender ID (xxx) yyy - zzz" SMTP error, where "xxx" is replaced with "PRA" or "MAIL FROM", "yyy" is replaced with the additional reason returned by the check_host() function, and "zzz" is replaced with the explanation string returned by the check_host() function. And also RFC4405 (Submitter) 4.2. Processing the SUBMITTER Parameter ... If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed." So please, lets get real about it. This is exactly what I felt will happen with the relaxation of entire SPF/SIDF framework. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com >> Since day one, SPF was about rejection the abusive domain spoofer >> which was the #1 problem and still is. The permissive authorization >> to SHOULD REJECT is pretty clear in section 2.5.4 >> >> 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. The checking >> software can choose to mark the mail based on this or to reject the >> mail outright. >> >> If the checking software chooses to reject the mail during the SMTP >> transaction, then it SHOULD use an SMTP reply code of 550 (see >> [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification >> (DSN) code (see [RFC3464]), in addition to an appropriate reply text. >> The check_host() function may return either a default explanation >> string or one from the domain that published the SPF records (see >> Section 6.2). If the information does not originate with the >> checking software, it should be made clear that the text is provided >> by the sender's domain. For example: >> >> 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 From sm@resistor.net Thu Apr 19 16:05: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 11A4011E8083 for ; Thu, 19 Apr 2012 16:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PRF+CbptnLo for ; Thu, 19 Apr 2012 16:05: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 6477211E8099 for ; Thu, 19 Apr 2012 16:05:39 -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 q3JN5W7p017615; Thu, 19 Apr 2012 16:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334876738; i=@resistor.net; bh=dIrKAPq8qm9go8iJch3tuTUf9Sc1qMUO3m5mZrrnAno=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TT3ert4xMhPbiB1Bf8dKS5T9RBLxAic/R8gOSTwmpA8dICzQdeLdwAxrVDn315Aiz ZTefu5hK7iUy9bB2IG9H3qmyWDwMqWJ6X5AuzL+WLWQcOEpKyoRk8rphb3wp8W/WCE V2s2QJbrmBuqmGt4CXiq/WzLRFfSUjn2+LbOKPZ8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334876738; i=@resistor.net; bh=dIrKAPq8qm9go8iJch3tuTUf9Sc1qMUO3m5mZrrnAno=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=b4Oa87M0EE1K1CYHVuusFR7oEXVxwAzyo52wFIPFCRdWjhuOUrHjIGapR0o51lIuL fn6hklOb+uWjthz/Wpr1m5/FHYtPdgRJt85DE24cBfZDcGeNrkX74YFudhxr4A8IWV NEN5YohsXa6rruZXym8drY5Cxq7gahoj5HYsDShQ= Message-Id: <6.2.5.6.2.20120419153306.0a06ff18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Apr 2012 15:53:45 -0700 To: Scott Kitterman From: SM In-Reply-To: <1830748.75dlm12hFV@scott-latitude-e6320> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <1830748.75dlm12hFV@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 23:05:41 -0000 Hi Scott, At 14:50 19-04-2012, Scott Kitterman wrote: >Why should this be moved to the top. From the perspective of the lack of The comment was editorial. >What lack of IETF review? Even though there was not a consensus call for the It's an individual opinion. A consensus call doesn't bring much. It's more than a matter of soliciting reviews. Regards, -sm From ajs@anvilwalrusden.com Thu Apr 19 16:26: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 5EC8311E80BB for ; Thu, 19 Apr 2012 16:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enVHndfELdaD for ; Thu, 19 Apr 2012 16:26:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C202211E8073 for ; Thu, 19 Apr 2012 16:26:10 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 606941ECB41D for ; Thu, 19 Apr 2012 23:26:09 +0000 (UTC) Date: Thu, 19 Apr 2012 19:26:06 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120419232606.GJ94829@mail.yitter.info> References: <20120419164741.60726.qmail@joyce.lan> <4F9045AF.9020403@isdg.net> <20120419171652.GB94829@mail.yitter.info> <4F90926D.7050107@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F90926D.7050107@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 23:26:11 -0000 Hector, Two things. On Thu, Apr 19, 2012 at 06:32:13PM -0400, Hector Santos wrote: > Since day one, SPF was about rejection the abusive domain spoofer The section that you quoted simply does not say, in English, that SPF is "about rejection" of anything. That is, > which was the #1 problem and still is. The permissive authorization > to SHOULD REJECT is pretty clear in section 2.5.4 it does _not_ say "SHOULD REJECT". It says that if you choose to reject, then you SHOULD use SMTP reply 550. There is no sense whatever that it says SHOULD REJECT: > If the checking software chooses to reject the mail during the SMTP > transaction, then it SHOULD use an SMTP reply code of 550 (see > [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification > (DSN) code (see [RFC3464]), in addition to an appropriate reply text. I urge you to read RFC 2119 and understand what SHOULD means, because the 4408 text does not say what you insist it says. Therefore, with my mailing list moderator hat on, unless you have another piece of text from RFC 4408 to point to, this discussion is off-charter and closed. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From dotis@mail-abuse.org Thu Apr 19 16:37: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 764BD11E8083 for ; Thu, 19 Apr 2012 16:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8VV-PPNDjZU for ; Thu, 19 Apr 2012 16:37:28 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id EA4DB11E8073 for ; Thu, 19 Apr 2012 16:37:28 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id A477D17401B9 for ; Thu, 19 Apr 2012 23:37:28 +0000 (UTC) Message-ID: <4F90A1B8.5080706@mail-abuse.org> Date: Thu, 19 Apr 2012 16:37:28 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F6DF992.10605@tana.it> <9452079D1A51524AA5749AD23E0039280B7AC7@exch-mbx901.corp.cloudmark.com> <4F6EEFF5.3070306@tana.it> <4F7BEA22.9050908@gathman.org> <4F7C6753.8060202@tana.it> <4F7CA052.3090006@gathman.org> <4F7DDB7C.9080605@tana.it> <4F8E184B.2030109@gathman.org> <4F8ECDAB.7010509@tana.it> <4F8EF1C3.3060906@gathman.org> <4F902E82.8080606@tana.it> <4F9087F4.6050103@gathman.org> <4F908905.9070109@gathman.org> In-Reply-To: <4F908905.9070109@gathman.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 23:37:29 -0000 On 4/19/12 2:52 PM, Stuart D Gathman wrote: > Long ago, Nostradamus foresaw that on 04/19/2012 05:47 PM, Stuart D > Gathman would write: >>> A mail server who opts to reject on fail needs to track all >>> forwarders and whitelist them. >>> >>> I don't mean to propose that wording for a document, just to make the >>> point clear. From such statement, the responsibility for breaking >>> mail delivery seems to stay on the receiver who missed to track a >>> forwarder. >> >> Yes, you get what I've been trying to say. Someone else complained >> that "forwarder" has to then be defined, but it is the recipient that >> defines it, not the RFC. It the recipient email admin hates alias >> forwarders and is an activist, he can refuse to whitelist anyone and >> always reject on FAIL. That doesn't help the SPF cause, because >> senders are tempted to try and work around this on their end. One >> technique that I played with was using exists: to verify a BATV style >> MFROM signature - this goes through alias forwarders just fine with >> 100% accuracy. But imposes a higher DNS overhead. > This is the killer app for the localpart macro that Doug Otis hates. > It enables SPF to pass through alias forwarding with no issues - > except that DNS caching is defeated. Dear Stuart, Such local-part forwarding schemes would be accepting email based on unverified SMTP Mail parameters. Mail parameters are fully open to exploitation, where validation independent of source would cause more harm than good. The SMTP EHLO parameter is fully within the control of sending domains and independent of forwarding conventions. Based upon the amount of heat versus light regarding Mail and EHLO, it could be beneficial to include a section explaining differences in dry sanguine terms. This might be a simple outline describing factors that permit increased rejection compliance without use of ad hoc information, for example. Some heavily phished domains are considering use of SPF as a fall-back strategy for when DKIM fails, which occurs in about 2% of the cases. A scheme that only works for 98% of the valid mail stream will generate too many support calls for most operations. In this application, EHLO offers several security related benefits: 1) Greater chance of EHLO/SPF rejection with "-all" records. 2) DKIM and EHLO both offer A-labels for easier domain alignment assessments. 3) Fewer DNS transactions required. 4) Will not interfere with SMTP forwarding features. 5) Offers a safer basis for white-listing. 6) Results in smaller tracking databases. 7) Permits rejection prior to Data (compared with DKIM). 8) Will not flood DNS cache with local-part foo. 9) Permits easier to manage server specific RRsets. 10) Identifies providers willing to be directly accountable. Regards, Douglas Otis From hsantos@isdg.net Thu Apr 19 16:50: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 F2A7711E8073 for ; Thu, 19 Apr 2012 16:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATIfXrERijpn for ; Thu, 19 Apr 2012 16:50:16 -0700 (PDT) Received: from groups.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9B06211E80CB for ; Thu, 19 Apr 2012 16:50:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2507; t=1334879405; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PxC7Ka4D1v4ABza6xnkmCR5wZZ4=; b=VzcsjrppWLPEO8y5GrRq qWQNdD6H9+SWgQscdmzSkByefhMlEsgeVDUhfa1iQ7MRXz72y9ErEeafF/dAwzgj 2EWAQ8KKTxFkhrIq80FwMuGzUPcQS4Vw/K16N45juVIYxGGpvy3mepgIlItMQp// w4HkGanFsDZTpX9bdvkPdGE= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 19:50: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3786226061.30828.4220; Thu, 19 Apr 2012 19:50:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2507; t=1334879074; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RVHHY3K 4LJtM8jo7SHpsF6GlQbirIKErSf6daN/ST0g=; b=ACRlV0ENVN6e7h/7fIeP0mP buYZkOC24eEAepWlqEgSsYgTB5I7G7hFpcRy9xmf2YlPa5vjBznPNY80XUDQcvTe hANPADdVNY09ZR35NQRh8GvwdjyHo3ncDna67JfzqZIc+QgW0ed3VQT9sBRiSd+F mDBbqpMmAlDQ7FcTq7T4= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 19:44:34 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 90161722.2441.4864; Thu, 19 Apr 2012 19:44:32 -0400 Message-ID: <4F90A480.2030005@isdg.net> Date: Thu, 19 Apr 2012 19:49:20 -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: <20120419164741.60726.qmail@joyce.lan> <4F9045AF.9020403@isdg.net> <20120419171652.GB94829@mail.yitter.info> <4F90926D.7050107@isdg.net> <20120419232606.GJ94829@mail.yitter.info> In-Reply-To: <20120419232606.GJ94829@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Apr 2012 23:50:18 -0000 This is semantics, and one where chair filtration is being unfairly used to PUSH a view and new framework by the editor that was clearly never there. Sure, its always local policy, but its been clear and described in many parts of all the SPF/SIDF related documents what the very essence and intent of the deterministic SPF protocol was all about which WAS NOT about heuristics or reputation. The list is too long to repeat all the text in all the docs which can summarize that for the HARDFAIL you either mark or reject it and the rejection you SHOULD use 550 - which is permanent. So if anything, perhaps a new issue should be added that will define what "mark it" means. Is that just adding the 5322.Receiver-SPF: FAIL and doing no more? Fine. But practically reality suggest its separating it from the user's normal stream of new mail. But at SMTP, REJECT-ON-FAIL is in the specification and it always has been and that comes in the form of a SHOULD 550 - a permanent REJECT. Marking this subject off-topic is fine be me because hopefully it will stop the attempts to change the meaning of what SMTP-SPF receivers are AUTHORIZED to do - per specification. Andrew Sullivan wrote: > Hector, > > Two things. > > On Thu, Apr 19, 2012 at 06:32:13PM -0400, Hector Santos wrote: > >> Since day one, SPF was about rejection the abusive domain spoofer > > The section that you quoted simply does not say, in English, that SPF > is "about rejection" of anything. That is, > >> which was the #1 problem and still is. The permissive authorization >> to SHOULD REJECT is pretty clear in section 2.5.4 > > it does _not_ say "SHOULD REJECT". It says that if you choose to > reject, then you SHOULD use SMTP reply 550. There is no sense > whatever that it says SHOULD REJECT: > >> If the checking software chooses to reject the mail during the SMTP >> transaction, then it SHOULD use an SMTP reply code of 550 (see >> [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification >> (DSN) code (see [RFC3464]), in addition to an appropriate reply text. > > I urge you to read RFC 2119 and understand what SHOULD means, because > the 4408 text does not say what you insist it says. > > Therefore, with my mailing list moderator hat on, unless you have > another piece of text from RFC 4408 to point to, this discussion is > off-charter and closed. > > Thanks, > > A > -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Thu Apr 19 17:09: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 9046811E80E0 for ; Thu, 19 Apr 2012 17:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YykbulTtg1Z for ; Thu, 19 Apr 2012 17:09:01 -0700 (PDT) Received: from groups.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0D11E80DC for ; Thu, 19 Apr 2012 17:09:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=677; t=1334880530; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=cod4Vdqgy5zZ1FT+B1rIinjIoeQ=; b=J4EB345zxwfhhzsSHuOS YFY0HbvJeUi7EAcT0fW2r/iloRXO5gUkKjh87uAVRCCg/8jvMBL1eiLh4Bh+fikp uEfMdc9kFHryxhSbzGjm0yKKb86Xof01qQYR8sTcowMoICWpWiOeOWKm/Uggnq4Q PB9TciO6vYcGR6e96bE0+bA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 20:08:50 -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 v6.4.454.1) with ESMTP id 3787351327.30828.1952; Thu, 19 Apr 2012 20:08:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=677; t=1334880195; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=j/DhVvH 5pIMk4WkKpaa6gSspvy5rAw4BWXXPfrJ02aA=; b=Q9Q5bqGZtOBu06oaG7AmIyG QtrBmjul5aHiuJRjmpp3yjj6oK9c/1m95wX+V0nbxui6SelDdv5yl/He9MJu+AlW 1r2ec/sU6fXnSiP+WbR8fl1m8sdLj2YIdolzMsE6+p5h1B1imcAHJhHYKzc3dDGp xRlzeETfp5j3n+Y6a2TE= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 19 Apr 2012 20:03:15 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 91282784.2443.1100; Thu, 19 Apr 2012 20:03:13 -0400 Message-ID: <4F90A8E0.6010000@isdg.net> Date: Thu, 19 Apr 2012 20:08:00 -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: <20120419164741.60726.qmail@joyce.lan> <4F9045AF.9020403@isdg.net> <20120419171652.GB94829@mail.yitter.info> <4F90926D.7050107@isdg.net> <20120419232606.GJ94829@mail.yitter.info> In-Reply-To: <20120419232606.GJ94829@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 00:09:02 -0000 Andrew Sullivan wrote: > I urge you to read RFC 2119 and understand what SHOULD means, because > the 4408 text does not say what you insist it says. Its funny, because I have some doubt you may have the wrong interpretation yourself. But who knows. One thing for sure, the attempt to change it with rfc2119BIS - failed! On the one hand, some view it a SHOULD is really a MUST unless there are no workarounds and other hand, some view it has an OPTION, abeit strong recommendation to follow. Either way, lets not forget to review http://tools.ietf.org/html/rfc2119#section-6 -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From ajs@anvilwalrusden.com Thu Apr 19 19:27: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 362E221E801A for ; Thu, 19 Apr 2012 19:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AkTu+bX0Cbw for ; Thu, 19 Apr 2012 19:27:32 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCEF21E800F for ; Thu, 19 Apr 2012 19:27:32 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id D87F31ECB41D for ; Fri, 20 Apr 2012 02:27:30 +0000 (UTC) Date: Thu, 19 Apr 2012 22:27:28 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120420022728.GK94829@mail.yitter.info> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 02:27:33 -0000 Dear colleagues, No hat. On Thu, Apr 19, 2012 at 09:08:55PM +0000, Murray S. Kucherawy wrote: > > > BTW, DNS RR Type could be used throughout the draft for consistency. > > I've seen the nomenclature "RRtype" used a lot. For now I've changed it to this throughout the document. Andrew, you read a lot of DNS stuff, what's the current popular favourite? > RFC 1034 spells it RR type. See section 3.3. RFC 2929, the 2000-era "DNS IANA Considerations" spelled it RR TYPE. The IANA registry says Resource Record (RR) TYPEs. Replacements of 2929 (5395 and 6195) have spelled it RRTYPE. Many of us spell it RRTYPE just because "type" is such a common word. I cannot recall seeing it as "RRtype", but that doesn't mean I haven't. > > > > "It is standard procedure within the IETF to document as standard > > those protocols and practices that have come into sufficient common > > use as to become part of the basic infrastructure." > > > > I would drop this. The charter already allows 4408bis to be published > > on the Standards Track. > > I don't think the charter comes into play here. The reason this text is there is to set up the rest, especially the part where we think SPF deserves advancement to the standards track. > I get SM's worry, though: it sounds like the document is attempting to make claims about how the IETF works, and there's no reason for us to say anything about it. What about this It is reasonable to conclude the experiment by making observations about which protocol has been most widely deployed, and standardizing it. ? > > In Appendix A: > > > > "the rigors of the RFC publication process." > > > > I suggest "Internet Standards Process". > > How about "IETF standards track process"? The official name from BCP 9 is "Internet Standards Process". > > "Later, after type 99 was assigned" > > > > I would say publication of RFC 4408 (Andrew might know about the > > procedure at that time). > > I believe the assignment came a short while before publication. Scott would know that history better than me, short of going back to look at the mxcomp archive. > There is a fascinating nest of trouble here. The expression "attractive nuisance" comes to mind. RFC 4408 was published in 2006. The RRTYPE assignment rules were, at the time, "IETF Consensus", as established by RFC 2929. However, perhaps amusingly, RFC 4020, which allowed for early IANA allocation of standards track code points, was published in 2005. It appears that the SPF dispute was part of the impetus for this. (Also, for the replacement of the rules in 2929 with something rather less absurd.) Better still, the earliest discussion of the SPF RRTYPE I am able to find in the namedroppers archive is from a request to add an agenda item to the meeting at IETF 61. That was in 2004. (I found this in the marc.info archive, because the IETF namedroppers archive doesn't go back that far, and the administrator of psg.com helpfully took the namedroppers archive off the Internet over a year ago -- with adequate libation you can probably get me to rant about this event -- so I might have missed something; but I don't think so.) However, RFC 4408 never was IETF consensus, of course -- that was in fact the point of the publication as it happened. Even under the rules of RFC 4020, I don't think 4408's RRTYPE request met the rules. So one can argue that the assignment of RRTYPE 99 _at all_ was an error. Isn't this fun? It seems to me that, unless we want to convene a meeting of the IETF Old Fart's Club so that we can debate this arcane point of IETF history, it would be better to stick to Murray's original formulation. It elides the details with no loss of accuracy. > > "[SPF] itself included a faulty transition plan, likely because of > > the late addition of a requirement to develop one: It said a > > server SHOULD publish both types and MUST publish at least one, > > while a client can query either or both, which means both can > > claim to be fully compliant while failing utterly to > > interoperate." > > > > I would put this to lack of IETF review. > > How about adding: "Publication occurred without proper IETF review, so this was not detected prior to publication." ? I think having a bunfight about who dropped this particular ball is a good way to distract people from the main conclusion. I wouldn't bother. (I will say that I fully expect a lot of complaining and defensiveness over this entire appendix, and I'm not sure that it'll do more good than harm. It reads awfully finger-waggy to me, even if I'm in a super sympathetic mood.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Apr 19 19:51: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 6268B11E80AE for ; Thu, 19 Apr 2012 19:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFVSrn-qdSCj for ; Thu, 19 Apr 2012 19:51:32 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E254511E80AA for ; Thu, 19 Apr 2012 19:51:31 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 2AD471ECB41D for ; Fri, 20 Apr 2012 02:51:31 +0000 (UTC) Date: Thu, 19 Apr 2012 22:51:29 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120420025129.GM94829@mail.yitter.info> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <1830748.75dlm12hFV@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1830748.75dlm12hFV@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 02:51:32 -0000 Dear colleagues, No hat. On Thu, Apr 19, 2012 at 05:50:52PM -0400, Scott Kitterman wrote: > > What lack of IETF review? Even though there was not a consensus > call for the draft that became SPF, Wayne Schlitt was very careful > to solicit reviews from the relevant IETF experts, including getting > reviews on namedroppers. Having just waded through a great deal of that review, I am not entirely sure that the solicitation resulted in a lot of good feelings on either side. TXT was just part of that train wreck. But in the interests of not needlessly opening old train-induced wounds, I really think that -- absent a lot of textual evidence and, maybe, references to interviews with the principals -- we ought to stand mute about the causes of past events. It's enough to say in this document that as a matter of fact there is a serious problem in the way the two RRTYPEs are used in the protocol. It doesn't matter why it happened. Any case where you have two different RRTYPEs used to do approximately the same thing runs the same risk, and it's a needless one. That's the core point of the text, and it seems worth making as a contribution to future interoperability. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Thu Apr 19 20:26: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 3CC5011E80E5 for ; Thu, 19 Apr 2012 20:26:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af3xC7SsUfh8 for ; Thu, 19 Apr 2012 20:26:36 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14411E8091 for ; Thu, 19 Apr 2012 20:26:36 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8D13320E409F; Thu, 19 Apr 2012 23:26:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334892395; bh=+PY4f0hgpI8NNXRmc7IwmqG19jdYSKq2MWGRKbnCCTw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=llwkr/pc7XCZjYQprMwjWNuFUPm6R9ZLivfSxwNQF4dD+oN7o5n0kA51hNd5rMRH7 DvLTzSH64ffr9zM/rOajTCPhM6JzsAq9yqgQEVoLynRSQzIz8jISYrAEafhoHPiHTB l6zjJ9G39VAU8YV0zzIRVZDmxOlspbeoH0eM/HFo= Received: from scott-latitude-e6320.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 ESMTPSA id 73BB820E408F; Thu, 19 Apr 2012 23:26:35 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 23:26:34 -0400 Message-ID: <2012536.4bt65atbq2@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120420025129.GM94829@mail.yitter.info> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <1830748.75dlm12hFV@scott-latitude-e6320> <20120420025129.GM94829@mail.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] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 03:26:37 -0000 On Thursday, April 19, 2012 10:51:29 PM Andrew Sullivan wrote: > Dear colleagues, > > No hat. > > On Thu, Apr 19, 2012 at 05:50:52PM -0400, Scott Kitterman wrote: > > What lack of IETF review? Even though there was not a consensus > > call for the draft that became SPF, Wayne Schlitt was very careful > > to solicit reviews from the relevant IETF experts, including getting > > reviews on namedroppers. > > Having just waded through a great deal of that review, I am not > entirely sure that the solicitation resulted in a lot of good feelings > on either side. TXT was just part of that train wreck. > > But in the interests of not needlessly opening old train-induced > wounds, I really think that -- absent a lot of textual evidence and, > maybe, references to interviews with the principals -- we ought to > stand mute about the causes of past events. It's enough to say in > this document that as a matter of fact there is a serious problem in > the way the two RRTYPEs are used in the protocol. It doesn't matter > why it happened. Any case where you have two different RRTYPEs used > to do approximately the same thing runs the same risk, and it's a > needless one. That's the core point of the text, and it seems worth > making as a contribution to future interoperability. > I agree with this. The one point that (and it doesn't matter why it happened this way) I think it important to consider for future efforts is that because the RR Type was assigned late there was almost no time to do the running code part of rough consensus and running code (ironically, because it was an experimental RFC the rough consensus part was skipped too). Late assignment was a problem that the IETF needs to be careful to avoid in the future. I don't care about digging into why or who's fault it was. Scott K From johnl@iecc.com Thu Apr 19 20:31: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 6F32F21F8562 for ; Thu, 19 Apr 2012 20:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.013 X-Spam-Level: X-Spam-Status: No, score=-111.013 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jziPl3vKyCZQ for ; Thu, 19 Apr 2012 20:31:27 -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 954AF21F84D8 for ; Thu, 19 Apr 2012 20:31:27 -0700 (PDT) Received: (qmail 88471 invoked from network); 20 Apr 2012 03:31:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2012 03:31:26 -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=4f90d88e.xn--9vv.k1204; i=johnl@user.iecc.com; bh=CY8o9LfmYfjLw805EhCrejfKnULZH00H+02GPZyIsf0=; b=ZxcD5fnpuEnq/4PB8VxFohxljlFVrIvFqrSNgLA3jtDX2AHNoBD4fCOadW1CzLgY43khSW26+QoeKEnwGl5DL0e5BGX7d9g9gGQxa9HiOc/MsMwbv05TYUGvDxA+lvt1gIecBJP9BLxs8zX9l2K26FWyCf19SOLHD1i06rkOZSs= 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=4f90d88e.xn--9vv.k1204; olt=johnl@user.iecc.com; bh=CY8o9LfmYfjLw805EhCrejfKnULZH00H+02GPZyIsf0=; b=mK+vSzpGfqbhYXz/dKbZ9aO71IF6F7UdmS5QkGMLksTugQD+nzCYEvSCpPeAuOuFJbE/HrsC+et9hP/yk2P7Yom6j5uVq7qeDYVemq8tWFd/8NB2MsuBoS4xQKjeWBrYEE/0scF5xeZGBkCHDORGShVilOgdzGTYKJmaxSLdVIE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Apr 2012 03:31:02 -0000 Message-ID: <20120420033102.7588.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2012536.4bt65atbq2@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] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 03:31:28 -0000 >I agree with this. The one point that (and it doesn't matter why it happened >this way) I think it important to consider for future efforts is that because >the RR Type was assigned late there was almost no time to do the running code >part of rough consensus and running code (ironically, because it was an >experimental RFC the rough consensus part was skipped too). Even if the language had been right, it's hard to imagine a transition from one RRTYPE to another once there's any installed base at all. R's, John From sm@resistor.net Thu Apr 19 20:34: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 C8AC021F858A for ; Thu, 19 Apr 2012 20:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HetwMT3t+E18 for ; Thu, 19 Apr 2012 20:34: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 60A2321F857A for ; Thu, 19 Apr 2012 20:34:47 -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 q3K3YgWU025099 for ; Thu, 19 Apr 2012 20:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334892886; i=@resistor.net; bh=Nr+7P8xmzmyQTryPQhZR0YVh2cxwl4Ib0ym6bWAYPtU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Api6Xejmc7Tbj3h5UijhMlvSnFs2PlCVDyqahSWPuV4p+kjZTm3Ryj+zoSgRtRY+E RyYbmLDemewA8eRGga4buifskXSxa9b3bCn8Nn6rExk6qZ70yvJ4m6RWd1Gxdc0h24 WklwOGBikWV627wThMlZxb8rlq0QVQmeRw6OQJWg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334892886; i=@resistor.net; bh=Nr+7P8xmzmyQTryPQhZR0YVh2cxwl4Ib0ym6bWAYPtU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=wXdVzaKHNAsV34O2biMZL78hMfVf8euvFcmwCTlu+vBtOFPex3k98ASz+ZNvXi6JV gMENU4OHsY5i8Kv1PKVkix1wbbdFKTq1kGWgZv9+mhOk06iiWOL+sMwQ6VtUtIIeZn 2JOpGRtUYeMVBstAj+T/IK2D2WnMTW/mjS+e+pbE= Message-Id: <6.2.5.6.2.20120419194006.0b441e58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Apr 2012 20:27:07 -0700 To: spfbis@ietf.org From: SM In-Reply-To: <20120420022728.GK94829@mail.yitter.info> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.com> <20120420022728.GK94829@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 03:34:49 -0000 At 19:27 19-04-2012, Andrew Sullivan wrote: >No hat. bis. :-) >RFC 1034 spells it RR type. See section 3.3. > >RFC 2929, the 2000-era "DNS IANA Considerations" spelled it RR TYPE. >The IANA registry says Resource Record (RR) TYPEs. Replacements of >2929 (5395 and 6195) have spelled it RRTYPE. > >Many of us spell it RRTYPE just because "type" is such a common word. > >I cannot recall seeing it as "RRtype", but that doesn't mean I >haven't. Thanks for documenting this. >I get SM's worry, though: it sounds like the document is attempting to >make claims about how the IETF works, and there's no reason for us to >say anything about it. What about this Yes. And it's good to remember that this WG is also part of the IETF. > It is reasonable to conclude the experiment by making observations > about which protocol has been most widely deployed, and > standardizing it. As my comments were editorial, I don't have any preference. >There is a fascinating nest of trouble here. The expression >"attractive nuisance" comes to mind. Yes. >item to the meeting at IETF 61. That was in 2004. (I found this in >the marc.info archive, because the IETF namedroppers archive doesn't >go back that far, and the administrator of psg.com helpfully took the >namedroppers archive off the Internet over a year ago -- with adequate I may have a backup of that list from a mirror. I did some quick cross-checking. I would not get into the historical details as part of a review unless there isn't any other option. >However, RFC 4408 never was IETF consensus, of course -- that was in >fact the point of the publication as it happened. Even under the >rules of RFC 4020, I don't think 4408's RRTYPE request met the rules. >So one can argue that the assignment of RRTYPE 99 _at all_ was an >error. Isn't this fun? :-) >(I will say that I fully expect a lot of complaining and defensiveness >over this entire appendix, and I'm not sure that it'll do more good >than harm. It reads awfully finger-waggy to me, even if I'm in a >super sympathetic mood.) I expect trouble. The draft could be cleansed by getting an external review before it gets to Last Call. Regards, -sm From spf2@kitterman.com Thu Apr 19 20:35: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 4F09F21F858E for ; Thu, 19 Apr 2012 20:35:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u3HlEb4Z+Xn for ; Thu, 19 Apr 2012 20:35:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69921F858A for ; Thu, 19 Apr 2012 20:35:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 382FF20E409F; Thu, 19 Apr 2012 23:35:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334892901; bh=OnESR6TzEqeTMUHzY3AZ7GDa+MJZokDrrpSPfgSESk8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=A3z8IulnjJ9L4q7u0i14jKjMvHhAtaXVxRX1rlY41j4X9mG7v6xhXkguZooaCmA1X B0sdFGIsSNKCajoRNPyOVkXrrqQJf0OGsSgGl1g3tmqVW6dTrb+9NTm9acSiszTAnk EK256joGsVh82SvlVM3qqYygZFSXT9dHsPyS1I2g= Received: from scott-latitude-e6320.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 ESMTPSA id 000B520E408F; Thu, 19 Apr 2012 23:35:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 23:35 -0400 Message-ID: <6545748.7hQS1rBIIj@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120420033102.7588.qmail@joyce.lan> References: <20120420033102.7588.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] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 03:35:02 -0000 On Friday, April 20, 2012 03:31:02 AM John Levine wrote: > >I agree with this. The one point that (and it doesn't matter why it > >happened this way) I think it important to consider for future efforts is > >that because the RR Type was assigned late there was almost no time to do > >the running code part of rough consensus and running code (ironically, > >because it was an experimental RFC the rough consensus part was skipped > >too). > > Even if the language had been right, it's hard to imagine a transition > from one RRTYPE to another once there's any installed base at all. I agree and that was obvious from the start, but the lack of time to experiment almost led us to deliver a spec that would have made it even harder. Scott K From ajs@anvilwalrusden.com Thu Apr 19 20:36: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 4A2DC11E80B2 for ; Thu, 19 Apr 2012 20:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVFZnawsVoJs for ; Thu, 19 Apr 2012 20:36:25 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B64C111E8091 for ; Thu, 19 Apr 2012 20:36:25 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 0CDCE1ECB41D for ; Fri, 20 Apr 2012 03:36:24 +0000 (UTC) Date: Thu, 19 Apr 2012 23:36:23 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120420033618.GO94829@mail.yitter.info> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <1830748.75dlm12hFV@scott-latitude-e6320> <20120420025129.GM94829@mail.yitter.info> <2012536.4bt65atbq2@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2012536.4bt65atbq2@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 03:36:26 -0000 On Thu, Apr 19, 2012 at 11:26:34PM -0400, Scott Kitterman wrote: > Late assignment was a problem that the IETF needs to be careful to avoid in > the future. I don't care about digging into why or who's fault it was. Aha. Well, that problem is solved now, so I don't think we need to comment on it either. (RRTYPE assignment is now by expert review. The last one took 3 weeks. It was for TLSA, which is what DANE is working to produce.) RRTYPEs that require special processing (think DNAME or DNSKEY) still require IETF consensus, and you can't really do early assignment in those cases, because it's dangerous. You need to do a lot of lab experiments, instead. Nobody wants these kinds of things, normally, however, so it's not a problem we need to solve, I think. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Thu Apr 19 20:52: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 D818721F8615 for ; Thu, 19 Apr 2012 20:52:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clMBuJV5kYC7 for ; Thu, 19 Apr 2012 20:52:56 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2962B21F860D for ; Thu, 19 Apr 2012 20:52:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BA03420E409F; Thu, 19 Apr 2012 23:52:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334893975; bh=r8QErblxZAAU90Q8iBBNTWJbfPkY9TFSUe996CZwEF8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ciJxoR87QFoPPjvBnxuWb/xJGcz+A9niRWYqBL6YEDx11JoQSrbNMwsmyB0IZG9yo gYAMwsmwicMaEv8wsoIJc4ESrnjB7naNvVyDdgWZaw7UlmdMsC4vHZyzvsjj+Ws5gf CFPBBCn+g+EY4VYC3knUC4USoT3HdasTh+tRdKsc= Received: from scott-latitude-e6320.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 ESMTPSA id ADAC520E408F; Thu, 19 Apr 2012 23:52:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Apr 2012 23:52:55 -0400 Message-ID: <3478442.SR8qoLpmtx@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120420033618.GO94829@mail.yitter.info> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <2012536.4bt65atbq2@scott-latitude-e6320> <20120420033618.GO94829@mail.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] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 03:52:57 -0000 On Thursday, April 19, 2012 11:36:23 PM Andrew Sullivan wrote: > On Thu, Apr 19, 2012 at 11:26:34PM -0400, Scott Kitterman wrote: > > Late assignment was a problem that the IETF needs to be careful to avoid > > in > > the future. I don't care about digging into why or who's fault it was. > > Aha. Well, that problem is solved now, so I don't think we need to > comment on it either. (RRTYPE assignment is now by expert review. > The last one took 3 weeks. It was for TLSA, which is what DANE is > working to produce.) > > RRTYPEs that require special processing (think DNAME or DNSKEY) still > require IETF consensus, and you can't really do early assignment in > those cases, because it's dangerous. You need to do a lot of lab > experiments, instead. Nobody wants these kinds of things, normally, > however, so it's not a problem we need to solve, I think. OK. Then maybe we should mention the problem and congratulate everyone on having solved it in the meantime so we're not just complaining. Scott K From msk@cloudmark.com Thu Apr 19 22:16: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 B226221F86F6 for ; Thu, 19 Apr 2012 22:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.664 X-Spam-Level: X-Spam-Status: No, score=-102.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6qqrPQz7ffj for ; Thu, 19 Apr 2012 22:16:39 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id D44FE21F846E for ; Thu, 19 Apr 2012 22:16:39 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 05Gc1j0010as01C015Gc9g; Thu, 19 Apr 2012 22:16:36 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=VCNWc_7EECYA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=Z5cbpT8XU_sLQQolnEEA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=Exr3hjyIGnX69X99:21 a=UfTE1aGrAwKqqZx0:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 22:16:17 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Comments on draft-ietf-spfbis-experiment-04 Thread-Index: AQHNHlwPBAjSL+wn80usOh3DX4DEbpainlhggADUiwCAABCqgP//pk5Q Date: Fri, 20 Apr 2012 05:16:16 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FBA2B@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.com> <20120420022728.GK94829@mail.yitter.info> <6.2.5.6.2.20120419194006.0b441e58@resistor.net> In-Reply-To: <6.2.5.6.2.20120419194006.0b441e58@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334898996; bh=Y3nZthbefUGX7SHqHKJnIppFBQjQObLyjYmOnZ0Sl2g=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=cK4J4E7Ugz4Gv7sWCXDzaE1UHsynS+OgfluYM8P1teUuGCQAfqkF9cwRq05ZCcFoF 5hrYohUVfjIaK0HQ9t2fsCsuarQpYE8tJMIJVeSiVJZgxPoOlR7l+1RVztIK2qmnXX q2PYBBvPfacAp1uUhPzjYBscMb7jFB1V3Yl6Bb44= Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 05:16:40 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of SM > Sent: Thursday, April 19, 2012 8:27 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 >=20 > >I get SM's worry, though: it sounds like the document is attempting to > >make claims about how the IETF works, and there's no reason for us to > >say anything about it. What about this >=20 > Yes. And it's good to remember that this WG is also part of the IETF. I don't understand this comment. Has someone forgotten that? > >(I will say that I fully expect a lot of complaining and defensiveness > >over this entire appendix, and I'm not sure that it'll do more good > >than harm. It reads awfully finger-waggy to me, even if I'm in a super > >sympathetic mood.) >=20 > I expect trouble. The draft could be cleansed by getting an external > review before it gets to Last Call. I think that would be a Fine Thing. I agree with the "finger-waggy" characterization, but the pain to which the= work was subjected really needs to be avoided. It made a big mess even wi= thout the fervent participant behaviour six years ago. Although it feels l= ike it's better now, there's no BCP in place act like a stopper against it = happening again. If this could be a first step in such a direction, I thin= k it's worth the risk. And if this is something the working group wants to say (and this is the fi= rst expression of any sort of concern about it), then we should try to say = it. At the same time, if there's truly no path forward including it, then I'm h= appy to take it out of here and see if it can find a home elsewhere. -MSK From msk@cloudmark.com Thu Apr 19 22:19: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 5D77021F86F6 for ; Thu, 19 Apr 2012 22:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEug4m8W-RGW for ; Thu, 19 Apr 2012 22:19:50 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9FD21F846E for ; Thu, 19 Apr 2012 22:19:50 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 05KU1j0010ZaKgw015KUtN; Thu, 19 Apr 2012 22:19:28 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=VCNWc_7EECYA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 22:19:28 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Comments on draft-ietf-spfbis-experiment-04 Thread-Index: AQHNHlwPBAjSL+wn80usOh3DX4DEbpajJZsAgABT/YCAAAnOAIAAAr6AgAAEnoD//6J1AA== Date: Fri, 20 Apr 2012 05:19:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FBA46@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <2012536.4bt65atbq2@scott-latitude-e6320> <20120420033618.GO94829@mail.yitter.info> <3478442.SR8qoLpmtx@scott-latitude-e6320> In-Reply-To: <3478442.SR8qoLpmtx@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334899168; bh=YOR0kJ0G8QqX6iL+7B/EeCJmpim0HRPYiCPiSjEGzz8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=xUBWfnJhCyR6s+ss7e9SsaUf8zHtGQH+juY6S5bw8S/0YY66mqk16PhIwGws/4odF BVyOIoXadPZBIR9+Ui45rx6guCIpaH1pEPccLFQUr7juDRFk6CUGUOEWzVikbQqmp3 3TDaFM1F1CpJUdPL1to1G+5aEJ/9NSJfTacT/ISI= Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 05:19:51 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Thursday, April 19, 2012 8:53 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 >=20 > OK. Then maybe we should mention the problem and congratulate everyone > on having solved it in the meantime so we're not just complaining. Does someone want to suggest replacement text for the Appendix to this end,= or following Andrew's suggestion? Or are we talking about leaving it? It's late and I'm having trouble following what it is we think we should be= saying instead of what's there now. -MSK From msk@cloudmark.com Thu Apr 19 22:26: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 03A7121F86BB for ; Thu, 19 Apr 2012 22:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz9d0Ym12e85 for ; Thu, 19 Apr 2012 22:25:59 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0EF21F86BA for ; Thu, 19 Apr 2012 22:25:59 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 05SH1j0010ZaKgw015SHC4; Thu, 19 Apr 2012 22:26:17 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=VCNWc_7EECYA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=Ghqh4ACBBoBeAOjoUj0A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 22:25:58 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Comments on draft-ietf-spfbis-experiment-04 Thread-Index: AQHNHlwPBAjSL+wn80usOh3DX4DEbpajJZsAgABT/YCAAAnOAIAAAr6AgAAEnoD//6J1AIAAATWg Date: Fri, 20 Apr 2012 05:25:56 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FBA73@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <2012536.4bt65atbq2@scott-latitude-e6320> <20120420033618.GO94829@mail.yitter.info> <3478442.SR8qoLpmtx@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FBA46@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FBA46@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334899577; bh=3kQOEnrCZ4zPTGY1j9iTj9cJIBdTIVe2LiGMYUXi8f4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=myu/HIOW4cGCUWcxUE9i1WAROEZlQS1Gm5atHrQOZ8DcB5Kqjwqg0NNszfRg7Yuws ojo1UTsgTxxUI+TUZZuueBuzIKW1LjyL5Tue4KmaS/Z9ebvwK3vGvQk09GX9pO9u5x c/C6IGvk9rAbVcnWxydEVvQoUj+nIOBGpUuKXEZY= Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 05:26:00 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Thursday, April 19, 2012 10:19 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 >=20 > It's late and I'm having trouble following what it is we think we > should be saying instead of what's there now. Also, I'm applying the change to use "RRTYPE" now, with a definition up fro= nt for good measure. I'll post -05 shortly. I suggest we start WGLC on -0= 5 and revise Appendix A as part of that since it's the only part we seem to= still be discussing, and it's not really part of the meat of the work. -MSK From internet-drafts@ietf.org Thu Apr 19 22:55: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 49E4721F8433; Thu, 19 Apr 2012 22:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92ahkyuNfT-q; Thu, 19 Apr 2012 22:55:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B149B21E8037; Thu, 19 Apr 2012 22:55:40 -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.00 Message-ID: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2012 22:55:40 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 05:55:41 -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 : Resolution of The SPF/Sender-ID Experiment Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-05.txt Pages : 11 Date : 2012-04-19 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender-ID, two proposed email authentication protocols. Because of possible interoperability issues, particularly but not only those created by simultaneous use of the two protocols by a receiver, the IESG was unable to determine technical consensus and decided it was best to publish all of RFC4405, RFC4406, RFC4407 and RFC4408 as Experimental documents. The IESG invited the community to observe their deployments for a period of time, and expressed hope for later convergence of opinion. After six years, sufficient experience and evidence have been collected that the experiment thus created can be considered concluded, and a single protocol can be advanced. This document presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-05.txt From msk@cloudmark.com Thu Apr 19 22:58: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 3517921E8036 for ; Thu, 19 Apr 2012 22:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.659 X-Spam-Level: X-Spam-Status: No, score=-102.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfu48K99G7Sc for ; Thu, 19 Apr 2012 22:58:30 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9D321E8025 for ; Thu, 19 Apr 2012 22:58:30 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 05yV1j0020as01C015yV1e; Thu, 19 Apr 2012 22:58:29 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=87i2ctr6TLgA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=B0I-nc4g8iaCzDeurSIA:9 a=4Rv6B9ChLXSITXZV5vQA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 22:58:29 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: I-D Action: draft-ietf-spfbis-experiment-05.txt Thread-Index: AQHNHrpEl78OTRuSrkOKtgToYqGV95ajN3ag Date: Fri, 20 Apr 2012 05:58:29 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> In-Reply-To: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334901509; bh=iYISkyppzs0usELTP4xikoIpqKw9GyKRgOJOPfqikCE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=u5qDa7lkaQaLEfZIxU/8XTiNZbJ7fPrj6naC/pvGspdB9ZTgeVyzYL96dQaKlHiRw N29QxoqbMm8dKNFMJXcrM0BYwXPFi8bLYrr66twtXdKBWAAZ6YheigCPPg/uC6DaUU ECnuS0/AH+du/ttiM4MR7Rb1z8VUMS0mAe2BXNtQ= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 05:58:31 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, April 19, 2012 10:56 PM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: I-D Action: draft-ietf-spfbis-experiment-05.txt >=20 > 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. >=20 > Title : Resolution of The SPF/Sender-ID Experiment > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-05.txt > Pages : 11 > Date : 2012-04-19 > [...] Incorporates co-chair review comments. No changes to Appendix A yet as dis= cussion is ongoing. -MSK From sm@resistor.net Thu Apr 19 23:46: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 C2F3621F873C for ; Thu, 19 Apr 2012 23:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csZnMRzyKmur for ; Thu, 19 Apr 2012 23:46: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 9DA8321F873A for ; Thu, 19 Apr 2012 23:46:25 -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 q3K6k8OX011816; Thu, 19 Apr 2012 23:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334904373; i=@resistor.net; bh=BebIF1UxfbVfl1+haUyP7BQRXog8C2VgtUEWjjcq390=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Bc65vB7PuZ2Vb+DYfhhqXuHLntqS85RJ78E2pXT6q4bhzgkehFy6C0zwukMB4xPQd l9r6ln+u9Mbqo1L6CGBwdF0atkwJ7uaZ46fGWWd85Q2fMSiNcSS4Ef+8n2oHweaArr dtLXujqDsXYlIYX9GrX/DNsSokCqZ7G4XoagBRC0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334904373; i=@resistor.net; bh=BebIF1UxfbVfl1+haUyP7BQRXog8C2VgtUEWjjcq390=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZhpHRXLuiolGVK/IGxNMnpuILpJq0QYwc7NGsRNkgGdUqALnucNHMiW2FvXuq0g/D c+F1FcRdT0PVeE76RYTQKTbcvFZORSOv1ywH9+2QMEn6Y8r2+hsqa2PM3ik+BY3eyr hwlJLzxA0xYWDM4w/B62baXFQUJXZGPr7R4376l4= Message-Id: <6.2.5.6.2.20120419223729.0a1d4b78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Apr 2012 23:32:31 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: <9452079D1A51524AA5749AD23E0039280FBA2B@exch-mbx901.corp.cl oudmark.com> References: <6.2.5.6.2.20120419110129.09902380@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB40A@exch-mbx901.corp.cloudmark.com> <20120420022728.GK94829@mail.yitter.info> <6.2.5.6.2.20120419194006.0b441e58@resistor.net> <9452079D1A51524AA5749AD23E0039280FBA2B@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 06:46:27 -0000 Hi Murray, At 22:16 19-04-2012, Murray S. Kucherawy wrote: >I don't understand this comment. Has someone forgotten that? I don't know. That didn't even cross my mind. >I agree with the "finger-waggy" characterization, but the pain to >which the work was subjected really needs to be avoided. It made a >big mess even without the fervent participant behaviour six years >ago. Although it feels like it's better now, there's no BCP in >place act like a stopper against it happening again. If this could >be a first step in such a direction, I think it's worth the risk. BCPs cannot fix such problems in my humble opinion. It's up to participants to figure out how to resolve issues. >And if this is something the working group wants to say (and this is >the first expression of any sort of concern about it), then we >should try to say it. I think that it is up to the working group to devise what it wants to say. >At the same time, if there's truly no path forward including it, >then I'm happy to take it out of here and see if it can find a home elsewhere. I'll stay out of this. At 22:19 19-04-2012, Murray S. Kucherawy wrote: >It's late and I'm having trouble following what it is we think we >should be saying instead of what's there now. Take a break. Regards, -sm From vesely@tana.it Fri Apr 20 02:20: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 0E33821F86DF for ; Fri, 20 Apr 2012 02:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.591 X-Spam-Level: X-Spam-Status: No, score=-4.591 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfj6DwEBt8n6 for ; Fri, 20 Apr 2012 02:20:55 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2B17C21F8644 for ; Fri, 20 Apr 2012 02:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334913653; bh=MEybZc7T0noTX1nSECc9Ygr82L9BXgRaZWJoAOSKBS0=; l=1124; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Zoa8uumz6yl43L/D15dGEyOeHnlGavJPA0gTrfdQ5OQPBlk00QFWLKNxcd5VA1cJr CToApw1E/HaxbK9Rju9v9CU28ulDgY+Cx3E4UsbAPP76Kt8HblKfGsIO8b+tixr6GU STcaSZN+VjTg2SmLpJeNDMVdQ0FBWbhGUyuICnTk= 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, 20 Apr 2012 11:20:53 +0200 id 00000000005DC039.000000004F912A75.0000554A Message-ID: <4F912A75.8030808@tana.it> Date: Fri, 20 Apr 2012 11:20:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120324090349.15462.qmail@joyce.lan> <4F902E82.8080606@tana.it> <9452079D1A51524AA5749AD23E0039280FACEE@exch-mbx901.corp.cloudmark.com> <1411716.v9dQfoyIUs@scott-latitude-e6320> In-Reply-To: <1411716.v9dQfoyIUs@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 09:20:56 -0000 On Fri 20/Apr/2012 11:09:12 +0200 Scott Kitterman wrote: > On Thursday, April 19, 2012 04:39:59 PM Murray S. Kucherawy wrote: >>> From: ietf.org On Behalf Of Alessandro Vesely >> >>> A mail server who opts to reject on fail needs to track all >>> forwarders and whitelist them. >> >> For this to appear in a standards document, you'll need to categorize >> exactly how one would identify a forwarder in a reliable way. IMHO, there is lots of room for progress there. For one thing, forcing users to repeat the same assertion twice is annoying and leads to inconsistencies. >> Mostly though it seems like we're hinting at some heuristics to improve on >> SPF's general accuracy. I suspect a collection of these might be useful to >> document someplace but I'm skeptical about putting them in SPFbis itself >> (though see also my suggestion about appendices and a separate operations >> document). > > It's in RFC 4408 9.3.3.1 already. Besides that paragraph's wording and position, the fact that such operations are to be carried out manually determines an unfair bias against low-volume senders. From vesely@tana.it Fri Apr 20 02:22: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 87C8221F8772 for ; Fri, 20 Apr 2012 02:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.594 X-Spam-Level: X-Spam-Status: No, score=-4.594 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SSnL7BTC9Qo for ; Fri, 20 Apr 2012 02:22:43 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8F30921F876F for ; Fri, 20 Apr 2012 02:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334913759; bh=jJEeP7Tb1aB8duPxZYECeEBYuhSwWvR7uiuHK8xvozg=; l=1541; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Zj1ZMFpVtkc/ShWCRT0AB6WynghLf0IZDdM4BJ95jrJpMd7ywKILn81wwg2Sgms8+ 2c58u0jhGUn0w9pYk1HHTUkItxCaSVrh2doJcK2sr56MWc+O7fq73HOgBJdLq3p5l7 lbNssgnn7jJMmcxbdfD4nHH7GYmu2HGsIK8/KxEA= 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, 20 Apr 2012 11:22:39 +0200 id 00000000005DC039.000000004F912ADF.000055F3 Message-ID: <4F912ADF.1070201@tana.it> Date: Fri, 20 Apr 2012 11:22:39 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120419164741.60726.qmail@joyce.lan> In-Reply-To: <20120419164741.60726.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 09:22:44 -0000 On Fri 20/Apr/2012 10:13:04 +0200 John Levine wrote: >>> +1 for SHOULD reject on EHLO fail > > Absolutely not. The SPF spec is about how you come up with an SPF > result given envelope information. It does not say anything about > what you do with the result. John, RFC 4408 says: if a claimed identity fails verification, local policy can take stronger action against such E-Mail, such as rejecting it. Yeah, it doesn't say CAN take action, but do we think reject-on-fail is not an integral part of SPF? > Should this group be so ill-advised as to start putting MTA design > advice into 4408bis, I doubt that I would be the only one to > object. As ill-advised as putting that kind of advice may be, it is even worse to write it in a form so concealed and reticent that makes it hard to even comprehend what the intended meaning might be. Remember the ADSP. I agree that 2119-language is not appropriate for wording this kind of advice. Nevertheless, we HAVE TO spell it loud and clear, as it would be hypocritical and error-prone to refer readers to some unwritten text in order to learn the difference between -all and ~all. > Since the charter makes it abundantly clear that we're not going to do > that, I will stop saying anything more on this topic, and I really > wish that other people would, too. Please, can we avoid these meta arguments? Servers misbehavior based on possible misunderstandings of the spec /is/ an issue, and the charter keeps clear from prohibiting to clarify it. From vesely@tana.it Fri Apr 20 02:32: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 C000921F867C for ; Fri, 20 Apr 2012 02:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofhUVpmmpDzW for ; Fri, 20 Apr 2012 02:32:17 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D6ABF21F8670 for ; Fri, 20 Apr 2012 02:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334914335; bh=66+ensQbLvSW1APqI1uPvmsjWULMbdQEUjuOvKOU2Vw=; l=1517; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=eP2B1FjUkz3FEi87+BsAciSNvURneJjwd/70qk4OuZEVhBDrlERzu3OK5OGGjVUqA Q720m98DR97En462IlSAMpUyEe0PZOSEFiKLH6qQvOyi2TEusGqslVke9e/Aq0tyG1 YcNstSMLMThzoQdCbIzoCfqfTPMIThY9XYGdl7oU= 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, 20 Apr 2012 11:32:15 +0200 id 00000000005DC039.000000004F912D1F.00005843 Message-ID: <4F912D1E.1000908@tana.it> Date: Fri, 20 Apr 2012 11:32:14 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120419164741.60726.qmail@joyce.lan> <4F9045AF.9020403@isdg.net> <20120419171652.GB94829@mail.yitter.info> <9452079D1A51524AA5749AD23E0039280FAF6E@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FAF6E@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 09:32:17 -0000 On Fri 20/Apr/2012 10:39:03 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Andrew Sullivan > >> I am unable to find in section 2.5, "Interpreting the result", of RFC >> 4408 the idea of a policy hardfail. Maybe you mean "Fail", section >> 2.5.4. If so, then that section is not consistent with what you say. >> It says this: >> >> A "Fail" result is an explicit statement that the client is not >> authorized to use the domain in the given identity. The checking >> software can choose to mark the mail based on this or to reject the >> mail outright. >> >> There is no SHOULD there, and there is no RFC 2119 language at all. >> This is, according to that text at least, purely a matter of local >> policy. > > I checked all the way back to the original Meng Weng Wong document > (thanks for the link, Scott). Rejection on fail was never a MUST > or even a SHOULD. > > SPF is input to local policy only. It could be one's local policy > to do exactly what SPF says, and it may even be almost doctrine for > some people that the whole Internet should work that way, but > that's not what the document has ever said. Did you manage to find out /who/ said it, then? > The same goes for DNSBLs (RFC5782) and ADSP (RFC5617). I wouldn't consider those a shining example of clarity. > DKIM even goes the opposite way, saying a failed signature isn't > grounds for rejection. Correct, DKIM does the authentication part only. That is covered by TCP for SPF concerns. From johnl@iecc.com Fri Apr 20 05:44: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 AE3CE21F876C for ; Fri, 20 Apr 2012 05:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.031 X-Spam-Level: X-Spam-Status: No, score=-111.031 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55Naw1i+sfqi for ; Fri, 20 Apr 2012 05:44:46 -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 EF72321F8766 for ; Fri, 20 Apr 2012 05:44:45 -0700 (PDT) Received: (qmail 89861 invoked from network); 20 Apr 2012 12:44:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2012 12:44:45 -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=4f915a3d.xn--3zv.k1204; i=johnl@user.iecc.com; bh=/sJZ7j81uUkNrA4P8Drhkb3KgH6AROcHTY6xCby6XOA=; b=ZC1+JCzXW7FasLPuVmMEywT/uFUnZ9Z+SeOqFLASI+FZURb94w5f8hnrES9M0Zjo3DThoLyH5ItbQ0KqPHHr7iTrYysICkGaYnBNH8Pgsa6yT9A2MC7xE37Uf941A+LDR33kN8f2W2e8onvcFAPLZouEPkcnOHQx+SQxbvTLp4M= 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=4f915a3d.xn--3zv.k1204; olt=johnl@user.iecc.com; bh=/sJZ7j81uUkNrA4P8Drhkb3KgH6AROcHTY6xCby6XOA=; b=XUIifpbDOaYgMpnzYB9VbMJzr0JeHQWtz4BeBE7W3iB+jeOjp07wZM5UJ4G8ta+mxkFUTFB1o63/3JdqKG96lcoiSRV/nycaKQYKLPiBcv8GNpsMMU5SqUPFdyLG+3lYDHRWjmmAKUKgMpPd5EcWa0uj1u36n7bp7CP8/mUDb+8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Apr 2012 12:44:23 -0000 Message-ID: <20120420124423.21010.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F912ADF.1070201@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 12:44:46 -0000 >Yeah, it doesn't say CAN take action, but do we think reject-on-fail >is not an integral part of SPF? Reject on fail is not an integral part of SPF. Many mail systems use it in other ways, such as an input to a scoring system, or to manage whitelisting. In this case, you are just wrong. Please stop. R's, John From ajs@anvilwalrusden.com Fri Apr 20 07:04: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 DB1F421F8736 for ; Fri, 20 Apr 2012 07:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVHiCxPpxqIi for ; Fri, 20 Apr 2012 07:04:34 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5741F21F872F for ; Fri, 20 Apr 2012 07:04:34 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 624721ECB41D for ; Fri, 20 Apr 2012 14:04:31 +0000 (UTC) Date: Fri, 20 Apr 2012 10:04:18 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120420140412.GA53610@mail.yitter.info> References: <20120419164741.60726.qmail@joyce.lan> <4F912ADF.1070201@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F912ADF.1070201@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Moderator note: no more discussion of "reject on fail" (was: #12: RFC 4408 Section 9 - Forwarding and helo identities) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 14:04:35 -0000 Dear colleagues, Moderator hat on. On Fri, Apr 20, 2012 at 11:22:39AM +0200, Alessandro Vesely wrote: > > Yeah, it doesn't say CAN take action, but do we think reject-on-fail > is not an integral part of SPF? I've already posted, several times, that anyone who wants to make this argument any more MUST provide a reference to text in RFC 4408 that clearly states something stronger than the local policy text already discussed. The alternative of empirical evidence that one local policy is universally used is already ruled out by the evidence so far presented. Unless you have an argument that is tightly bound to actual text in RFC 4408 and that shows something stronger than the local policy option that has been so far discussed, do not post on this topic. It is closed. People are no longer posting new arguments, and there is nothing more to discuss. Continued repetition of the same arguments will be treated as the disruptive behaviour that it is becoming. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From vesely@tana.it Fri Apr 20 07:11: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 9D0FC21F8699 for ; Fri, 20 Apr 2012 07:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk6jVwgra5sT for ; Fri, 20 Apr 2012 07:11:16 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D88FB21F866D for ; Fri, 20 Apr 2012 07:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334931074; bh=3ViEcf846yTgQgUBltTI/3xb2twGwShUUl7ZEU1XG0w=; l=2711; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lWmwjvI0lIZihpRjm8Tv7LoQJiovRleDfiRihR93+cOZhhenSm8oRkj+Yq8c1x3a9 kcxUB+sGTrRPkpp7vy4V9cX4LN/ptlYD+6fGQn0SO8arJPGUwC3+4JNvxth2LSwrBY oX4km4XNr14SCjdWsHdzOi71NknvUMHC4NI+1uBM= 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, 20 Apr 2012 16:11:14 +0200 id 00000000005DC039.000000004F916E82.000019BE Message-ID: <4F916E82.7020205@tana.it> Date: Fri, 20 Apr 2012 16:11:14 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 14:11:22 -0000 On Fri 20/Apr/2012 12:13:13 +0200 Murray S. Kucherawy wrote: > > Incorporates co-chair review comments. No changes to Appendix A > yet as discussion is ongoing. Why does it have to be an Appendix? But I hadn't commented on -04, so I take my chance now. *Abstract* and a single protocol can be advanced. Although "there can be only one" would more closely recall that movie, I'd also strike "single" from the last paragraph. *DNS Resource Record Types* | TXT replies | 397,511 | 39.8% | | SPF replies | 6,627 | <0.1% | | SPF+TXT replies | 6,603 | <0.1% | | spf2.0/* replies | 5,291 | <0.1% | Kudos for the tables. However, confusion may arise because row names are informal and the number of TXT records that are neither v=spf1 nor spf2.0 is missing. I'd suggest the following column names, or equivalent, where the leading phrase "domains having one or more RRs such that" is omitted: v=spf1 TXT any TXT any SPF (v=spf1 || spf2.0/*) both SPF && TXT spf2.0/* (TXT || SPF) google-site-verification TXT (for comparison) Or would it be better to put "TXT", "SPF", "either", or "both" in a separate column? In addition, it would help having a few words for characterizing how the domain names in the two surveys were selected/collected. *Analysis* 2. Of the records retrieved, fewer than 3% requested processing of messages using the PRA algorithm, which was an essential part of Sender-ID. This is formally incorrect, as the PRA algorithm can be applied to v=spf1 records by virtue of the compatibility equivalence of Section 3.4 of RFC 4406. What we can derive is the percentage of domains whose admins determined that PRA deserves a different treatment than MFROM. That is the percentage of domains that expect there to be a difference, and corroborates the analysis of differences carried out in Section 4. We can also infer, by comparing the orders of magnitude, that a good deal of domains didn't care about spf2.0 at all, but that's not related to the PRA specifically. *Experiences Developing SPF* I'd change the title to something containing the word "DNS", and possibly move it to a numbered section (i.e. not an appendix.) Furthermore, I'd mention the following: * The format of the SPF RRTYPE was defined to be identical to the corresponding TXT. Therefore, only one of the two advantages highlighted by RFC 5507 would have been attained. * Using the TXT RRTYPE in parallel should have prevented defining an SPF RRTYPE in the first place. [That's according to Section 3.5/1 of RFC 5507. What part of RFC 4020 leads to the same conclusion? The more DNS references we cite the better, IMHO.] From msk@cloudmark.com Fri Apr 20 07:32: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 F341E21F8630 for ; Fri, 20 Apr 2012 07:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leLSGj81RWPc for ; Fri, 20 Apr 2012 07:32:37 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5DE21F8629 for ; Fri, 20 Apr 2012 07:32:37 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 0EYc1j0010as01C01EYcPw; Fri, 20 Apr 2012 07:32:36 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=GHrnrXXKDOsA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MxNxKjxnZwpEMUl_IbwA:9 a=41yuS-se6z5FHYUc6z4A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=kz3QciXGA4ML5bKC:21 a=bryYYjohQX_pNPhl:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 07:32:36 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt Thread-Index: AQHNHrpEl78OTRuSrkOKtgToYqGV95ajN3aggAD/UgD//4x/kA== Date: Fri, 20 Apr 2012 14:32:35 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> In-Reply-To: <4F916E82.7020205@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334932356; bh=WuD5v2VZErir+GPVb7SkLyFpcyju+AykgzaWdQ2e/kE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=eTSI0lcJ9bX25pMxlizFAgetA1MwkGRZZsO/4XYAcYe5CvScOcMB0MY0FZFV/YGGE nblmCq8oEluCtZxiFZkOrJgRNYuVxUmAyZAFis0xIP0feRm8cCEpSVM1x0rg+NdFy1 o1RYOBRSsFCNnQD1LCH2V/YJjOgksi5tJw4tAJGc= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 14:32:38 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Friday, April 20, 2012 7:11 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt >=20 > On Fri 20/Apr/2012 12:13:13 +0200 Murray S. Kucherawy wrote: > > Incorporates co-chair review comments. No changes to Appendix A yet > > as discussion is ongoing. >=20 > Why does it have to be an Appendix? It is orthogonal to the main question being answered. > But I hadn't commented on -04, so I take my chance now. >=20 > *Abstract* >=20 > and a single protocol can be advanced. >=20 > Although "there can be only one" would more closely recall that movie, > I'd also strike "single" from the last paragraph. Apart from the cult movie reference, why is "single" harmful here? It's co= rrect. > *DNS Resource Record Types* >=20 > | TXT replies | 397,511 | 39.8% | > | SPF replies | 6,627 | <0.1% | > | SPF+TXT replies | 6,603 | <0.1% | > | spf2.0/* replies | 5,291 | <0.1% | >=20 > Kudos for the tables. However, confusion may arise because row names > are informal and the number of TXT records that are neither v=3Dspf1 nor > spf2.0 is missing. They also aren't relevant to answering the question of which of the two pro= tocols is in use. I could add a note saying only valid replies were tabulated, just to be cle= ar. > I'd suggest the following column names, or > equivalent, where the leading phrase "domains having one or more RRs > such that" is omitted: >=20 > v=3Dspf1 TXT > any TXT > any SPF > (v=3Dspf1 || spf2.0/*) both SPF && TXT > spf2.0/* (TXT || SPF) > google-site-verification TXT (for comparison) How do those additional details go toward answering the main question? > In addition, it would help having a few words for characterizing how > the domain names in the two surveys were selected/collected. The -05 version does say that. > *Analysis* >=20 > 2. Of the records retrieved, fewer than 3% requested processing of > messages using the PRA algorithm, which was an essential part of > Sender-ID. >=20 > This is formally incorrect, as the PRA algorithm can be applied to > v=3Dspf1 records by virtue of the compatibility equivalence of Section > 3.4 of RFC 4406. What we can derive is the percentage of domains whose > admins determined that PRA deserves a different treatment than MFROM. > That is the percentage of domains that expect there to be a difference, > and corroborates the analysis of differences carried out in Section 4. A sender that wants its mail to be subjected specifically to PRA evaluation= , and not to SPF, has to use an "spf2.0/*" record. A sender that is ambiva= lent about which of the two methods is to be used by receivers can use "v= =3Dspf1" and roll the dice. The only way to state "I want SPF only and not= PRA" is to include an "spf2.0/pra ?all" record in the RRset, but we saw on= ly a couple hundred of those across the entire survey. There's no obvious = explanation for that number, because it could well be that word about this = tool never made it to most people, or that provisioning tools don't allow f= or multi-record replies to TXT queries. So I believe what's cited is correct, though we could be more precise and s= ay "specifically requested" instead of just "requested" if you like. Relyi= ng on the compatibility stuff in RFC4406 doesn't constitute a specific requ= est. > We can also infer, by comparing the orders of magnitude, that a good > deal of domains didn't care about spf2.0 at all, but that's not related > to the PRA specifically. This is really getting at why the IESG did what it did in 2006. > *Experiences Developing SPF* >=20 > I'd change the title to something containing the word "DNS", and > possibly move it to a numbered section (i.e. not an appendix.) >=20 > Furthermore, I'd mention the following: >=20 > * The format of the SPF RRTYPE was defined to be identical to the > corresponding TXT. Therefore, only one of the two advantages > highlighted by RFC 5507 would have been attained. >=20 > * Using the TXT RRTYPE in parallel should have prevented defining an > SPF RRTYPE in the first place. [That's according to Section 3.5/1 > of RFC 5507. What part of RFC 4020 leads to the same conclusion? > The more DNS references we cite the better, IMHO.] Comments from others on these, since we're talking a lot about the appendix= ? There's an obvious point that 5507 came long after 4408... -MSK From ajs@anvilwalrusden.com Fri Apr 20 09: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 B726421F865F for ; Fri, 20 Apr 2012 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCDi-RBjxcqM for ; Fri, 20 Apr 2012 09:45:32 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3381321F8659 for ; Fri, 20 Apr 2012 09:45:32 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 41C7F1ECB41D for ; Fri, 20 Apr 2012 16:45:29 +0000 (UTC) Date: Fri, 20 Apr 2012 12:45:24 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120420164422.GC53610@mail.yitter.info> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F916E82.7020205@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 16:45:32 -0000 Dear colleagues, No hat. On Fri, Apr 20, 2012 at 04:11:14PM +0200, Alessandro Vesely wrote: > Kudos for the tables. However, confusion may arise because row names > are informal and the number of TXT records that are neither v=spf1 nor > spf2.0 is missing. Why would anyone care about that? > * The format of the SPF RRTYPE was defined to be identical to the > corresponding TXT. Therefore, only one of the two advantages > highlighted by RFC 5507 would have been attained. Well, if we really want open an immense can of worms, the fact is that defining two RRTYPEs such that their RDATA has to be the same is by definition preposterous, at least on the consumer side: there is absolutely no way to test the requirement. According to my casual investigations last night, that was a problem of which dnsext participants were actuely aware at the time this was being specified, but there seems to be a general assumption in SPF that DNS entries are by and large stable -- an assumption that is formally false but practically true enough to be useful. I don't think that the document ought to spend a lot of time investigating all the various ways that the DNS can be abused. I think it's a good idea to say, "Here's what happened when we did this." I think we are asking for an argument the more we start to try to explain those historical facts. > * Using the TXT RRTYPE in parallel should have prevented defining an > SPF RRTYPE in the first place. [That's according to Section 3.5/1 > of RFC 5507. What part of RFC 4020 leads to the same conclusion? > The more DNS references we cite the better, IMHO.] I'm not sure what RFC 5507 has to do with this. Also, I'm not sure what "the more DNS references we cite" is for here, since I can't see what (for instance) Dynamic Update or DNAME has to do with any of it. A -- Andrew Sullivan ajs@anvilwalrusden.com From presnick@qualcomm.com Fri Apr 20 09:45: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 5A38221F8564 for ; Fri, 20 Apr 2012 09:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd+mda+0dC+6 for ; Fri, 20 Apr 2012 09:45:42 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 16AAA21F8494 for ; Fri, 20 Apr 2012 09:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1334940342; x=1366476342; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; bh=jaZlnprSV6hH0pYkYsGBJAi+uo4OgDyDpaie9NrVBc0=; b=daK9NmKkrB8tEEb00UarV8JfnwKlkpUGPf3n6OdiWuVv6HIlWGC81I8T K2dx+Lv7sQxD0g3WT/untiCL4m3hZtzMbXIOolD2vCWxZ3jDbUXSL0ff6 LZzfskPKM7iJrl4bQCtAf2jw5vzgTT+NeANT5CayLAQTBW1zv/bWNrgBm 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6687"; a="181254570" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 20 Apr 2012 09:45:41 -0700 X-IronPort-AV: E=Sophos;i="4.75,453,1330934400"; d="scan'208,217";a="158789577" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Apr 2012 09:45:41 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 20 Apr 2012 09:45:41 -0700 Message-ID: <4F9192B0.1050308@qualcomm.com> Date: Fri, 20 Apr 2012 11:45:36 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E0039280FB328@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FB328@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------030800000606000707090607" X-Originating-IP: [172.30.39.5] Cc: "spfbis@ietf.org" Subject: Re: [spfbis] FW: Proposed IESG Statement on the Conclusion of Experiments X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Apr 2012 16:45:43 -0000 --------------030800000606000707090607 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 4/19/12 3:38 PM, Murray S. Kucherawy wrote: > Perhaps some of this is relevant to what we're doing in the experiment document. Timely... > I was just chatting with one of the chairs about this. I think the short answer is: It's not particularly relevant. The proposed IESG Statement is about how to deal with new Experimental docs that are about to be published (to make sure that someone starts thinking about how the experiment will conclude in the future) and old Experimental documents that have nobody working on them anymore (to make sure that we can get rid of the cruft at some point). SPFBIS, of course, is going above and beyond what the Statement anticipates by having a WG that is chartered to explicitly conclude an experiment and write a new standards track document. We're doing much more (and are in fact chartered to do much more) than is anticipated by the statement. Interesting, but no changes to our way of moving forward. pr > Subject: > Proposed IESG Statement on the Conclusion of Experiments > From: > Adrian Farrel > Date: > Thu, 19 Apr 2012 20:31:14 +0000 > To: > "ietf@ietf.org" , "wgchairs@ietf.org" > > To: > "ietf@ietf.org" , "wgchairs@ietf.org" > CC: > "iesg@ietf.org" > > > All, > > The IESG has been discussing how to tidy up after Experimental RFCs. > > We have developed the following draft IESG statement. This does not > represent a change in process, and continues to value Experimental RFCs > as an important part of the IETF process. It does, however, seek to > encourage documentation of the conclusion of experiments. > > We are aware that there may be other discussion points around > Experimental RFCs, and we would like to discuss these, but we also > believe that there is merit in making small, incremental improvements. > > The IESG would welcome your thoughts on this draft before they approve > the final text on April 26th. > > Thanks, > Adrian > > ============= > > IESG Statement on Conclusion of IETF Experiments > > > Experiments are an established and valuable part of the IETF process. > A number of core Internet protocols were first published as Experimental > RFCs while the community gathered experience and carefully investigated > the consequences of deploying new mechanisms within the Internet. > > In the case where an experiment leads on to the development of a > Standards Track RFC documenting a protocol, the new RFC obsoletes the > old Experimental RFC and there is a clear conclusion to the experiment. > > However, many experiments do not lead to the development of Standards > Track RFCs. Instead, the work may be abandoned through lack of interest > or because important lessons have been learned. > > It is currently hard to distinguish between an experiment that is still > being investigated, and an old experiment that has ceased to be of > interest to the community. In both cases an Experimental RFC exists in > the repository and newcomers might easily be misled into thinking that > it would be helpful to conduct more research into an abandoned > experiment. > > In view of this, the original proponents of experiments (that is, > authors of Experimental RFCs, and Working Groups that requested the > publication of Experimental RFCs) are strongly encouraged to document > the termination of experiments that do not result in subsequent > Standards Track work by publishing an Informational RFC that: > > - very briefly describes the results of the experiment > > - obsoletes the Experimental RFC > > - if appropriate, deprecate any IANA code points allocated for the > experiment > > - may request that the Experimental RFC is moved to Historic status. > > If there is no energy in the community for the producing such an > Informational RFC, if the authors have moved on to other things, or if > the Working Group has been closed down, Area Directors should author or > seek volunteers to author such an Informational RFC. > > > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------030800000606000707090607 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 4/19/12 3:38 PM, Murray S. Kucherawy wrote: 
Perhaps some of this is relevant to what we're doing in the experiment document.  Timely...

I was just chatting with one of the chairs about this. I think the short answer is: It's not particularly relevant. The proposed IESG Statement is about how to deal with new Experimental docs that are about to be published (to make sure that someone starts thinking about how the experiment will conclude in the future) and old Experimental documents that have nobody working on them anymore (to make sure that we can get rid of the cruft at some point). SPFBIS, of course, is going above and beyond what the Statement anticipates by having a WG that is chartered to explicitly conclude an experiment and write a new standards track document. We're doing much more (and are in fact chartered to do much more) than is anticipated by the statement.

Interesting, but no changes to our way of moving forward.

pr

Subject:
Proposed IESG Statement on the Conclusion of Experiments
From:
Adrian Farrel <adrian@olddog.co.uk>
Date:
Thu, 19 Apr 2012 20:31:14 +0000
To:
"ietf@ietf.org" <ietf@ietf.org>, "wgchairs@ietf.org" <wgchairs@ietf.org>
To:
"ietf@ietf.org" <ietf@ietf.org>, "wgchairs@ietf.org" <wgchairs@ietf.org>
CC:
"iesg@ietf.org" <iesg@ietf.org>		 

All,

The IESG has been discussing how to tidy up after Experimental RFCs.

We have developed the following draft IESG statement. This does not 
represent a change in process, and continues to value Experimental RFCs
as an important part of the IETF process. It does, however, seek to 
encourage documentation of the conclusion of experiments.

We are aware that there may be other discussion points around 
Experimental RFCs, and we would like to discuss these, but we also
believe that there is merit in making small, incremental improvements.

The IESG would welcome your thoughts on this draft before they approve
the final text on April 26th.

Thanks,
Adrian

=============

IESG Statement on Conclusion of IETF Experiments


Experiments are an established and valuable part of the IETF process.
A number of core Internet protocols were first published as Experimental
RFCs while the community gathered experience and carefully investigated
the consequences of deploying new mechanisms within the Internet.

In the case where an experiment leads on to the development of a      
Standards Track RFC documenting a protocol, the new RFC obsoletes the 
old Experimental RFC and there is a clear conclusion to the experiment.

However, many experiments do not lead to the development of Standards
Track RFCs. Instead, the work may be abandoned through lack of interest
or because important lessons have been learned.

It is currently hard to distinguish between an experiment that is still
being investigated, and an old experiment that has ceased to be of
interest to the community. In both cases an Experimental RFC exists in
the repository and newcomers might easily be misled into thinking that
it would be helpful to conduct more research into an abandoned
experiment.

In view of this, the original proponents of experiments (that is, 
authors of Experimental RFCs, and Working Groups that requested the
publication of Experimental RFCs) are strongly encouraged to document
the termination of experiments that do not result in subsequent
Standards Track work by publishing an Informational RFC that:

- very briefly describes the results of the experiment

- obsoletes the Experimental RFC

- if appropriate, deprecate any IANA code points allocated for the 
  experiment

- may request that the Experimental RFC is moved to Historic status.

If there is no energy in the community for the producing such an
Informational RFC, if the authors have moved on to other things, or if
the Working Group has been closed down, Area Directors should author or
seek volunteers to author such an Informational RFC.

  

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

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------030800000606000707090607-- From vesely@tana.it Fri Apr 20 10:24: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 E08F521F84CD for ; Fri, 20 Apr 2012 10:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxutA-J9qE3S for ; Fri, 20 Apr 2012 10:24:00 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7B23A21F84C9 for ; Fri, 20 Apr 2012 10:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334942639; bh=iwU2iyQbPGnCnjS7Dh4o50DTGsnV+5n1UwS3ZLuA7E0=; l=4977; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=PxO5bYA0nix610y4ngCLmUT23VLlWL4rDwqDzHggzthGbl8A1R4jajFABZ1+rRweo FXl7zFjCR5F2bEmhW7b2RffCZYKq6R1MiDWvRuGvSnuL/Uq7nlvZ+vETe0gbmcrCRY ZkOos7emy3i2zZBBYIZVd92DDynJ1KTFdfakC2ZI= 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, 20 Apr 2012 19:23:59 +0200 id 00000000005DC042.000000004F919BAF.00004A54 Message-ID: <4F919BAF.1040303@tana.it> Date: Fri, 20 Apr 2012 19:23:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 17:24:02 -0000 On Fri 20/Apr/2012 18:08:53 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> Why does it have to be an Appendix? > > It is orthogonal to the main question being answered. I assume you mean the main question being asked. Doesn't it get less emphasis than it deserves, that way? >> *Abstract* >> >> and a single protocol can be advanced. >> >> Although "there can be only one" would more closely recall that movie, >> I'd also strike "single" from the last paragraph. > > Apart from the cult movie reference, why is "single" harmful here? > It's correct. It is correct after the charter assumptions, but it emphasizes them unnecessarily. Anyway, it was just an aesthetic consideration. >> *DNS Resource Record Types* >> >> | TXT replies | 397,511 | 39.8% | >> | SPF replies | 6,627 | <0.1% | >> | SPF+TXT replies | 6,603 | <0.1% | >> | spf2.0/* replies | 5,291 | <0.1% | >> >> Kudos for the tables. However, confusion may arise because row names >> are informal and the number of TXT records that are neither v=spf1 nor >> spf2.0 is missing. > > They also aren't relevant to answering the question of which of the > two protocols is in use. No, they aren't. They just help evaluate the background noise. > I could add a note saying only valid replies were tabulated, just > to be clear. Yes please. If you run a syntax check, or a record selection according to Section 4.5 of RFC 4408, please say so. >> I'd suggest the following column names, or >> equivalent, where the leading phrase "domains having one or more RRs >> such that" is omitted: >> >> v=spf1 TXT >> any TXT >> any SPF >> (v=spf1 || spf2.0/*) both SPF && TXT >> spf2.0/* (TXT || SPF) >> google-site-verification TXT (for comparison) > > How do those additional details go toward answering the main question? The "any TXT" and "google-site-verification TXT" parts are only relevant for the DNS usage appendix. >> In addition, it would help having a few words for characterizing how >> the domain names in the two surveys were selected/collected. > > The -05 version does say that. You don't mean: Specifically, these surveys pulled a large number of domain names from recent activity logs and queried their nameservers for both RRTYPEs that can be used for SPF and/or Sender-ID. Do you? It doesn't tell the difference between the two. >> *Analysis* >> >> 2. Of the records retrieved, fewer than 3% requested processing of >> messages using the PRA algorithm, which was an essential part of >> Sender-ID. >> >> This is formally incorrect, as the PRA algorithm can be applied to >> v=spf1 records by virtue of the compatibility equivalence of Section >> 3.4 of RFC 4406. What we can derive is the percentage of domains whose >> admins determined that PRA deserves a different treatment than MFROM. >> That is the percentage of domains that expect there to be a difference, >> and corroborates the analysis of differences carried out in Section 4. > > A sender that wants its mail to be subjected specifically to PRA > evaluation, and not to SPF, has to use an "spf2.0/*" record. ^^^^^^^^^^^^^^^^^^^^^^^^^MFROM? Ditto reversing MFROM and PRA. > A sender that is ambivalent about which of the two methods is to be > used by receivers can use "v=spf1" and roll the dice. The only way > to state "I want SPF only and not PRA" is to include an "spf2.0/pra > ?all" record in the RRset, but we saw only a couple hundred of > those across the entire survey. There's no obvious explanation for > that number, because it could well be that word about this tool > never made it to most people, or that provisioning tools don't > allow for multi-record replies to TXT queries. I see no rational explanation either. With or without tool, they are complicated stuff to write and to maintain. An irrational feeling could be derived from the tendency to associate MFROM with v=spf1, and it's easier to feel than to ratiocinate :-/ There are thousands "spf2.0/pra" but only hundreds "spf2.0/mfrom". Would that mean that PRA is perceived as more important than MFROM by those who opt for specific treatments? > So I believe what's cited is correct, though we could be more > precise and say "specifically requested" instead of just > "requested" if you like. Relying on the compatibility stuff in > RFC4406 doesn't constitute a specific request. Adding "specifically" makes the sentence correct at least until the comma. I'm not sure whether the ability to differentiate the two is (or was) an essential part of Sender-ID. >> We can also infer, by comparing the orders of magnitude, that a good >> deal of domains didn't care about spf2.0 at all, but that's not related >> to the PRA specifically. > > This is really getting at why the IESG did what it did in 2006. And we'd probably better not making it explicit. Numbers speak by themselves. From dotis@mail-abuse.org Fri Apr 20 10:25: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 DE06821F84D2 for ; Fri, 20 Apr 2012 10:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuN2FXg1XUT1 for ; Fri, 20 Apr 2012 10:25:17 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7526421F84CD for ; Fri, 20 Apr 2012 10:25:17 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id EDC7C174039A for ; Fri, 20 Apr 2012 17:25:16 +0000 (UTC) Message-ID: <4F919BFE.5040003@mail-abuse.org> Date: Fri, 20 Apr 2012 10:25:18 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 17:25:18 -0000 On 4/19/12 10:58 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Thursday, April 19, 2012 10:56 PM >> To: i-d-announce@ietf.org >> Cc: spfbis@ietf.org >> Subject: I-D Action: draft-ietf-spfbis-experiment-05.txt >> >> 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 : Resolution of The SPF/Sender-ID Experiment >> Author(s) : Murray S. Kucherawy >> Filename : draft-ietf-spfbis-experiment-05.txt >> Pages : 11 >> Date : 2012-04-19 >> [...] > Incorporates co-chair review comments. No changes to Appendix A yet as discussion is ongoing. Dear Murray, Thank you for your excellent efforts. Would you consider expanding DNS resource deployment tables to include contained macro use? Some of these are at thresholds used to justify deprecation of other items, such as RR types. This could help shape future cruft ridding efforts. Regards, Douglas Otis From msk@cloudmark.com Fri Apr 20 10:35: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 9B56D21F867B for ; Fri, 20 Apr 2012 10:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8g8xavF+I4W for ; Fri, 20 Apr 2012 10:35:06 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id E23F521F8670 for ; Fri, 20 Apr 2012 10:35:06 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 0Hb61j0030as01C01Hb6Lr; Fri, 20 Apr 2012 10:35:06 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=GHrnrXXKDOsA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=RHg2iD6gMy15uB39QtUA:9 a=07TMis5L8mOrdCZr7RUA:7 a=CjuIK1q_8ugA:10 a=kkUMZHjH4KkA:10 a=lZB815dzVvQA:10 a=cKKdn-SOnwvQ05Fl:21 a=woZifPxNnFldbU-W:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 10:35:06 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt Thread-Index: AQHNHrpEl78OTRuSrkOKtgToYqGV95ajN3aggAD/UgD//4x/kIAAqVuA//+K5pA= Date: Fri, 20 Apr 2012 17:35:05 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> In-Reply-To: <4F919BAF.1040303@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334943306; bh=nu0VpKdQHGokM8xLYMdLgXyWb7zpe6xbtcXftQQ3dfo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=fC6SBynJjr8OjRVI/TfZgdX47x3jxS3XRlb4iN9qoOasVpJaKiIFU0Z9mawOqF/8r LeWqxao9t/OEgnJ6jNu7M01wFlTlT5cZSlO8uyLViWiKdNE1zDa3n5gEhFaef/K51w qoX0hxWGnO5g5oXWS48rPdpqknkR47bTSWtx4YT8= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 17:35:07 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Alessandro Vesely > Sent: Friday, April 20, 2012 10:24 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt >=20 > On Fri 20/Apr/2012 18:08:53 +0200 Murray S. Kucherawy wrote: > >> From: ietf.org On Behalf Of Alessandro Vesely > > > >> Why does it have to be an Appendix? > > > > It is orthogonal to the main question being answered. >=20 > I assume you mean the main question being asked. Doesn't it get less > emphasis than it deserves, that way? Yes, and rightly so. The document isn't supposed to be a treatise on SPF h= istory. It's just meant to answer a question. As it happens we have a lot= of information relevant to IETF current practices with respect to RRTYPE a= llocation, and it seems like the community could learn from the SPF experie= nce if it were to be summarized someplace, especially since it's a recurrin= g topic in the community. The "as it happens" bit means it shouldn't go in= the main body of the document. > >> *DNS Resource Record Types* > >> > >> | TXT replies | 397,511 | 39.8% | > >> | SPF replies | 6,627 | <0.1% | > >> | SPF+TXT replies | 6,603 | <0.1% | > >> | spf2.0/* replies | 5,291 | <0.1% | > >> > >> Kudos for the tables. However, confusion may arise because row names > >> are informal and the number of TXT records that are neither v=3Dspf1 > >> nor > >> spf2.0 is missing. > > > > They also aren't relevant to answering the question of which of the > > two protocols is in use. >=20 > No, they aren't. They just help evaluate the background noise. True, but that goes to SPF implementation advice (i.e., "be prepared to pro= cess a ton of crap while you're getting DNS answers"), not to the question = of adoption rates. > > I could add a note saying only valid replies were tabulated, just to > > be clear. >=20 > Yes please. If you run a syntax check, or a record selection according > to Section 4.5 of RFC 4408, please say so. Added such a note for the next version. > > How do those additional details go toward answering the main question? >=20 > The "any TXT" and "google-site-verification TXT" parts are only > relevant for the DNS usage appendix. Only if we want the appendix also to discuss arbitrary junk an SPF verifier= will have to handle. That seems to be to be the kind of thing to emphasiz= e in RFC4408bis itself as implementation advice though, not for the experim= ent document. > >> In addition, it would help having a few words for characterizing how > >> the domain names in the two surveys were selected/collected. > > > > The -05 version does say that. >=20 > You don't mean: >=20 > Specifically, these surveys pulled a large number of domain names > from recent activity logs and queried their nameservers for both > RRTYPEs that can be used for SPF and/or Sender-ID. >=20 > Do you? It doesn't tell the difference between the two. Yes, that's what I meant. That text indicates how the domains were selecte= d and exactly how they were queried. What's missing? > >> This is formally incorrect, as the PRA algorithm can be applied to > >> v=3Dspf1 records by virtue of the compatibility equivalence of Section > >> 3.4 of RFC 4406. What we can derive is the percentage of domains > >> whose admins determined that PRA deserves a different treatment than M= FROM. > >> That is the percentage of domains that expect there to be a > >> difference, and corroborates the analysis of differences carried out > in Section 4. > > > > A sender that wants its mail to be subjected specifically to PRA > > evaluation, and not to SPF, has to use an "spf2.0/*" record. > ^^^^^^^^^^^^^^^^^^^^^^^^^MFROM? >=20 > Ditto reversing MFROM and PRA. Why? If I want MFROM processing only, I can use "spf2.0/mfrom" or "v=3Dspf= 1". If I want PRA processing only, I can't say "v=3Dspf1" or I might get M= FROM processing from SPF-only verifiers. So the reverse is not true. > There are thousands "spf2.0/pra" but only hundreds "spf2.0/mfrom". > Would that mean that PRA is perceived as more important than MFROM by > those who opt for specific treatments? It would mean there are more requests for PRA processing than MFROM process= ing directed at verifiers that understand Sender-ID. It contains no inform= ation for SPF-only verifiers. -MSK From msk@cloudmark.com Fri Apr 20 10:36: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 0AC0221F85C7 for ; Fri, 20 Apr 2012 10:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idRqOErrBL03 for ; Fri, 20 Apr 2012 10:36:04 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id A5A8E21F85C2 for ; Fri, 20 Apr 2012 10:36:04 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 0Hc41j0010as01C01Hc4MQ; Fri, 20 Apr 2012 10:36:04 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=GHrnrXXKDOsA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=xAWAlFL5FEp-oojh_aYA:9 a=f2pdhEmTH8AE384H_GcA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 10:36:04 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt Thread-Index: AQHNHrpEl78OTRuSrkOKtgToYqGV95ajN3aggAE1igD//41v8A== Date: Fri, 20 Apr 2012 17:36:03 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FC8D4@exch-mbx901.corp.cloudmark.com> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F919BFE.5040003@mail-abuse.org> In-Reply-To: <4F919BFE.5040003@mail-abuse.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334943364; bh=St5+UnVSPvO0dWjhmUQd10fzPsZvua6uwpzVDiz0MRU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GqKgV30SF85SjL90aplswQDHjeJ9Z9tzRgj/Wc9pYmqdceTJloFMbkK56sGMWdjOF UQVr7XI7lszC/bb7dAGg6BWBHII/YERSXb67eHL5RFIry+CP3B82iShEBeKrtANhK2 TwEgbSmZMJDgRHUkbiYWV0XYncMp4oJ8C9jKGfCQ= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 17:36:05 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Douglas Otis > Sent: Friday, April 20, 2012 10:25 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt >=20 > Would you consider expanding DNS resource deployment tables to include > contained macro use? Some of these are at thresholds used to justify > deprecation of other items, such as RR types. This could help shape > future cruft ridding efforts. We have those data in both of the DNS survey tables (which you can access y= ourself; see previous posts), but they are immaterial for this document. T= hey can be used when we crack open RFC4408bis if we need to. -MSK From vesely@tana.it Fri Apr 20 11:13: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 CE4B121F8636 for ; Fri, 20 Apr 2012 11:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.595 X-Spam-Level: X-Spam-Status: No, score=-4.595 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmOPSuRfVW6V for ; Fri, 20 Apr 2012 11:13:55 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F331021F8533 for ; Fri, 20 Apr 2012 11:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334945633; bh=fdRyozYTaSUz4fFNIQkwGS7Pj8A2JWIvzLXz6ZuCXKw=; l=1560; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=he2KnKX2KVXwBZZL6sQoRAvce53ihjU0gr2qHzDYBb5vmwDAwwt4TEIgkKUdBzU14 AziRMXW6AkP4Yq+fnd/uRe9gcbBTdy2tmyLeiLIM1vBP2ms2ixp88xWLYjo/XF9gsn CFEHSM20FXliOM+wlrAey/ySqeaWi2gLUN3T7Le4= 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, 20 Apr 2012 20:13:53 +0200 id 00000000005DC039.000000004F91A761.0000559E Message-ID: <4F91A761.8050500@tana.it> Date: Fri, 20 Apr 2012 20:13:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 18:13:55 -0000 On Fri 20/Apr/2012 19:52:19 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> The "any TXT" and "google-site-verification TXT" parts are only >> relevant for the DNS usage appendix. > > Only if we want the appendix also to discuss arbitrary junk an SPF > verifier will have to handle. That seems to be to be the kind of > thing to emphasize in RFC4408bis itself as implementation advice > though, not for the experiment document. The two main issues RFC 5507 brings on why adding a new RRTYPE are the collision with other uses of TXT, and space considerations in DNS messages. The second can be considered a consequence of the first, and we can provide some numbers on how the first goes in our case. >> You don't mean: >> >> Specifically, these surveys pulled a large number of domain names >> from recent activity logs and queried their nameservers for both >> RRTYPEs that can be used for SPF and/or Sender-ID. >> >> Do you? It doesn't tell the difference between the two. > > Yes, that's what I meant. That text indicates how the domains were > selected and exactly how they were queried. What's missing? Any clue on how/why they differ from one another? Anything that may characterize one sample w.r.t. the other? >> Ditto reversing MFROM and PRA. > > Why? If I want MFROM processing only, I can use "spf2.0/mfrom" or > "v=spf1". No, the compatibility stuff says: Sender ID implementations SHOULD interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom,pra" From msk@cloudmark.com Fri Apr 20 11:16: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 E9B2621F863B for ; Fri, 20 Apr 2012 11:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW6SjcJic5pV for ; Fri, 20 Apr 2012 11:16:47 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 19ABB21F8657 for ; Fri, 20 Apr 2012 11:16:47 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 0JGj1j0010as01C01JGjZu; Fri, 20 Apr 2012 11:16:43 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=GHrnrXXKDOsA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=x0EWPLzeIjXC_YBFKkYA:9 a=5v3p25qNTk19tAHzxPIA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=o_XH0M_sGjXxyxVE:21 a=u9GaAtHhFuR5d-rp:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 11:16:43 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt Thread-Index: AQHNHrpEl78OTRuSrkOKtgToYqGV95ajN3aggAD/UgD//4x/kIAAqVuA//+K5pCAAIMLgP//iwsA Date: Fri, 20 Apr 2012 18:16:42 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@tana.it> In-Reply-To: <4F91A761.8050500@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334945803; bh=biUv160KovFMpongsxD9YUKGiM2oiadjdIJCda4qkrg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=xC4Jrp6oLYGev/IPfud6e7cpU/0KyAQVCiz7H37BVMLQzqEFElwjmLbDfF0nExuKZ YF3MGWhOJsXsMvSj3e2h/IyT3wTzv8FJdjA/TQyCdJ8BHGLtasHi4+xylO7B+MxZ2n 4MjoUW6JOU0N7VD9/8D8phUmZ90UEDsjUR002c/M= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 18:16:48 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Friday, April 20, 2012 11:14 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt >=20 > > Only if we want the appendix also to discuss arbitrary junk an SPF > > verifier will have to handle. That seems to be to be the kind of > > thing to emphasize in RFC4408bis itself as implementation advice > > though, not for the experiment document. >=20 > The two main issues RFC 5507 brings on why adding a new RRTYPE are the > collision with other uses of TXT, and space considerations in DNS > messages. The second can be considered a consequence of the first, and > we can provide some numbers on how the first goes in our case. We could include a "See RFC5507 for further related discussion" if you like= . > >> You don't mean: > >> > >> Specifically, these surveys pulled a large number of domain names > >> from recent activity logs and queried their nameservers for both > >> RRTYPEs that can be used for SPF and/or Sender-ID. > >> > >> Do you? It doesn't tell the difference between the two. > > > > Yes, that's what I meant. That text indicates how the domains were > > selected and exactly how they were queried. What's missing? >=20 > Any clue on how/why they differ from one another? Anything that may > characterize one sample w.r.t. the other? What's "they"? I don't know what you're comparing. > >> Ditto reversing MFROM and PRA. > > > > Why? If I want MFROM processing only, I can use "spf2.0/mfrom" or > > "v=3Dspf1". >=20 > No, the compatibility stuff says: >=20 > Sender ID implementations SHOULD interpret the version prefix > "v=3Dspf1" as equivalent to "spf2.0/mfrom,pra" "spf2.0/mfrom,pra" is not MFROM only, nor is it PRA only. -MSK From dotis@mail-abuse.org Fri Apr 20 11:25: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 7904D21F8665 for ; Fri, 20 Apr 2012 11:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rthgAl776KJu for ; Fri, 20 Apr 2012 11:25:27 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id DBD9621F8584 for ; Fri, 20 Apr 2012 11:25:27 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id C19A517401A1 for ; Fri, 20 Apr 2012 18:25:27 +0000 (UTC) Message-ID: <4F91AA19.9020701@mail-abuse.org> Date: Fri, 20 Apr 2012 11:25:29 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> In-Reply-To: <4F919BAF.1040303@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 18:25:28 -0000 On 4/20/12 10:23 AM, Alessandro Vesely wrote: > On Fri 20/Apr/2012 18:08:53 +0200 Murray S. Kucherawy wrote: > >> From: ietf.org On Behalf Of Alessandro Vesely > > > >> Why does it have to be an Appendix? > > > > It is orthogonal to the main question being answered. > > I assume you mean the main question being asked. Doesn't it get > less emphasis than it deserves, that way? > > >> *Abstract* > >> > >> and a single protocol can be advanced. > >> > >> Although "there can be only one" would more closely recall that > >> movie, I'd also strike "single" from the last paragraph. > > > > Apart from the cult movie reference, why is "single" harmful here? > > It's correct. > > It is correct after the charter assumptions, but it emphasizes them > unnecessarily. Anyway, it was just an aesthetic consideration. > > >> *DNS Resource Record Types* > >> > >> | TXT replies | 397,511 | 39.8% | | SPF replies | > >> 6,627 | <0.1% | | SPF+TXT replies | 6,603 | <0.1% | | > >> spf2.0/* replies | 5,291 | <0.1% | > >> > >> Kudos for the tables. However, confusion may arise because row > >> names are informal and the number of TXT records that are neither > >> v=spf1 nor spf2.0 is missing. > > > > They also aren't relevant to answering the question of which of > > the two protocols is in use. > > No, they aren't. They just help evaluate the background noise. > > > I could add a note saying only valid replies were tabulated, just > > to be clear. > > Yes please. If you run a syntax check, or a record selection > according to Section 4.5 of RFC 4408, please say so. > > >> I'd suggest the following column names, or equivalent, where the > >> leading phrase "domains having one or more RRs such that" is > >> omitted: > >> > >> v=spf1 TXT any TXT any SPF (v=spf1 || spf2.0/*) both SPF && TXT > >> spf2.0/* (TXT || SPF) google-site-verification TXT (for > >> comparison) > > > > How do those additional details go toward answering the main > > question? > > The "any TXT" and "google-site-verification TXT" parts are only > relevant for the DNS usage appendix. > > >> In addition, it would help having a few words for characterizing > >> how the domain names in the two surveys were selected/collected. > > > > The -05 version does say that. > > You don't mean: > > Specifically, these surveys pulled a large number of domain names > from recent activity logs and queried their nameservers for both > RRTYPEs that can be used for SPF and/or Sender-ID. > > Do you? It doesn't tell the difference between the two. > > >> *Analysis* > >> > >> 2. Of the records retrieved, fewer than 3% requested processing > >> of messages using the PRA algorithm, which was an essential part > >> of Sender-ID. > >> > >> This is formally incorrect, as the PRA algorithm can be applied > >> to v=spf1 records by virtue of the compatibility equivalence of > >> Section 3.4 of RFC 4406. What we can derive is the percentage of > >> domains whose admins determined that PRA deserves a different > >> treatment than MFROM. That is the percentage of domains that > >> expect there to be a difference, and corroborates the analysis of > >> differences carried out in Section 4. > > > > A sender that wants its mail to be subjected specifically to PRA > > evaluation, and not to SPF, has to use an "spf2.0/*" record. > ^^^^^^^^^^^^^^^^^^^^^^^^^MFROM? > > Ditto reversing MFROM and PRA. Dear Alessandro, Agree/Disagree. Agree: Reasons for using spf2.0 were declared in the IESG note and clarified in Section 3.4 of RFC4406 which defaults "v=spf1" as being equivalent to "spf2.0/mfrom,pra" unless preempted by an existing "spf2.0/..." record. The IESG note created a devious problem for subsequent efforts in deciphering publisher intent. Only when "spf2.0/mfrom" records have been published (that many considered either a sacrilege or waste of resources) would intent be clear as intent to avoid application of Sender-ID. RFC4406 defaults can lead to misleading results when the "spf2.0" version is tallied as evidence of Sender-ID intent when it might imply the opposite, and absence of "spf2.0" records doesn't exclude Sender-ID intent. You clarified this again later. Heads you lose, tails I win. Disagree: SPF offers no scope and may apply against either MFROM or the HELO. Regards, Douglas Otis From vesely@tana.it Fri Apr 20 12:23: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 B931F21E8028 for ; Fri, 20 Apr 2012 12:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoRMy-kS6qdK for ; Fri, 20 Apr 2012 12:23:30 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 08A0E21E801C for ; Fri, 20 Apr 2012 12:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334949809; bh=PyjReia+hb+jLwjMZIsacpK+hCqXmjDrqR5PMTOKCRQ=; l=1324; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=b3gmZqoqWDVS+Bi6oUeSDZ/wEJaR4Yimvuxn+R7ywqQ2bAX9JBchlM+9EbX3favkg 0BZeAfnHiRFOQv4+3U0jVtKmgzy/XC15FkQhu5wyhR7CFhqvCrpyi8KTqZKC2aaImQ d46xPqw0NQZ4wmxF8yJpB3DT6miqc6ySObrmYuAs= 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, 20 Apr 2012 21:23:28 +0200 id 00000000005DC035.000000004F91B7B0.000065D7 Message-ID: <4F91B7B0.7040106@tana.it> Date: Fri, 20 Apr 2012 21:23:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@tana.it> <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 19:23:32 -0000 On Fri 20/Apr/2012 21:05:28 +0200 Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >>>> You don't mean: >>>> >>>> Specifically, these surveys pulled a large number of domain names >>>> from recent activity logs and queried their nameservers for both >>>> RRTYPEs that can be used for SPF and/or Sender-ID. >>>> >>>> Do you? It doesn't tell the difference between the two. >>> >>> Yes, that's what I meant. That text indicates how the domains were >>> selected and exactly how they were queried. What's missing? >> >> Any clue on how/why they differ from one another? Anything that may >> characterize one sample w.r.t. the other? > > What's "they"? I don't know what you're comparing. The two surveys. They are derived from activity at real sites, not after statistical sampling methods, hence they are skewed. I think that including some random notices about the sites may help guessing how representative they might be of the global server population. I don't know what data may be relevant, though. Anything that can depict in a few words what is the real traffic of the sites would probably do, including the amount of time it took to collect the sample, the nations or states, mailing lists, monkey butter and fruits... anything you'd feel like disclosing. No? From spf2@kitterman.com Fri Apr 20 13:34: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 975AA11E8086 for ; Fri, 20 Apr 2012 13:34:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcVBSiD2-ZnG for ; Fri, 20 Apr 2012 13:34:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CA6FE11E8085 for ; Fri, 20 Apr 2012 13:34:19 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 816C620E409F; Fri, 20 Apr 2012 16:34:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1334954058; bh=7hLB7arzxcGeirwKE9fTKhnSCd7x0stxN91YiQPS0L0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ZhJzPRpbde2mTtyi+YBG3lnmg0cXEH0H0aaGnDpHhRxeQps5mSVUtV3uSnBUWNYTB lFFolt7svTRmKtUCiBuGm8UNAY7VdIkD/nZs1r74AwycoRkC6q+n/B42wWOQIA31Pq Rmf4S1GRf/aVtOlLvCVQiJMF5opq0hj+RLPk810o= Received: from scott-latitude-e6320.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 ESMTPSA id 6364520E4083; Fri, 20 Apr 2012 16:34:18 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 20 Apr 2012 16:34:17 -0400 Message-ID: <1833368.deoOj51N1M@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F91A761.8050500@tana.it> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@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] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 20:34:20 -0000 On Friday, April 20, 2012 08:13:53 PM Alessandro Vesely wrote: > >> Ditto reversing MFROM and PRA. > > > > > > > > Why? If I want MFROM processing only, I can use "spf2.0/mfrom" or > > "v=spf1". > > No, the compatibility stuff says: > > Sender ID implementations SHOULD interpret the version prefix > "v=spf1" as equivalent to "spf2.0/mfrom,pra" There is actually no way to avoid PRA processing due to the broken way Sender ID is designed. If I do: v=spf1 [some stuff here] -all spf2.0/pra ?all That's actually a request for PRA processing. The so called opt-out isn't really an opt-out, it's an opt-in with a hard coded result. Since use of SPF (and Sender ID) results is a matter of local policy, there's no knowing what the effect of publishing such a record might be (It could turn results that would have been pass to neutral if there was no spf2.0/pra ?all record). If Microsoft had stuck with the MARID consensus and not reused SPF records for Sender ID, this would all be much cleaner now. I'd recommend we don't dig any deeper than the current text does. Going farther down doesn't make it any prettier. Scott K From dotis@mail-abuse.org Fri Apr 20 13:58: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 4AE9E21F85E4 for ; Fri, 20 Apr 2012 13:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EahMMuES48hX for ; Fri, 20 Apr 2012 13:58:39 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id D33D421F85E3 for ; Fri, 20 Apr 2012 13:58:39 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id AC19517400DC for ; Fri, 20 Apr 2012 20:58:39 +0000 (UTC) Message-ID: <4F91CDFF.3010107@mail-abuse.org> Date: Fri, 20 Apr 2012 13:58:39 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@tana.it> <1833368.deoOj51N1M@scott-latitude-e6320> In-Reply-To: <1833368.deoOj51N1M@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 20:58:40 -0000 On 4/20/12 1:34 PM, Scott Kitterman wrote: > On Friday, April 20, 2012 08:13:53 PM Alessandro Vesely wrote: >>>> Ditto reversing MFROM and PRA. >>>> >>>> Why? If I want MFROM processing only, I can use "spf2.0/mfrom" or >>>> "v=spf1". >> No, the compatibility stuff says: >> >> Sender ID implementations SHOULD interpret the version prefix >> "v=spf1" as equivalent to "spf2.0/mfrom,pra" Dear Scott, The RFC4406 "equivalence" has an additional requirement: "provided no record starting with "spf2.0" exists". Alessandro's suggestion to note cases where "spf2.0/mfrom" supplant pra is appropriate when assessing intent. This sidesteps RFC4406 advise in how to formulate Sender-ID avoidance (for the win). Regards, Douglas Otis > There is actually no way to avoid PRA processing due to the broken way Sender > ID is designed. If I do: > > v=spf1 [some stuff here] -all > spf2.0/pra ?all > > That's actually a request for PRA processing. The so called opt-out isn't > really an opt-out, it's an opt-in with a hard coded result. Since use of SPF > (and Sender ID) results is a matter of local policy, there's no knowing what > the effect of publishing such a record might be (It could turn results that > would have been pass to neutral if there was no spf2.0/pra ?all record). > > If Microsoft had stuck with the MARID consensus and not reused SPF records for > Sender ID, this would all be much cleaner now. > > I'd recommend we don't dig any deeper than the current text does. Going > farther down doesn't make it any prettier. Don't ignore obvious attempts depicted by "spf2.0/mfrom" sans pra. Regards, Douglas Otis From msk@cloudmark.com Fri Apr 20 14:28: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 1BFAB21F8570 for ; Fri, 20 Apr 2012 14:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkF59UdPe4K3 for ; Fri, 20 Apr 2012 14:28:43 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1FA21F856D for ; Fri, 20 Apr 2012 14:28:43 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 0MUq1j0010as01C01MUqiz; Fri, 20 Apr 2012 14:28:50 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=GHrnrXXKDOsA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=Rx9ZtpbRss9nba4cwswA:9 a=rNn933TqlSaD0MskaiwA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=MSl-tDqOz04A:10 a=3ixfTSoY1giU6wFh:21 a=UgMW49LQnDwLgxwq:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 14:28:31 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt Thread-Index: AQHNHrpEl78OTRuSrkOKtgToYqGV95ajN3aggAD/UgD//4x/kIAAqVuA//+K5pCAAIMLgP//iwsAABEM1QAACmpJ8A== Date: Fri, 20 Apr 2012 21:28:30 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FCCE6@exch-mbx901.corp.cloudmark.com> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@tana.it> <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> <4F91B7B0.7040106@tana.it> In-Reply-To: <4F91B7B0.7040106@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334957330; bh=xQZ8fMc6G2Dqd5uTzPZ7/czoZovGevYA6fbaYsNoxQQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=sV/Amm9Sa4s+OJkZQk5+akM+hjcHdDEZrYPbXDl5cuqs+Z3d/VcZo+FB+SPLIe8Qb QFqf9JgTQjYIckKmAHwbM6w19TNw88MC+ZvUXZor1qN3Qzyb6XsB+htUy5fuqijoRU j7iQzPN7wCwPPkIAXlL6N9XYXg12mqw1nq2AIQIc= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 21:28:44 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Friday, April 20, 2012 12:23 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt >=20 > The two surveys. They are derived from activity at real sites, not > after statistical sampling methods, hence they are skewed. I think > that including some random notices about the sites may help guessing > how representative they might be of the global server population. I > don't know what data may be relevant, though. Anything that can depict > in a few words what is the real traffic of the sites would probably do, > including the amount of time it took to collect the sample, the nations > or states, mailing lists, monkey butter and fruits... anything you'd > feel like disclosing. No? I would think it's enough to indicate (as we have) that the domain names we= re selected from recent mail logs, meaning they reflect domain names of act= ual mail traffic that was evaluated with SPF and/or Sender-ID. However, I = can add a time range to the second one. If the people who gave me data for= the first and third can respond, I'll do the same for theirs. If we believe, however, that 90% or more of current mail traffic is spam, I= would imagine it doesn't matter who collects the domain names; they will b= e largely random, with some of the more popular ones (gmail.com, for exampl= e) common to all of them. -MSK From pmidgen@messagebus.com Fri Apr 20 14:31: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 98C5721F853D for ; Fri, 20 Apr 2012 14:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qCz2m4pJy-F for ; Fri, 20 Apr 2012 14:31:03 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 50DF721F84EC for ; Fri, 20 Apr 2012 14:31:03 -0700 (PDT) Received: by dady13 with SMTP id y13so18097418dad.27 for ; Fri, 20 Apr 2012 14:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=messagebus.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=xe6OYwo3y1mRjiRh32t8a04J5bwo01L5pBZDPbi4kSY=; b=OnCRncznBdR+mkbQ3wva4Dv84dZjVeewx387UqpznmDjgueWoji/VEegt1w/6jGSH7 qqXnDXF9wwKNnsorsUHy9xrQWM5cHkB3WlfN36f2ifxClF10NWkWcf4bdQ8FXKzLtFQJ N5tvgByYRkSaQoe8OfuKuJgFLDZ4e/h1rd47g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=xe6OYwo3y1mRjiRh32t8a04J5bwo01L5pBZDPbi4kSY=; b=ans9R7jEMiORBZf0JGWxSRKoHbwSyUr1Vol0BCtzx1NSvBT0oC5A5Vf0Hv7QChqZOz OnNDBHwxuO3uOC9kWQu9I3NA4oWQwDxEydTT4GX1qy/8mzd/cpJGf4Ek33bDQ0Z4OSJR PdARuZjNLZo0JMv8s+8SkARqvzIl/c9jrLyitj4ZiJno0TSDxVfWLWf5ABqq/+U6dwUz y3KApNjzyzyuCCMLssN6SN3LhnemGhuoJF1AAHQ95q4In5HimPHhNuaOspHuU4MTEbug 9D7KHy4YQyuE7j7dyi7p5EJ2w38IYSyn30SjmYsp+ATnLhhO29uS2eilNf9iHelFr77j LbXQ== Received: by 10.68.229.73 with SMTP id so9mr9888055pbc.163.1334957462899; Fri, 20 Apr 2012 14:31:02 -0700 (PDT) Received: from PaulMidgen.local (102.sub-166-250-46.myvzw.com. [166.250.46.102]) by mx.google.com with ESMTPS id ox2sm6380265pbc.55.2012.04.20.14.31.01 (version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 14:31:02 -0700 (PDT) Message-ID: <4F91D594.9020203@messagebus.com> Date: Fri, 20 Apr 2012 14:31:00 -0700 From: Paul Midgen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@tana.it> <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------020802070804030706010603" X-Gm-Message-State: ALoCoQkBPSpxbpaS5C4lgKFLL1nV+toNUtDHJvvpEOrrLjWsBADBhf++82TJRDc+lMBAlG0ngM8i X-Mailman-Approved-At: Fri, 20 Apr 2012 14:35:40 -0700 Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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, 20 Apr 2012 21:32:57 -0000 This is a multi-part message in MIME format. --------------020802070804030706010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (note: my email address is no longer at microsoft.com, this is because i've left the company, however for the purpose of this discussion i'll base my comments on my experience at hotmail) Hi Murray, Thanks for shepherding this, by the end you'll have earned some kind of medal for valor. Having contributed the Hotmail-based data to this effort, given that it is in general agreement with the data collected by others, I think the document is drawing the right high-level conclusions. I would like to say for the record that Hotmail's decision to support SPF was driven by the following conclusions based on stable observations of hundreds of billions of inbound messages from millions of domains: 1. for nearly 80% of messages the final authentication state (after spf, sender-id, dkim, local policy, etc.) was identical when evaluating spf and sender-id for the same message using the same record. 2. domains publishing both spf2.0/pra and spf1 records almost always "said" exactly the same things with those records. 3. the cases where PRA offered some advantage over MFROM (e.g. forwarders, MLMs), where "advantage" means "more likely to generate a pass/fail authentication result" are easily handled in local policy by making the decision to look at 5322.From and Sender on the basis of information external to SPF, such as IP and domain reputation. It's worth noting that #3 does in fact say that, for Hotmail, the experience of using PRA was valuable and in the end our email authentication system will be stronger for it. That learning does not include a statement about the security and/or rightness of said practice, and therefore doesn't argue for or support modification of SPFbis to include PRA, SUBMITTER, etc. The point is that for a majority of cases SPF will perform its intended function, and when it doesn't we can compensate in our local policy system in a manner that preserves the integrity of SPF. I noted no mention of message volume anywhere in the document, if there continues to be debate about DNS and connection log data being sufficient to prove the necessary pointswe may consider overlaying the existing studies with volume information from a couple of receivers ranging from small to large to see if the evidence remains consistent. From section 6: > 2. The absence of significant adoption of the RRTYPE 99 DNS Resource > Record suggests that it has not attracted enough support to be > useful. I'd suggest that given the design of DNS, the point here is not about usefulness of RRTYPE 99, rather that it "has not attracted enough support to be mandated for SPFbis compliance" or a statement similar to that. > 3. The absence of significant adoption of the [SUBMITTER] extension, > [SENDER-ID], and [PRA], indicates that there is not a strong > community prepared to develop those mechanisms beyond > experimental status. There is clearly a community of *some* size prepared to develop these things, but I wonder what the point would be. Why advance two standards when one is clearly good enough to start with && can be deliberately evolved over time if it proven lacking. It isn't that Sender-ID lacks proponents or has zero value, it's that Sender-ID's deployment and use will never approach that of SPF, the two have essentially the same result (in observed practice, not strictly hypothetically/on paper), advancing SPFbis to standard status establishes a starting point to evolve from, if a proven need emerges. -p On 20-Apr/12 11:16 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Alessandro Vesely >> Sent: Friday, April 20, 2012 11:14 AM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt >> >>> Only if we want the appendix also to discuss arbitrary junk an SPF >>> verifier will have to handle. That seems to be to be the kind of >>> thing to emphasize in RFC4408bis itself as implementation advice >>> though, not for the experiment document. >> The two main issues RFC 5507 brings on why adding a new RRTYPE are the >> collision with other uses of TXT, and space considerations in DNS >> messages. The second can be considered a consequence of the first, and >> we can provide some numbers on how the first goes in our case. > We could include a "See RFC5507 for further related discussion" if you like. > >>>> You don't mean: >>>> >>>> Specifically, these surveys pulled a large number of domain names >>>> from recent activity logs and queried their nameservers for both >>>> RRTYPEs that can be used for SPF and/or Sender-ID. >>>> >>>> Do you? It doesn't tell the difference between the two. >>> Yes, that's what I meant. That text indicates how the domains were >>> selected and exactly how they were queried. What's missing? >> Any clue on how/why they differ from one another? Anything that may >> characterize one sample w.r.t. the other? > What's "they"? I don't know what you're comparing. > >>>> Ditto reversing MFROM and PRA. >>> Why? If I want MFROM processing only, I can use "spf2.0/mfrom" or >>> "v=spf1". >> No, the compatibility stuff says: >> >> Sender ID implementations SHOULD interpret the version prefix >> "v=spf1" as equivalent to "spf2.0/mfrom,pra" > "spf2.0/mfrom,pra" is not MFROM only, nor is it PRA only. > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis --------------020802070804030706010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit (note: my email address is no longer at microsoft.com, this is because i've left the company, however for the purpose of this discussion i'll base my comments on my experience at hotmail)

Hi Murray,

Thanks for shepherding this, by the end you'll have earned some kind of medal for valor. Having contributed the Hotmail-based data to this effort, given that it is in general agreement with the data collected by others, I think the document is drawing the right high-level conclusions.

I would like to say for the record that Hotmail's decision to support SPF was driven by the following conclusions based on stable observations of hundreds of billions of inbound messages from millions of domains:
1. for nearly 80% of messages the final authentication state (after spf, sender-id, dkim, local policy, etc.) was identical when evaluating spf and sender-id for the same message using the same record.

2. domains publishing both spf2.0/pra and spf1 records almost always "said" exactly the same things with those records.

3. the cases where PRA offered some advantage over MFROM (e.g. forwarders, MLMs), where "advantage" means "more likely to generate a pass/fail authentication result" are easily handled in local policy by making the decision to look at 5322.From and Sender on the basis of information external to SPF, such as IP and domain reputation.

It's worth noting that #3 does in fact say that, for Hotmail, the experience of using PRA was valuable and in the end our email authentication system will be stronger for it. That learning does not include a statement about the security and/or rightness of said practice, and therefore doesn't argue for or support modification of SPFbis to include PRA, SUBMITTER, etc. The point is that for a majority of cases SPF will perform its intended function, and when it doesn't we can compensate in our local policy system in a manner that preserves the integrity of SPF.

I noted no mention of message volume anywhere in the document, if there continues to be debate about DNS and connection log data being sufficient to prove the necessary points we may consider overlaying the existing studies with volume information from a couple of receivers ranging from small to large to see if the evidence remains consistent.

From section 6:
   2.  The absence of significant adoption of the RRTYPE 99 DNS Resource
       Record suggests that it has not attracted enough support to be
       useful.
I'd suggest that given the design of DNS, the point here is not about usefulness of RRTYPE 99, rather that it "has not attracted enough support to be mandated for SPFbis compliance" or a statement similar to that.

   3.  The absence of significant adoption of the [SUBMITTER] extension,
       [SENDER-ID], and [PRA], indicates that there is not a strong
       community prepared to develop those mechanisms beyond
       experimental status.
There is clearly a community of *some* size prepared to develop these things, but I wonder what the point would be. Why advance two standards when one is clearly good enough to start with && can be deliberately evolved over time if it proven lacking.

It isn't that Sender-ID lacks proponents or has zero value, it's that Sender-ID's deployment and use will never approach that of SPF, the two have essentially the same result (in observed practice, not strictly hypothetically/on paper), advancing SPFbis to standard status establishes a starting point to evolve from, if a proven need emerges.

-p
On 20-Apr/12 11:16 AM, Murray S. Kucherawy wrote: 
-----Original Message-----
From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Alessandro Vesely
Sent: Friday, April 20, 2012 11:14 AM
To: spfbis@ietf.org
Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt


Only if we want the appendix also to discuss arbitrary junk an SPF
verifier will have to handle.  That seems to be to be the kind of
thing to emphasize in RFC4408bis itself as implementation advice
though, not for the experiment document.

The two main issues RFC 5507 brings on why adding a new RRTYPE are the
collision with other uses of TXT, and space considerations in DNS
messages.  The second can be considered a consequence of the first, and
we can provide some numbers on how the first goes in our case.

We could include a "See RFC5507 for further related discussion" if you like.


You don't mean:

   Specifically, these surveys pulled a large number of domain names
   from recent activity logs and queried their nameservers for both
   RRTYPEs that can be used for SPF and/or Sender-ID.

Do you?  It doesn't tell the difference between the two.

Yes, that's what I meant.  That text indicates how the domains were
selected and exactly how they were queried.  What's missing?

Any clue on how/why they differ from one another?  Anything that may
characterize one sample w.r.t. the other?

What's "they"?  I don't know what you're comparing.


Ditto reversing MFROM and PRA.

Why?  If I want MFROM processing only, I can use "spf2.0/mfrom" or
"v=spf1".

No, the compatibility stuff says:

   Sender ID implementations SHOULD interpret the version prefix
   "v=spf1" as equivalent to "spf2.0/mfrom,pra"

"spf2.0/mfrom,pra" is not MFROM only, nor is it PRA only.

-MSK
_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis
--------------020802070804030706010603-- From hsantos@isdg.net Sat Apr 21 03:35: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 2EEE121F8551 for ; Sat, 21 Apr 2012 03:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dfa21aZcxqQ for ; Sat, 21 Apr 2012 03:35:52 -0700 (PDT) Received: from mail.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D23BD21F84EB for ; Sat, 21 Apr 2012 03:35:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8024; t=1335004542; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=elh5eCe68FYwxxcsPDBf60Dfk1Y=; b=txp2HJB/ZB1L7Dv1y9a7 8Vw6IH/nO43w5u4xFU3dzbAmkAsbFw4BWaekMax0Kf/SMxB6Yv5OwlvDK2jIJpyz 0lt2CBXQhkLfzKBm2WilySzi1G99xNvNUrbVdqUVcMZoopgcEXFeUbz8CPm7XbiH BTMe/3B3jcCe4fOIKjI2eYg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 21 Apr 2012 06:35: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 v6.4.454.1) with ESMTP id 3911362450.33274.5160; Sat, 21 Apr 2012 06:35:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8024; t=1335004205; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nGgMHpy +fj1eM+F1HV6XUolVbuUXpyvmKSnoVM7bEAI=; b=CionqLumA6oNC0MK7sdezHV shm84I2Hzzj2BBnIHzNFSbr8xjI++biAFgHc+cvq8cB+YC3E+jtFPQzvlInu6LOa Ipbp1a8XUmgS4aboxnKo7sqo0yPKFNpkcb4fUDiwu98all67Q7ze5cNXusDR6lCI dWVRHYwlKpYv8BtSjE+A= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 21 Apr 2012 06:30:05 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 215293050.2622.1692; Sat, 21 Apr 2012 06:30:04 -0400 Message-ID: <4F929B3E.1070708@isdg.net> Date: Sat, 21 Apr 2012 07:34:22 -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: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@tana.it> <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> <4F91D594.9020203@messagebus.com> In-Reply-To: <4F91D594.9020203@messagebus.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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: Sat, 21 Apr 2012 10:35:57 -0000 Hi Paul, I would like to express a POV below, I believe may provide some insights to help produce the issues we are dealing with today. see inline comments. Paul Midgen wrote: > > I would like to say for the record that Hotmail's decision to support > SPF was driven by the following conclusions based on stable observations > of hundreds of billions of inbound messages from millions of domains: > > 1. for nearly 80% of messages the final authentication state (after > spf, sender-id, dkim, local policy, etc.) was identical when > evaluating spf and sender-id for the same message using the same record. This is same observation experienced over 80% or more. It was expected the PRA would only be useful for certain use cases. I believe I was the first to highlight the high equality, indicating our stats ~84%, thus sparking the submitter proposal as an optimizer. But when I did the scanning of mail archives of already accepted mail, including spam, it was only possible to get the percentage when they did not match but not possible to get a payoff value given the 2005 dearth of published SPF records. You can only pick and choose by domains you knew had records. In other words, the percentage was clear, but not possible to see if it meant anything without having SPF1 and/or SPF2 records. > 2. domains publishing both spf2.0/pra and spf1 records almost always > "said" exactly the same things with those records. I suspect this only shows that a deployment supported SenderID however not have the network use cases that required a different IP::PRA.DOMAIN relationship. I also suggest without a more detail analysis of paths and whether their clients supported SUBMITTER, its hard to tell what the receiver will be doing here. If the receiver support SUBMITTER, then extracting the SPF2.0/PRA sufficed. If the receiver did not support submitter, then the SPF1.0 record was available. So its pretty much attempt to cover all bases. Its the same with DKIM, if you sign only with SHA256, you might find older DKIM receivers not supporting SHA256. But if you sign with SHA1, you guaranteed the widest coverage. Some sign with both to get the highest strength and the widest coverage. Just a interesting file I just found. I have an old June 2005 AOL.COM file capture of their SPF/SPF2 records, with the following: spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" The same records, compared to today: spf2.0/pra ptr:mx.aol.com ?all v=spf1 ptr:mx.aol.com ?all Reduced but the same. Now whether the logistic of this has some merit I can't tell, but I do know one the main concerns I had with all this new DNS related query stuff was the waste and redundancy in the lookup with neutral policy results. > It's worth noting that #3 does in fact say that, for Hotmail, the > experience of using PRA was valuable and in the end our email > authentication system will be stronger for it. That learning does not > include a statement about the security and/or rightness of said > practice, and therefore doesn't argue for or support modification of > SPFbis to include PRA, SUBMITTER, etc. The point is that for a majority > of cases SPF will perform its intended function, and when it doesn't we > can compensate in our local policy system in a manner that preserves the > integrity of SPF. See my comment below regarding a very important consideration that was on the table. > There is clearly a community of *some* size prepared to develop these > things, but I wonder what the point would be. Why advance two standards > when one is clearly good enough to start with && can be deliberately > evolved over time if it proven lacking. > > It isn't that Sender-ID lacks proponents or has zero value, it's that > Sender-ID's deployment and use will never approach that of SPF, the two > have essentially the same result (in observed practice, not strictly > hypothetically/on paper), advancing SPFbis to standard status > establishes a starting point to evolve from, if a proven need emerges. There were many who question PRA in the SPF camp, after all, plain and simple, you only needed the SMTP envelope domains to apply SPF. The concept of a payload based 3rd identity called PRA was the monkey wrench. To people who were interested in the integrated solutions that not only covered SMTP but the highly subjective content analysis methods with heuristic ideas and promising 3rd party trusted service reputation services, was all part of the strategic views people presented. And Paul, that included the high possibility that end users, our ultimate customers and one we wish to protect with lower exposed risk, did not have a backend host that was yet offering or up to par with all the new email technology with backend filtering or separating of good vs bad streams. So as the RFC4406 (SenderID) describes in its introduction: This document describes a mechanism such that receiving Mail Transfer Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents (MUAs) can recognize mail in the above category and take appropriate action. For example, an MTA might refuse to accept a message, an MDA might discard a message rather than placing it into a mailbox, and an MUA might render that message in some distinctive fashion. It addresses all components within a total mail system including the compliant backend MTA/MDA dealing with problematic messages we were concerned with or non-compliant backend and the possibility the MUA could fill that niche or gap by using the protocols or perhaps use the results of a MARK ONLY backend to help the users. The same issue carried over to DKIM as well where the backend was not yet ready or compliant with DKIM verification., In fact, in the MUA area, there were some some 3rd party add-ons, I recall an ActiveX component for Outlook that marketed SenderID support and I personally recall a ThunderBird XUL plug-in that also did DKIM verification. Related to the idea that a backend server may not yet be ready or is still exploring deployment, I wrote an I-D that offered a Partial Support idea to help with the migration and time-shifted delay problem of users getting unverified expired signed mail. http://tools.ietf.org/html/draft-santos-dkim-rcvd-00 Finally, just consider the POV of the total integrated aspect, we have five to six domains on DNS "lookup" table to evaluate either separated or in some optimized combined together: - 5321.EHLO (SPF) - 5321.MAILFROM (SPF - 5321.SUBMITTER (SIDF) - 5322.PRA (SIDF) - 5322.FROM (DKEYS/POLICY support or DKIM/ADSP/ATPS signature protection policies) - 5322.DKIM.D (DKIM Signer ID) This is why I sympathize with Mr. Levine long time belief that a trusted signature is all that is needed and it help trumps many of the known practical transport ills and hiccups known to exist. Its an great idea, but unfortunately its only for filtering good mail, can only work consistently and persistent across the board with everyone using the same 3rd party trust or reputation "Batteries" and does nothing to address the faults of a transaction with/or a faulty signature and the #1 problem of legacy abuse on domains and receivers continues. Does PRA play a role somewhere? At the backend or the MUA? I don't a feel for it, but we haven't really shown it does not. We only repeated what was already known, low volume on per site average, specific use cases and I personally do not believe this justifies getting rid of it. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Sat Apr 21 23:13: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 CF93521F857F for ; Sat, 21 Apr 2012 23:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kDQbNcSaExZ for ; Sat, 21 Apr 2012 23:13:44 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 942A421F857D for ; Sat, 21 Apr 2012 23:13:44 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 0uE31j0010ZaKgw01uE3YS; Sat, 21 Apr 2012 23:14:03 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=GHrnrXXKDOsA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=FaMIee6n00XMA-alxVsA:9 a=8G1CbqGbwAQ9hB2pwt8A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=jwngavOA7Qtz2Lz8:21 a=aQd0Ffxxa0EL-aab:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=PuGWO4biCa4wo_MrEQMA:9 a=Bfv0fvMP_Spz5vZH1woA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=4cdORWcxDBViBzbN:21 a=OktTu1lvPfOdsb2F:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sat, 21 Apr 2012 23:13:43 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt Thread-Index: AQHNHrpEl78OTRuSrkOKtgToYqGV95ajN3aggAD/UgD//4x/kIAAqVuA//+K5pCAAIMLgP//iwsAABWBEgAANYzhYA== Date: Sun, 22 Apr 2012 06:13:42 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FE3C6@exch-mbx901.corp.cloudmark.com> References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@tana.it> <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> <4F91D594.9020203@messagebus.com> In-Reply-To: <4F91D594.9020203@messagebus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280FE3C6exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335075243; bh=hleWJTPNtfR6upbbMYvQGTaWIhXmyhfEQlHG9sl/HKE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Rg2XtNFEwFOf7JxFFY5Oohudod+vZd7s+HslVE84i1PJ8jsWvC9oHbXT57/k+8NJZ qvYW/YatUeTlZt08AvzLwMVlC3RjVjo4WS4AZXizzLqTRB66fj1M5hJ4vAU5Z1dsbD gyGUUU0ENtNUvvZtK+VYF0gt1iJqp/NhD7Y1ZZMk= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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: Sun, 22 Apr 2012 06:13:49 -0000 --_000_9452079D1A51524AA5749AD23E0039280FE3C6exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, comments inline. From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Paul Midgen Sent: Friday, April 20, 2012 2:31 PM To: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt 1. for nearly 80% of messages the final authentication state (after spf, se= nder-id, dkim, local policy, etc.) was identical when evaluating spf and se= nder-id for the same message using the same record. [MSK: Thanks, I'll add that alongside the existing data in the document.] 2. domains publishing both spf2.0/pra and spf1 records almost always "said"= exactly the same things with those records. [MSK: Do people find this an interesting point to make? I'm not sure it so= lidifies our conclusions further.] 3. the cases where PRA offered some advantage over MFROM (e.g. forwarders, = MLMs), where "advantage" means "more likely to generate a pass/fail authent= ication result" are easily handled in local policy by making the decision t= o look at 5322.From and Sender on the basis of information external to SPF,= such as IP and domain reputation. It's worth noting that #3 does in fact say that, for Hotmail, the experienc= e of using PRA was valuable and in the end our email authentication system = will be stronger for it. That learning does not include a statement about t= he security and/or rightness of said practice, and therefore doesn't argue = for or support modification of SPFbis to include PRA, SUBMITTER, etc. The p= oint is that for a majority of cases SPF will perform its intended function= , and when it doesn't we can compensate in our local policy system in a man= ner that preserves the integrity of SPF. [MSK: The work of the experiment document, at least, doesn't advocate for r= equiring anyone to turn off Sender-ID (or in Hotmail's case, one particular= piece of the PRA algorithm). It's merely an effort to determine and compa= re the uptake of both protocols and select one to promote to and along the = Standards Track. So while this is interesting, and possibly input for an "= SPF experience" document or section in terms of later work, I don't think w= e should go into it here.] I noted no mention of message volume anywhere in the document, if there con= tinues to be debate about DNS and connection log data being sufficient to p= rove the necessary points we may consider overlaying the existing studies w= ith volume information from a couple of receivers ranging from small to lar= ge to see if the evidence remains consistent. [MSK: Certainly more data are welcome, although I expect as you've found th= at those data will further corroborate what we have. We can go do that if = asked.] >From section 6: 2. The absence of significant adoption of the RRTYPE 99 DNS Resource Record suggests that it has not attracted enough support to be useful. I'd suggest that given the design of DNS, the point here is not about usefu= lness of RRTYPE 99, rather that it "has not attracted enough support to be = mandated for SPFbis compliance" or a statement similar to that. [MSK: I think "useful" as it's used here means use in terms of a standards = track version of RFC4408. Including the type 99 stuff there will only cont= inue to confuse matters. In the long view I think a dedicated RR type woul= d've been a good thing to have from the start, but various factors made tha= t not happen; see Appendix A (which may itself evolve as the Working Group = Last Call progress).] 3. The absence of significant adoption of the [SUBMITTER] extension, [SENDER-ID], and [PRA], indicates that there is not a strong community prepared to develop those mechanisms beyond experimental status. There is clearly a community of *some* size prepared to develop these thing= s, but I wonder what the point would be. Why advance two standards when one= is clearly good enough to start with && can be deliberately evolved over t= ime if it proven lacking. [MSK: If there is any kind of community that still wants to do the work to = advance Sender-ID in any way, it has yet to appear. I think there exists a= handful of people that do, but they aren't writing documents or having the= conversations that make these things happen. The work isn't there. But i= t is for SPF.] It isn't that Sender-ID lacks proponents or has zero value, it's that Sende= r-ID's deployment and use will never approach that of SPF, the two have ess= entially the same result (in observed practice, not strictly hypothetically= /on paper), advancing SPFbis to standard status establishes a starting poin= t to evolve from, if a proven need emerges. [MSK: Precisely.] -p On 20-Apr/12 11:16 AM, Murray S. Kucherawy wrote: -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbi= s-bounces@ietf.org] On Behalf Of Alessandro Vesely Sent: Friday, April 20, 2012 11:14 AM To: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt Only if we want the appendix also to discuss arbitrary junk an SPF verifier will have to handle. That seems to be to be the kind of thing to emphasize in RFC4408bis itself as implementation advice though, not for the experiment document. The two main issues RFC 5507 brings on why adding a new RRTYPE are the collision with other uses of TXT, and space considerations in DNS messages. The second can be considered a consequence of the first, and we can provide some numbers on how the first goes in our case. We could include a "See RFC5507 for further related discussion" if you like= . You don't mean: Specifically, these surveys pulled a large number of domain names from recent activity logs and queried their nameservers for both RRTYPEs that can be used for SPF and/or Sender-ID. Do you? It doesn't tell the difference between the two. Yes, that's what I meant. That text indicates how the domains were selected and exactly how they were queried. What's missing? Any clue on how/why they differ from one another? Anything that may characterize one sample w.r.t. the other? What's "they"? I don't know what you're comparing. Ditto reversing MFROM and PRA. Why? If I want MFROM processing only, I can use "spf2.0/mfrom" or "v=3Dspf1". No, the compatibility stuff says: Sender ID implementations SHOULD interpret the version prefix "v=3Dspf1" as equivalent to "spf2.0/mfrom,pra" "spf2.0/mfrom,pra" is not MFROM only, nor is it PRA only. -MSK _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis --_000_9452079D1A51524AA5749AD23E0039280FE3C6exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul, comments inline.=

 <= /p>

From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ie= tf.org] On Behalf Of Paul Midgen
Sent: Friday, April 20, 2012 2:31 PM
To: spfbis@ietf.org
Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.tx= t

 

1. for nearly 80% o= f messages the final authentication state (after spf, sender-id, dkim, loca= l policy, etc.) was identical when evaluating spf and sender-id for the sam= e message using the same record.

=  

[MSK:= Thanks, I’ll add that alongside the existing data in the document.]<= /span>

2. domains publishing both spf2.0/pra and = spf1 records almost always "said" exactly the same things with th= ose records.

 <= /p>

[MSK: Do people find this= an interesting point to make?  I’m not sure it solidifies our c= onclusions further.]


3. the cases where PRA offered some advant= age over MFROM (e.g. forwarders, MLMs), where "advantage" means &= quot;more likely to generate a pass/fail authentication result" are ea= sily handled in local policy by making the decision to look at 5322.From and Sender on the basis of information external to SPF, = such as IP and domain reputation.


It's worth noting that #3 does in fact say that, for Hotmail, the experienc= e of using PRA was valuable and in the end our email authentication system = will be stronger for it. That learning does not include a statement about t= he security and/or rightness of said practice, and therefore doesn't argue for or support modification of = SPFbis to include PRA, SUBMITTER, etc. The point is that for a majority of = cases SPF will perform its intended function, and when it doesn't we can co= mpensate in our local policy system in a manner that preserves the integrity of SPF.

 <= /p>

[MSK: The work of the exp= eriment document, at least, doesn’t advocate for requiring anyone to = turn off Sender-ID (or in Hotmail’s case, one particular piece of the PRA algorithm).  It’s merely an effort to determine and = compare the uptake of both protocols and select one to promote to and along= the Standards Track.  So while this is interesting, and possibly inpu= t for an “SPF experience” document or section in terms of later work, I don’t think we should go into it here.]<= /o:p>



I noted no mention of message volume anywhere in the document, if there con= tinues to be debate about DNS and connection log data being sufficient to p= rove the necessary points we may consider overlaying the existing studies w= ith volume information from a couple of receivers ranging from small to large to see if the evidence remains co= nsistent.<= /span>

 <= /p>

[MSK: Certainly more data= are welcome, although I expect as you’ve found that those data will = further corroborate what we have.  We can go do that if asked.]


>From section 6:

   2.  The absence of significant adoption of the RRTYP=
E 99 DNS Resource
       Record suggests that it has not a=
ttracted enough support to be
       useful.

I'd suggest that gi= ven the design of DNS, the point here is not about usefulness of RRTYPE 99,= rather that it "has not attracted enough support to be mandated for S= PFbis compliance" or a statement similar to that.

[MSK: I think “= useful” as it’s used here means use in terms of a standards tra= ck version of RFC4408.  Including the type 99 stuff there will only co= ntinue to confuse matters.  In the long view I think a dedicated RR type would’ve been a good thing to have from the start, but vario= us factors made that not happen; see Appendix A (which may itself evolve as= the Working Group Last Call progress).]

 <= /p> 

   3.  The absence of significant adoption of the [SUBM=
ITTER] extension,
       [SENDER-ID], and [PRA], indicates=
 that there is not a strong
       community prepared to develop tho=
se mechanisms beyond
       experimental status.

There is clearly a =
community of *some* size prepared to develop these things, but I wonder wha=
t the point would be. Why advance two standards when one is clearly good en=
ough to start with && can be deliberately
 evolved over time if it proven lacking.


 <=
/p>

[MSK: If there is any kin=
d of community that still wants to do the work to advance Sender-ID in any =
way, it has yet to appear.  I think there exists a handful
 of people that do, but they aren’t writing documents or having the c=
onversations that make these things happen.  The work isn’t ther=
e.  But it is for SPF.]




It isn't that Sender-ID lacks proponents or has zero value, it's that Sende=
r-ID's deployment and use will never approach that of SPF, the two have ess=
entially the same result (in observed practice, not strictly hypothetically=
/on paper), advancing SPFbis to
 standard status establishes a starting point to evolve from, if a proven n=
eed emerges.





[MSK: Precisely.]




-p








On 20-Apr/12 11:16 AM, Murray S. Kucherawy wrote: 




-----Original Message-----


From: spfbis-bounces@ietf.o=
rg [mailto:spfbis-bounces@ie=
tf.org] On Behalf Of Alessandro Vesely


Sent: Friday, April 20, 2012 11:14 AM


To: spfbis@ietf.org<=
/pre>

Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.txt<=
o:p>


 




Only if we want the appendix also to discuss arbitrary junk an SPF


verifier will have to handle.  That seems to be to be the kind of=



thing to emphasize in RFC4408bis itself as implementation advice<=
/o:p>


though, not for the experiment document.




 


The two main issues RFC 5507 brings on why adding a new RRTYPE are the=



collision with other uses of TXT, and space considerations in DNS=



messages.  The second can be considered a consequence of the firs=
t, and


we can provide some numbers on how the first goes in our case.




 


We could include a "See RFC5507 for further related discussion&qu=
ot; if you like.


 








You don't mean:


 


   Specifically, these surveys pulled a large number of doma=
in names


   from recent activity logs and queried their nameservers f=
or both


   RRTYPEs that can be used for SPF and/or Sender-ID.


 


Do you?  It doesn't tell the difference between the two.




 


Yes, that's what I meant.  That text indicates how the domains we=
re


selected and exactly how they were queried.  What's missing?=





 


Any clue on how/why they differ from one another?  Anything that =
may


characterize one sample w.r.t. the other?




 


What's "they"?  I don't know what you're comparing.


 








Ditto reversing MFROM and PRA.




 


Why?  If I want MFROM processing only, I can use "spf2.0/mfr=
om" or


"v=3Dspf1".




 


No, the compatibility stuff says:


 


   Sender ID implementations SHOULD interpret the version pr=
efix


   "v=3Dspf1" as equivalent to "spf2.0/mfrom,=
pra"




 


"spf2.0/mfrom,pra" is not MFROM only, nor is it PRA only.


 


-MSK


_______________________________________________


spfbis mailing list


spfbis@ietf.org

https://www.i=
etf.org/mailman/listinfo/spfbis
--_000_9452079D1A51524AA5749AD23E0039280FE3C6exchmbx901corpclo_-- From pmidge@messagebus.com Sun Apr 22 02: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 52BED21F8625 for ; Sun, 22 Apr 2012 02:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+IeNpLJxf1V for ; Sun, 22 Apr 2012 02:15:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9D7521F8637 for ; Sun, 22 Apr 2012 02:15:08 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2716989pbb.31 for ; Sun, 22 Apr 2012 02:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=messagebus.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=PBZKg+t0IKxvGR37qXKnxMfrrQU79ld97Dmb+vbO9gc=; b=EaY5J2Oo9cx2EyYxwK1/5DObbNdglSN3jae7CCZrsbXnQIaDyQCrgZCoVqiJvyqeen 27UHY+KYmGfS+HnOr1UB1PW+z9+7V0ZYwbmprqkHpiurGBinNUtfJ5Yi7bKpfQJ57+0c 0wGuMm0HomNOVcGIYaVsguzKTzhqRWzWWY5J0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=PBZKg+t0IKxvGR37qXKnxMfrrQU79ld97Dmb+vbO9gc=; b=aTSjTY/7eT+ltXry5Jo56sTqTJFxRgCHonwXISpCNmq9QlDfQS9mJie3gjh3bist8h TbI2jzo7JDgWWg5K+AIi7ek508PBXOeHgYA9sgp2wrNi1SzglXzq1Qu6ShRpoAObe7Xq 2OBz/irAENPM5xQCQJ8qojSH915H9tNWklUBPpyi9EbDfSs6CIo+JNSVSB+cWDI/OnRP dTq07mTMw9W/Ww081iGd0fZw7pXxptXKhOlh7hiVppt2b5pBSehZ0dBK/MtPw1a4S4TZ jJu0CeBHKR/7fVFfV4tKO5OwldDxZs/rv3YPHgFcAn4YPhvv8NiYAXAMCY/QuGkoaw6I k2WA== Received: by 10.68.189.231 with SMTP id gl7mr27080637pbc.151.1335086108291; Sun, 22 Apr 2012 02:15:08 -0700 (PDT) Received: from PaulMidgen.local (c-98-234-236-249.hsd1.ca.comcast.net. [98.234.236.249]) by mx.google.com with ESMTPS id o9sm10884937pbe.60.2012.04.22.02.15.07 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 02:15:07 -0700 (PDT) Message-ID: <4F93CC1A.3050608@messagebus.com> Date: Sun, 22 Apr 2012 02:15:06 -0700 From: Paul Midgen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120420055540.14787.42817.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E0039280FBAFE@exch-mbx901.corp.cloudmark.com> <4F916E82.7020205@tana.it> <9452079D1A51524AA5749AD23E0039280FC4B6@exch-mbx901.corp.cloudmark.com> <4F919BAF.1040303@tana.it> <9452079D1A51524AA5749AD23E0039280FC8C3@exch-mbx901.corp.cloudmark.com> <4F91A761.8050500@tana.it> <9452079D1A51524AA5749AD23E0039280FC9DA@exch-mbx901.corp.cloudmark.com> <4F91D594.9020203@messagebus.com> <9452079D1A51524AA5749AD23E0039280FE3C6@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FE3C6@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------030802080300090500020000" X-Gm-Message-State: ALoCoQmWJG1PnUsqF1mthRWEWLkIoBy0EiZSxRnF5uAXf/onRVt/HsQljfQCIzYealh0oCwgdIwp Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-05.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: Sun, 22 Apr 2012 09:15:11 -0000 This is a multi-part message in MIME format. --------------030802080300090500020000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just a couple of comments-on-comments: On 21-Apr/12 11:13 PM, Murray S. Kucherawy wrote: > > Hi Paul, comments inline. > > > 2. domains publishing both spf2.0/pra and spf1 records almost always > "said" exactly the same things with those records. > > [MSK: Do people find this an interesting point to make? I'm not sure > it solidifies our conclusions further.] > > I don't actually suggest adding text regarding this, I just pointed it out as background. > > 3. the cases where PRA offered some advantage over MFROM (e.g. > forwarders, MLMs), where "advantage" means "more likely to generate a > pass/fail authentication result" are easily handled in local policy by > making the decision to look at 5322.From and Sender on the basis of > information external to SPF, such as IP and domain reputation. > > > It's worth noting that #3 does in fact say that, for Hotmail, the > experience of using PRA was valuable and in the end our email > authentication system will be stronger for it. That learning does not > include a statement about the security and/or rightness of said > practice, and therefore doesn't argue for or support modification of > SPFbis to include PRA, SUBMITTER, etc. The point is that for a > majority of cases SPF will perform its intended function, and when it > doesn't we can compensate in our local policy system in a manner that > preserves the integrity of SPF. > > [MSK: The work of the experiment document, at least, doesn't advocate > for requiring anyone to turn off Sender-ID (or in Hotmail's case, one > particular piece of the PRA algorithm). It's merely an effort to > determine and compare the uptake of both protocols and select one to > promote to and along the Standards Track. So while this is > interesting, and possibly input for an "SPF experience" document or > section in terms of later work, I don't think we should go into it here.] > > Agreed. --------------030802080300090500020000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just a couple of comments-on-comments:

On 21-Apr/12 11:13 PM, Murray S. Kucherawy wrote:

Hi Paul, comments inline.


2. domains publishing both spf2.0/pra and spf1 records almost always "said" exactly the same things with those records.

 

[MSK: Do people find this an interesting point to make?  I’m not sure it solidifies our conclusions further.]


I don't actually suggest adding text regarding this, I just pointed it out as background.

3. the cases where PRA offered some advantage over MFROM (e.g. forwarders, MLMs), where "advantage" means "more likely to generate a pass/fail authentication result" are easily handled in local policy by making the decision to look at 5322.From and Sender on the basis of information external to SPF, such as IP and domain reputation.


It's worth noting that #3 does in fact say that, for Hotmail, the experience of using PRA was valuable and in the end our email authentication system will be stronger for it. That learning does not include a statement about the security and/or rightness of said practice, and therefore doesn't argue for or support modification of SPFbis to include PRA, SUBMITTER, etc. The point is that for a majority of cases SPF will perform its intended function, and when it doesn't we can compensate in our local policy system in a manner that preserves the integrity of SPF.

 

[MSK: The work of the experiment document, at least, doesn’t advocate for requiring anyone to turn off Sender-ID (or in Hotmail’s case, one particular piece of the PRA algorithm).  It’s merely an effort to determine and compare the uptake of both protocols and select one to promote to and along the Standards Track.  So while this is interesting, and possibly input for an “SPF experience” document or section in terms of later work, I don’t think we should go into it here.]


Agreed.

--------------030802080300090500020000-- From barryleiba.mailing.lists@gmail.com Sun Apr 22 06:58: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 7006321F858E for ; Sun, 22 Apr 2012 06:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD10Or0fHWuZ for ; Sun, 22 Apr 2012 06:58:11 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 673C021F84F0 for ; Sun, 22 Apr 2012 06:58:11 -0700 (PDT) Received: by yhkk25 with SMTP id k25so6649517yhk.31 for ; Sun, 22 Apr 2012 06:58:10 -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:content-type; bh=iCkz9Y/8FPjuUEnA7KLNStipYWy3QFCdwwPR17A5sdo=; b=FJGuA/Aqc5YSf02250g9e2H+HF3H0c2lDvia/QriwnM9A4KuuFXH9N4DBisaUbRRFr gkNevMjIdogGSI/ZAhG0I9V3/D09pLCVMk4qppPbDBxaogtyr+AiEE/x8eha9vs0I3yZ k/4uk/ifHv8gGTpjKZ5Tvg8YRLomkEQgLdlBrZNS1pqwUpAUn7V/4sPsaL8Z6emuQKJe GMJwhAepXzLG3oBBnZaa/bmmyIrZmt5r6zRU/+DqsY87V7jdhwH5RiOCaMCSqHJMlzQz woxZrddfF3UALBrJF3Pxvqv2IKBDk3RnSH/44pUKcuiovC4LQjq0xHkK/EPyaxVxbyD+ Trqg== MIME-Version: 1.0 Received: by 10.236.154.35 with SMTP id g23mr11851710yhk.107.1335103089961; Sun, 22 Apr 2012 06:58:09 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.152.14 with HTTP; Sun, 22 Apr 2012 06:58:09 -0700 (PDT) In-Reply-To: <4F8CABE8.10007@isdg.net> References: <20120416230031.12409.qmail@joyce.lan> <4F8CABE8.10007@isdg.net> Date: Sun, 22 Apr 2012 09:58:09 -0400 X-Google-Sender-Auth: 9xAiQCmdAabW2ihjLAgJCJvJb5A Message-ID: From: Barry Leiba To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=20cf303b427d6a6b6c04be44e95c Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 13:58:12 -0000 --20cf303b427d6a6b6c04be44e95c Content-Type: text/plain; charset=ISO-8859-1 > If the SPFBIS is going recommend to end the SIDF protocol Let's be clear about one thing here: while "ending the SIDF protocol" might be something some participants in this WG want to do, it is not a goal of the WG, and as far as I can tell, no one is trying to put that in any of the WG's documents. The working group is chartered to describe its consensus of the result of a number of years of experimentation with SPF and SIDF, and to move SPF to Proposed Standard. If that consensus says that SPF is in wide use and SIDF is not, and there's data to support that, it's fine. As an AD, I will say that if any document comes out of this working group making any normative statement (or even a strong recommendation) telling people NOT to use SIDF, saying that SIDF is deprecated or obsolete, obsoleting any SIDF RFC, or moving any SIDF RF to Historic, I will surely put a DISCUSS position on that document for exceeding the WG's charter. I'm guessing that Pete, who's the responsible AD here, will cut it off before it ever gets to me anyway, should a document do that. So, please, everyone stop accusing the WG of trying to "kill" SIDF. It will not. If someone should want to create an SIDFbis WG to do something one way or the other with that protocol, that'd be a fine thing to pursue as a separate effort. But later, after this one is done. Barry --20cf303b427d6a6b6c04be44e95c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > If the SPFBIS is going recommen= d to end the =A0SIDF protocol

Let's= be clear about one thing here: while "ending the SIDF protocol" = might be something some participants in this WG want to do, it is not a goa= l of the WG, and as far as I can tell, no one is trying to put that in any = of the WG's documents. =A0The working group is chartered to describe it= s consensus of the result of a number of years of experimentation with SPF = and SIDF, and to move SPF to Proposed Standard. =A0If that consensus says t= hat SPF is in wide use and SIDF is not, and there's data to support tha= t, it's fine.

As an AD, I will say that if any document com= es out of this working group making any normative statement (or even a stro= ng recommendation) telling people NOT to use SIDF, saying that SIDF is depr= ecated or obsolete, obsoleting any SIDF RFC, or moving any SIDF RF to Histo= ric, I will surely put a DISCUSS position on that document for exceeding th= e WG's charter. =A0I'm guessing that Pete, who's the responsibl= e AD here, will cut it off before it ever gets to me anyway, should a docum= ent do that.

So, please, everyone stop accusing the WG of = trying to "kill" SIDF. =A0It will not. =A0If someone should want = to create an SIDFbis WG to do something one way or the other with that prot= ocol, that'd be a fine thing to pursue as a separate effort. =A0But lat= er, after this one is done.

Barry
--20cf303b427d6a6b6c04be44e95c-- From hsantos@isdg.net Sun Apr 22 08:12: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 1671821F85EA for ; Sun, 22 Apr 2012 08:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFRRX+bbzkJb for ; Sun, 22 Apr 2012 08:12:47 -0700 (PDT) Received: from pop3.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 898F921F85E6 for ; Sun, 22 Apr 2012 08:12:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=10401; t=1335107560; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Rpc9KPbE5HHwvRvf+B9nACAZUys=; b=Eu6g1oWxXoyDxwLHFqSW xHiRCQC2aMZvBRrCqzFgb0SBnGF1DLaW2cN4+ynjJ5RKXARPDvlS2y8I5PTJDngv Y7jQue1C9Z5tOrH4EMPtRBL0QUgiXOhTVllslNu/fkvUhBbp8GHUHzpYdsFez1O/ poks6Uk90aA6MBiXW4qN/Mc= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 22 Apr 2012 11:12:40 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4014378475.34182.3820; Sun, 22 Apr 2012 11:12:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=10401; t=1335107224; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=TIwcmD5 vXt1ETAWAPR7IVTc4TUk/XLLluNSH05zy9lc=; b=RYEs30zZg8VjI6LOZS77O85 Tzl+ftxM7+SSAtMd2rCKaVLnW9jd8O3KnikFX7luImLAPKWm9ErCSbF0nxGUY0CA 3Pfw7edW+ezepvlTHfKG5fw2nDlY3jQ4F2pHwQxEURI4k9a6N0BnNIuClSYj6daH vDpw3bZwUUG+RgNYTC4o= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 22 Apr 2012 11:07:04 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 318311925.2844.4556; Sun, 22 Apr 2012 11:07:03 -0400 Message-ID: <4F942DCD.1060106@isdg.net> Date: Sun, 22 Apr 2012 12:11:57 -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] Interop Report needs two data points related to WG issues X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 15:12:49 -0000 Hi, I don't know if this is possible to gather, but there two issues on the WG table that perhaps having some usage data would help in the writing of 4408BIS spec. I have an real example below showing both issues, but first my action proposals: ================================= (1) For the Interop-report, if practically possible: The relates to Received-SPF and the issue #12 proposal to replace it with the proposed standard Authentication-Result header. IMO, this item will be highly debated item, and probably if the consideration is deemed worthy to pursue, the debate will mostly be about in how it is worded with the ideal preference to accelerate deployment with a replacement worded as opposed to the more relaxed deprecation wording. I am wondering if having some usage data is relevant for the interop report to help implementators decide with any deprecation or replacement 44084BIS outcome. Proposal: Collect and report any data on the usage of Received-SPF header. Collect and report any data on the current usage of the 5322.Authentication-Result header to report SPF or Sender-ID results. Collect and report data on how deployed SMTP receivers have applied SPF policy violations for domains using hard fail (-ALL) SPF policies. I think it is correct to suggest that ultimately a local site SPF deployment can operate in two ways for -ALL policy violations: - REJECT-ON-FAIL - MARK-ON-FAIL It would good to know how SPF deployment for one of the other method. There are good reasons for both and also bad reasons both. But only one has a higher coverage to protect users, and in my view, whatever mode is used, the end result as far as the user is concern should be same or nearly the same. If one mode means (REJECT) is selected because the mail is considered bad, then opting to mark it instead should, in my engineering design view, offer the same negative rejection quality allowed the user to leverage and decide. In other words, marking a message should not offer any new possible value about the message if an alternative mode of acting on the message is direct rejection. Example below illustrates this. 2) New issue to track This is related to a recent discussion on what 4408 says or doesn't say regarding REJECT-ON-FAIL and the different viewpoints that was in the past and appear to be rearing its head again, a source of conflict. It is specifically written "Mark It or Reject" for a SPF domain policy resulting a FAIL (-all). I think the reject option is well defined but not "Mark it." Proposal: Define what "MARK-ON-FAIL" means. Does this just mean to use the SPFBIS recommended reporting header, currently Received-SPF? or have additional meaning like stream classification, i.e. quarantine to a Junk/Spam Email" user storage/folder? How does a specific type of MUA relate to this, i.e. Online vs Offline MUA access where with Online, the backend has better controls and with offline it is limited to the Offline MUA capabilities? ================================= Real Example showing that touch base with the above issues. This example usages hotmail.com and I sincerely want to express that none of this should misconstrued as negative on any individual, hotmail.com or questions their methodologies. My purpose is to hopefully show areas that relate to important SPFBIS considerations. This all started with a 2005 R&D effort to see two things and also confirm a third using the large ESP at the time, it included hotmail.com, aol.com, yahoo.com, earthlink.com and msn.com, etc. - Are the still working as long traditional ESPs not enforcing RFCx822 at DATA? - Which means are supporting SPF? - Are they always accepting and perhaps discarding illegal mail? I have a 2005 recorded hotmail.com session that showed an illegal MAIL FROM showed it did not reject it based on SPF/SIDF. The DATA payload that only had single line "Hello No Headers" (no headers) was still working as a traditional host and not enforcing RFCx2822. The message was accepted, unfortunately for this June 2005 test, I don't recall if I tried to confirm it appeared in my hotmail.com inbox or it was discarded. Related, I strongly recollect the Hotmail.com announcement that they were going to begin to enforce RFC2822 and wondered how this can change the industry because this as not something typically enforced for large suite of application reasons where the RFC822/2822 headers were simply not required to accept the message. So I tried it again today, in 2012, asking the same 2005 questions. The following is a capture telnet port 25 session: ---- Captured hotmail.com SMTP session --------- 220 SNT0-MC3-F37.Snt0.hotmail.com Sending unsolicited commercial or bulk e-mail to Microsoft's computer network is prohibited. Other restrictions are found at http://privacy.microsoft.com/en-us/anti-spam.mspx. Sun, 22 Apr 2012 01:45:46 -0700 HELO hdev2 250 SNT0-MC3-F37.Snt0.hotmail.com (3.15.0.97) Hello [208.247.131.22] MAIL FROM: 250 expecting.spf.rejection@altavista.com....Sender OK RCPT TO: 250 hls70@hotmail.com DATA 354 Start mail input; end with . expecting rejection . 250 Queued mail for delivery QUIT 221 SNT0-MC3-F37.Snt0.hotmail.com Service closing transmission channel ------------------------------------------ Please note the intentional usage of the altavista.com domain with SPF policy of -ALL, and no headers were used for data as was done in 2005. I also checked my Windows Live MUA and it showed the message was delivered, however, the backend put it into the "Junk E-Mail" folder. The delivered email has the following MUA message source view: ---- Message source view of delivered email --------- Authentication-Results: hotmail.com; sender-id=temperror (sender IP is 208.247.131.22) header.from=expecting.spf.rejection@altavista.com; dkim=none header.d=altavista.com; x-hmca=none X-SID-PRA: expecting.spf.rejection@altavista.com X-DKIM-Result: None X-Message-Status: n:0:n X-SID-Result: TempError X-AUTH-Result: NONE X-Message-Delivery: Vj0xLjE7dXM9MDtsPTA7YT0wO0Q9MjtHRD0yO1NDTD02 X-Message-Info: 11chDOWqoTmjqhOzvWWho/vK8oL2x1FIoE........=== Received: from hdev2 ([208.247.131.22]) by SNT0-MC3-F37.Snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4900); Sun, 22 Apr 2012 01:46:04 -0700 From: expecting.spf.rejection@altavista.com Bcc: Return-Path: expecting.spf.rejection@altavista.com Message-ID: X-OriginalArrivalTime: 22 Apr 2012 08:46:10.0973 (UTC) FILETIME=[5E03ACD0:01CD2064] Date: 22 Apr 2012 01:46:10 -0700 expecting rejection ------------------------------------------ There are many points that be stated, logistic questions, but I want to just highlight the key issues and questions are; - RFC5322 was not enforced. Not expected IMV. - It auto creates new headers and usages RFC5322 which does not require the adding of the To: header, like others will do with strict RFC822 local site policies or just to fill it an as separate option usually offered, i.e. EnableMissingTo. - Does HOTMAIL.COM perform any kind of SMTP level rejection or is it an always accept farm of inbound servers? - If it supports SPFv1.0 at SMTP, this would be example of RFC4408 option to do MARK-ON-FAIL and did not honor the domains strong policy of a NO MAIL SPD domain policy email practice declaration. In other words, the policy has to IPs or directives to compare, its a simple -ALL which means NO MAIL is expected for this domain. - But it didn't use a Received-SPF in reporting an SPF result, which should of showed if it was supported: Received-SPF: fail (......) - So does it deploy SPF at SMTP? - It uses Authentication-Result to report sender-id: temperror. Why is this a temporary error? OPTIONAL READING: If we are going to consider the recommendation to replacing Received-SPF with Auth-Res, it need to offer the same functionality in terms what the SPF policy says, -ALL means a FAIL was expected. It should not be translated into different meanings. I don't see this as big issue, but if anything it would related to the my next view regarding the type of MUA expected to be used. As a vendor with a mail system support for multiple device portals for mail access, from dumb terminals, console, ANSI/VT10x UI, to offloaded native GUI online MUA, Web UI, to pure offline store and forward MUA and also mixed online/offline, it was always a difficult challenge to support all this and also single source the basic backend framework as far what is secured and what is displayed. Newer systems has the luxury to stick with the new/current method, like web mail only. Others will offer web, pop3 or imap, and there is a trend to go back to the ONLINE MUA only as the only way. Cases in point, Microsoft abandoning NNTP access for LiveID authenticated MSDN web forums only and high-value user-vendor transaction are now increasing pushed to online online - the smart phone, small device evolution I believe is enabling it. The point is that something the backend assumed only one dominate mode of access and when this is the case, it can do things that offer safer mode or lower risk to users. For example, even though the above SMTP session with faulty transaction was accepted, it did quarantine it into my Junk Email box. But what if there was a 3rd party MUA, will it work in the same way? In the case with Hotmail.com, I was using Windows Live and it used a SOAP/HTTP protocol to access the backend mail and it had the logic to show the separate sort/split mail folders. The good news is hotmail.com offers pop3 port 995 access and with my Thunderbird MUA, the junk email was not included as part of my normal new mail So in this case, without confirmation, the backend MARK-ON-FAIL also meant a backend classification to separate the the bad from the good normal email. Is this material for SPFBIS 4408BIS to consider in defining what MARK-ON-FAIL means? -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Sun Apr 22 12:13: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 0234821F8658 for ; Sun, 22 Apr 2012 12:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sPQ+lSfYtx4 for ; Sun, 22 Apr 2012 12:13:13 -0700 (PDT) Received: from ntbbs.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 46F4B21F8652 for ; Sun, 22 Apr 2012 12:13:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4174; t=1335121990; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=2g8bLrtSsaGqWxbd7iS0goEfowA=; b=YPYJxhp9oXAjVC6CBZ+m 2m83WmurqSK65J0HZyirLPjUJzhYKD5QI+Eg5EsPQi0dJB0ZS5yvFD90PQa1iXt2 iBze79BMEOHZZRG5Mn9+o7gIhkwtdcISZ/bp3ByG7PdV3TvDEDUpstAMHk0cuGw8 Pv72IZZE2fcaHAa+AjSJH5c= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 22 Apr 2012 15:13:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4028808645.34182.4460; Sun, 22 Apr 2012 15:13:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4174; t=1335121654; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=GUEjY3A 8bXHuYqYt120LLasC79EVJCvUC3k6UoCwo7g=; b=qblWGu+/LCcQAgBARVwXZq5 Tbiqrc12mP3RFmtdscPLFViKnuMQ5V6TlBfWp9+NvY2ceiTClGS0yDH0cOV12Nc+ CHN+aY1MDXJKLcUo/LwJQs4jWIsn0pIQ6x/DWPNdxkia5BqZ7SmgS+bFiX2D+2gH FkAjk0Zt8Mct2Snw7j5w= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 22 Apr 2012 15:07:34 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 332742503.2859.5136; Sun, 22 Apr 2012 15:07:33 -0400 Message-ID: <4F94662A.6070909@isdg.net> Date: Sun, 22 Apr 2012 16:12:26 -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: <20120416230031.12409.qmail@joyce.lan> <4F8CABE8.10007@isdg.net> In-Reply-To: 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] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 19:13:15 -0000 (offlist) Hi Barry, What bothers me that statements were written with a principle focus to replace SIDF with DKIM and there obvious issues that I believed where simply wrong from many angles I don't wish to repeat, but it took me to highlight issues because no else was. Why did it even have get to this level is vexing to me. a) Murray, an militant SPF opponent, had one purpose to use the experiment status of SPF/SIDF as a way to take strategic consolidation control of it, related to all his work, like with DMARC. Never mind the questionable justification the IETF may allow one to take control of a RFC they were not the prime author, but do so without seeking permission or views from they original editors. So right here it got off the wrong foot. b) The charter does state no more work is recommended and I don't know where that come from because there were clear interest in SPF/SIDF conflict corrections. The known concerns and any suggestion to seek corrections was not open and there interests in the practical reality spf/sidf integration existed. I understand in SPFBIS only focus, but not at the expense of ending SIDF with no real engineering review to justify it. c) The charter does reference a draft 4408bis, where it states: The success or failure of the Sender ID portion of this IESG experiment should be evaluated relative to DKIM. d) Murray did have in a prior report draft a section 2.0 or 3.0 that pretty much repeated (c) and the need to consider DKIM over SIDF and I asked that this section be removed. It was. Reassure it was no due to my input but most likely John Leslie to remove the section. I only guessing it was Leslie because of a side bet with him the "replace SIDF with DKIM" will continue to be pushed by Murray despite all repeated "Out of Scope" comments the report had no business to inject. e) and whenever I wasted more time to provide more reasonable arguments and empirical information that I guess he could not ignore, he repeated in in three messages that new input, including new results from new scanning of data related to SIDF/SUBMIT he stated he was doing, that it wouldn't matter anyway because it won't change his initial recommendation to recommend SIDF be made obsolete. So why even bother doing a new scan on "millions of domains". See ya Barry. Barry Leiba wrote: >> If the SPFBIS is going recommend to end the SIDF protocol > > Let's be clear about one thing here: while "ending the SIDF protocol" might > be something some participants in this WG want to do, it is not a goal of > the WG, and as far as I can tell, no one is trying to put that in any of > the WG's documents. The working group is chartered to describe its > consensus of the result of a number of years of experimentation with SPF > and SIDF, and to move SPF to Proposed Standard. If that consensus says > that SPF is in wide use and SIDF is not, and there's data to support that, > it's fine. > > As an AD, I will say that if any document comes out of this working group > making any normative statement (or even a strong recommendation) telling > people NOT to use SIDF, saying that SIDF is deprecated or obsolete, > obsoleting any SIDF RFC, or moving any SIDF RF to Historic, I will surely > put a DISCUSS position on that document for exceeding the WG's charter. > I'm guessing that Pete, who's the responsible AD here, will cut it off > before it ever gets to me anyway, should a document do that. > > So, please, everyone stop accusing the WG of trying to "kill" SIDF. It > will not. If someone should want to create an SIDFbis WG to do something > one way or the other with that protocol, that'd be a fine thing to pursue > as a separate effort. But later, after this one is done. > > Barry > > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From sm@elandsys.com Sun Apr 22 13:38: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 BED5C21F854C for ; Sun, 22 Apr 2012 13:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhhtU4lMAz4O for ; Sun, 22 Apr 2012 13:38:14 -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 B977421F8533 for ; Sun, 22 Apr 2012 13:38:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.236]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3MKbuV0009044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2012 13:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335127089; i=@elandsys.com; bh=AkF6MphET1OQsFnMpYoe4ZY2kuvJDTDqLVcDWvxKWXA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rs4uv+eYv7HPBII4Rf+OUh1ARFDSFlNFTyX03nl3omgmsTXW4m56LD0DS+H9Q2avg KAfsQ5ttIhaem2fXD5QIVFrLZ4lHA38dJzsqyU7ZKFdK/pmYZHzYby4uORilBVBdHe JUdlLKJyyBiS3WHoN7smhOongtfYMGv7ZJYNnzMc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335127089; i=@elandsys.com; bh=AkF6MphET1OQsFnMpYoe4ZY2kuvJDTDqLVcDWvxKWXA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BrE6n0SAl2yuA1Uqc3Q4/fdWAjfnjfAhMNpm1NCpgAqvXXSl4Dxw0xGApNvVG1SrD fvhSOdTT/FNsY96pg+Ow1Ass73oWZ3R+hCOGtVc46V52iff05m6ZDn2FNG2uy2782z vNj8uMLmFOMFIad6fqHV+CDbNCqdlvFioAuz1yG0= Message-Id: <6.2.5.6.2.20120422122411.0a521520@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 22 Apr 2012 13:15:34 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F94662A.6070909@isdg.net> References: <20120416230031.12409.qmail@joyce.lan> <4F8CABE8.10007@isdg.net> <4F94662A.6070909@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 20:38:16 -0000 At 13:12 22-04-2012, Hector Santos wrote: >(offlist) The SPFBIS mailing list archive might disagree about that. :-) A document editor documents working group consensus. The person is free to have his/her own opinion and express his/her opinion during working group discussions. What matters is that the document that comes out of this working group represents the consensus of this working group. >c) The charter does reference a draft 4408bis, where it states: > > The success or failure of the Sender ID portion of this IESG experiment > should be evaluated relative to DKIM. I read the SPFBIS charter again before writing this message. I do not see any mention of DKIM in the charter. >d) Murray did have in a prior report draft a section 2.0 or 3.0 that pretty > much repeated (c) and the need to consider DKIM over SIDF and I asked that > this section be removed. It was. Reassure it was no due to my input but It's not because the input is not part of a long thread that it was not taken into consideration. Murray Kucherawy, as document editor for draft-ietf-spfbis-experiment-05 must have taken that into account when documenting the consensus. > e) and whenever I wasted more time to provide more reasonable arguments and There will be a working group Last Call for draft-ietf-spfbis-experiment. It should last around two weeks. There will also be an IETF Last Call which should last two weeks. That's a month altogether. I made a note about the message posted at http://www.ietf.org/mail-archive/web/spfbis/current/msg01287.html This working group has made significant progress on its first deliverable due to the efforts of each and everyone. Let's not forget that. Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Sun Apr 22 13: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 6E76121F84E7 for ; Sun, 22 Apr 2012 13:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH2qdTluA22u for ; Sun, 22 Apr 2012 13:46:12 -0700 (PDT) Received: from pop3.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6762721F84DF for ; Sun, 22 Apr 2012 13:46:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1138; t=1335127565; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=x8cFkZVJJ+1dUP2o+Qrf2oAZtKs=; b=JdEyQfksZS1lKbPGUkwr kUpWzCzAV2PFdo7gOyUK9nfzTfR/kfZEylOKDAJopGL1E+8LthxfjiREzG63lijF H23WHPHYKow5UCz8zwqhTaJWOz0TfFlMoAz42sXquMQJTDIuFWYZZuNgspX8SjPQ zFAKt6HKspUwzRkssZSUGWw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 22 Apr 2012 16:46:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4034383778.34182.4876; Sun, 22 Apr 2012 16:46:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1138; t=1335127227; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DGosUdh XtjVYrB9KPBy1KleGhMJwIr9+cAlLIhCQV8g=; b=YYiAuX4KcSClB9LkXaGTP3U YbxwSQ7zM/Zypb7e38uf3zd6174AMOJ38VaEVB6eXiEsdHm5GvnV9MUt0dAej6em uV57J57XzrB3wSWqukq7mZl9OB+XILUQN468btpNaxw4Ey3WNMx16u4+LeWIjExi +puU+WaduCquP8hnFJOM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 22 Apr 2012 16:40:27 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 338315441.2872.7104; Sun, 22 Apr 2012 16:40:26 -0400 Message-ID: <4F947BEF.8010208@isdg.net> Date: Sun, 22 Apr 2012 17:45:19 -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: <20120416230031.12409.qmail@joyce.lan> <4F8CABE8.10007@isdg.net> <4F94662A.6070909@isdg.net> In-Reply-To: <4F94662A.6070909@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 20:46:13 -0000 Folks, Obviously, the intent was a private communication with Barry. I wish to apologize to all, especially Murray. While we do have conflicts, I honestly admire his dedication and work effort within the IETF. I hope we can resolve our differences. For the record, I was open to dealing with the SIDF issue and possibly replace it with some SPF/DKIM/ADSP/ATPS combined manner since after all, we have implemented SPF, PRA/SUBMITTER, DKIM, ADSP, ATPS and VBR and streamlining all this is a high interest. So I was not against the consideration if it could be done without negative repercussions. I simply didn't believe the "usage" angle was the correct approach to justify the idea, it is a more complex issue. Sincerely, -- Hector Santos Hector Santos wrote: > (offlist) > > Hi Barry, > > What bothers me that statements were written with a principle focus to > replace SIDF with DKIM and there obvious issues that I believed where > simply wrong from many angles I don't wish to repeat, but it took me to > highlight issues because no else was. Why did it even have get to this > level is vexing to me. From barryleiba.mailing.lists@gmail.com Sun Apr 22 13:58: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 2D9B821F85AA for ; Sun, 22 Apr 2012 13:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FeOdpqLucXe for ; Sun, 22 Apr 2012 13:58:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAC21F85A1 for ; Sun, 22 Apr 2012 13:58:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6740659ghb.31 for ; Sun, 22 Apr 2012 13:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=4QFUS+70PCjGcRRQRhsY+cTgVI9rLykQFXNnSzP3JtI=; b=vLtmvplF0uKUj739Ql0sMyHswFqRku+OuoV38jmkAx3yeNwUIqIDiR1dyOuJFnjuo1 lXh4vquUa9JcK6iMbm946YMZuYjVc47ipe7HSDz1u7F5WOAbYStVKogpW6gYCIgMNkii IhAAB/M0fstL0xN0QL/eiKvk5RE6/g0BK9Q7ad0ysqaIoFfgThCzslcOVKp9fX6syo66 tzsFyjV3ixqc7o3GBFGZyFHp0gYjIq8m7NE5STQAOLzTYQ+zusHofybeCcFJZo1zOCq6 51TTIp2Gzy7jn8HOaY41jNWJk+egfQJN+nQKrHsxKLkxNff7N7uNtt75QBhMZZ3NeyQd h3ug== MIME-Version: 1.0 Received: by 10.101.175.37 with SMTP id c37mr3889122anp.59.1335128303385; Sun, 22 Apr 2012 13:58:23 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.152.14 with HTTP; Sun, 22 Apr 2012 13:58:23 -0700 (PDT) Date: Sun, 22 Apr 2012 16:58:23 -0400 X-Google-Sender-Auth: O8x6kHVZb1oa8G-DDRZG5CVU32Y Message-ID: From: Barry Leiba To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=001636c5bb7740bad204be4ac8eb Subject: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 20:58:25 -0000 --001636c5bb7740bad204be4ac8eb Content-Type: text/plain; charset=ISO-8859-1 Here's a review of experiment-05. Some of these comments are purely editorial, but some address the tone of the document, the tendency to deprecate Sender ID, and general issues of pronouncements and opinions. Please seriously consider addressing those: I don't think such pronouncements, opinions, and bias are in place in this document (see my first comment below). -- Abstract -- OLD After six years, sufficient experience and evidence have been collected that the experiment thus created can be considered concluded, and a single protocol can be advanced. This document presents those findings. I would prefer that this document avoid making pronouncements and stating these kinds of opinions ("a single protocol can be advanced"). The point of this draft is to document results. The actual SPFbis doc will do the advancement of SPF. It would be better if statements about the fate of Sender ID be left for other granfalloons. I suggest ending the sentence with "concluded". Note that RFC 4406 uses "Sender ID", with a space and no dash (except in the IESG Note). Please use that orthography consistently here. -- Introduction -- OLD The two protocols made use of this policy statement and some specific (but different) logic NEW (clarity, even though "same" is in the next paragraph) The two protocols made use of this same policy statement and some specific (but different) logic OLD Due to the absence of consensus behind one or the other, and because Sender-ID supported use of the same policy statement defined by SPF, the IESG at the time was concerned that an implementation of Sender-ID might erroneously apply that statement to a message and, depending on selected recipient actions, could improperly interfere with message delivery. This seems to have a significant SPF bias. May I suggest this?: NEW Due to the absence of consensus behind one or the other and because SPF and Sender-ID supported use of the same policy statement with different semantics, the IESG at the time was concerned that implementations of SPF or Sender-ID might erroneously apply a statement that had been published with the semantics of the other, and, depending on selected recipient actions, could improperly interfere with message delivery. OLD It is important to note that this document makes no direct technical comparison of the two protocols in terms of correctness, weaknesses, or use case coverage. The email community at large has already done that. I suggest "has already done that through its deployment choices." Otherwise, one might wonder where the comparison that's been done is documented. -- Analysis -- OLD 2. Of the records retrieved, fewer than 3% requested processing of messages using the PRA algorithm, which was an essential part of Sender-ID. I suggest "which is an essential part of Sender ID." There seems no reason for past tense. OLD 3. Although the two mechanisms often used different email addresses as the subject being evaluated, no data collected showed any substantial operational benefit (e.g., cheaper processing, improved accuracy) to using Sender-ID over SPF. I suggest "to using either mechanism over the other." -- Conclusions -- OLD It is standard procedure within the IETF to document as standard those protocols and practices that have come into sufficient common use as to become part of the basic infrastructure. This seems unnecessary and out of place. I suggest removing it. OLD In light of the this and the analysis in the previous section, the following conclusions are supported: NEW In light of the analysis in the previous section, the following conclusions are supported: OLD 1. The experiment comprising the series of RFCs defining the SUBMITTER SMTP extension, the Sender-ID mechanism, the Purported Responsible address algorithm, and SPF, should be considered concluded. Citations for all have appeared earlier, but I think it would be helpful to put RFC citations for them here... consider it an excutive summary. This is one of the problems with the choice of non-RFC-based citation tags. I suggest this, which uses parentheses instead of citations: NEW 1. The experiment comprising the series of RFCs defining the SUBMITTER SMTP extension (RFC 4405), the Sender-ID mechanism (RFC 4406), the Purported Responsible address algorithm (RFC 4407), and SPF (RFC 4408), should be considered concluded. OLD 3. The absence of significant adoption of the [SUBMITTER] extension, [SENDER-ID], and [PRA], indicates that there is not a strong community prepared to develop those mechanisms beyond experimental status. I would MUCH rather see this reported factually, without further opinion. Something like this: NEW 3. The absence of significant adoption of the [SUBMITTER] extension, [SENDER-ID], and [PRA], indicates that there is not a strong community deploying and using these protocols. OLD 4. Continued widespread use of [SPF] indicates it is worthy of consideration for the Standards Track. I suggest this: NEW 4. [SPF] has widespread implementation and deployment, comparable to that of many Standards Track protocols. -- Security Considerations -- OLD This document contains information for the community, akin to an implementation report, and does not introduce any new security concerns. Its implications could, in fact, resolve some. That last sentence seems odd. Unless you want to be specific about it, I suggest removing it. -- Informative References -- We can always argue whether an Informational document, by its nature, can have "normative" references. Still, in the sense that we use it here, references that are central to the understanding of the document at hand are usually considered to be normative. DNS is arguable, but I'd say no. I think the references to PRA, SENDER-ID, SPF, and SUBMITTER are normative. -- Appendix A. Experiences Developing SPF -- This is really about the RR type issue, not about SPF in general. I suggest saying that in the section title. Maybe, "Background on the RR Type Issue", or some such. -- Barry --001636c5bb7740bad204be4ac8eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here's a review of experime= nt-05. =A0Some of these comments are purely editorial, but some address the= tone of the document, the tendency to deprecate Sender ID, and general iss= ues of pronouncements and opinions. =A0Please seriously consider addressing= those: I don't think such pronouncements, opinions, and bias are in pl= ace in this document (see my first comment below).

-- Abstract --

OLD
= =A0 =A0After six years, sufficient experience and evidence have been
<= div>=A0 =A0collected that the experiment thus created can be considered
=A0 =A0concluded, and a single protocol can be advanced. =A0This document
=A0 =A0presents those findings.

I would p= refer that this document avoid making pronouncements and stating these kind= s of opinions ("a single protocol can be advanced"). =A0The point= of this draft is to document results. =A0The actual SPFbis doc will do the= advancement of SPF. =A0It would be better if statements about the fate of = Sender ID be left for other granfalloons. =A0I suggest ending the sentence = with "concluded".

Note that RFC 4406 uses "Sender ID", with a s= pace and no dash (except in the IESG Note). =A0Please use that orthography = consistently here.

-- Introduction --=A0

OLD
=A0 =A0The two protocols made use of this poli= cy
=A0 =A0statement and some specific (but different) logic
=

NEW (clarity, even though "same" is in the ne= xt paragraph)
=A0 =A0The two protocols made use of this same policy
=A0 = =A0statement and some specific (but different) logic

OLD
=A0 =A0Due to the absence of consensus behind one or the o= ther, and because
=A0 =A0Sender-ID supported use of the same policy statement defined by= SPF,
=A0 =A0the IESG at the time was concerned that an implement= ation of
=A0 =A0Sender-ID might erroneously apply that statement = to a message and,
=A0 =A0depending on selected recipient actions, could improperly inter= fere
=A0 =A0with message delivery.

This = seems to have a significant SPF bias. =A0May I suggest this?:
NEW
=A0 =A0Due to the absence of consensus behind one or the= other and because
=A0 =A0SPF and Sender-ID supported use of the = same policy statement with
=A0 =A0different semantics, the IESG a= t the time was concerned that
=A0 =A0implementations of SPF or Sender-ID might erroneously apply a
=A0 =A0statement that had been published with the semantics of the= other,
=A0 =A0and, depending on selected recipient actions, coul= d improperly
=A0 =A0interfere with message delivery.

OLD
=A0 =A0It is important to note that this document makes no direct = technical
=A0 =A0comparison of the two protocols in terms of corr= ectness, weaknesses,
=A0 =A0or use case coverage. =A0The email community at large has alrea= dy done
=A0 =A0that.

I suggest "has= already done that through its deployment choices." =A0Otherwise, one = might wonder where the comparison that's been done is documented.

-- Analysis --

OLD
= =A0 =A02. =A0Of the records retrieved, fewer than 3% requested processing o= f
=A0 =A0 =A0 =A0messages using the PRA algorithm, which was an e= ssential part of
=A0 =A0 =A0 =A0Sender-ID.

I suggest "whi= ch is an essential part of Sender ID." =A0There seems no reason for pa= st tense.

OLD
=A0 =A03. =A0Although the = two mechanisms often used different email addresses
=A0 =A0 =A0 =A0as the subject being evaluated, no data collected showe= d any
=A0 =A0 =A0 =A0substantial operational benefit (e.g., cheap= er processing,
=A0 =A0 =A0 =A0improved accuracy) to using Sender-= ID over SPF.

I suggest "to using either mechanism over the other.&qu= ot;

-- Conclusions --

OLD=
=A0 =A0It is standard procedure within the IETF to document as s= tandard
=A0 =A0those protocols and practices that have come into sufficient co= mmon
=A0 =A0use as to become part of the basic infrastructure.

This seems unnecessary and out of place. =A0I sugges= t removing it.

OLD
=A0 =A0In light of the this and the analy= sis in the previous section, the
=A0 =A0following conclusions are= supported:
NEW
=A0 =A0In light of the analysis in the = previous section, the
=A0 =A0following conclusions are supported:

O= LD
=A0 =A01. =A0The experiment comprising the series of RFCs defi= ning the
=A0 =A0 =A0 =A0SUBMITTER SMTP extension, the Sender-ID m= echanism, the Purported
=A0 =A0 =A0 =A0Responsible address algorithm, and SPF, should be consi= dered
=A0 =A0 =A0 =A0concluded.

Citation= s for all have appeared earlier, but I think it would be helpful to put RFC= citations for them here... consider it an excutive summary. =A0This is one= of the problems with the choice of non-RFC-based citation tags. =A0I sugge= st this, which uses parentheses instead of citations:

NEW
=A0 =A01. =A0The experiment comprising th= e series of RFCs defining the
=A0 =A0 =A0 =A0SUBMITTER SMTP exten= sion (RFC 4405), the Sender-ID mechanism
=A0 =A0 =A0 (RFC 4406), = the Purported Responsible address algorithm (RFC 4407),
=A0 =A0 =A0 =A0and SPF (RFC 4408), should be considered concluded.

OLD
=A0 =A03. =A0The absence of significant= adoption of the [SUBMITTER] extension,
=A0 =A0 =A0 =A0[SENDER-ID= ], and [PRA], indicates that there is not a strong
=A0 =A0 =A0 =A0community prepared to develop those mechanisms beyond
=A0 =A0 =A0 =A0experimental status.

I wou= ld MUCH rather see this reported factually, without further opinion. =A0Som= ething like this:

NEW
=A0 =A03. =A0The absence of significant a= doption of the [SUBMITTER] extension,
=A0 =A0 =A0 =A0[SENDER-ID],= and [PRA], indicates that there is not a strong
=A0 =A0 =A0 =A0c= ommunity deploying and using these protocols.

OLD
=A0 =A04. =A0Continued widespread use of = [SPF] indicates it is worthy of
=A0 =A0 =A0 =A0consideration for = the Standards Track.

I suggest this:
NEW=
=A0 =A04. =A0[SPF] has widespread implementation and deployment, comparable=
=A0 =A0 =A0 =A0to that of many Standards Track protocols.
<= div>
-- Security Consi= derations --

OLD
=A0 =A0This document contains information= for the community, akin to an
=A0 =A0implementation report, and = does not introduce any new security
=A0 =A0concerns. =A0Its impli= cations could, in fact, resolve some.

That last sentence seems odd. =A0Unless you want to be = specific about it, I suggest removing it.

-- Infor= mative References --

We can always argue whether a= n Informational document, by its nature, can have "normative" ref= erences. =A0Still, in the sense that we use it here, references that are ce= ntral to the understanding of the document at hand are usually considered t= o be normative. =A0DNS is arguable, but I'd say no. =A0I think the refe= rences to PRA, SENDER-ID, SPF, and SUBMITTER are normative.

-- Appendix A. =A0Experiences Developing SPF --

This is really about the RR type issue, not about SPF in general. = =A0I suggest saying that in the section title. =A0Maybe, "Background o= n the RR Type Issue", or some such.

--
Barry
--001636c5bb7740bad204be4ac8eb-- From spf2@kitterman.com Sun Apr 22 14:12: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 AF15C21F8581 for ; Sun, 22 Apr 2012 14:12:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWbLB88SUss8 for ; Sun, 22 Apr 2012 14:12:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 27B9221F857D for ; Sun, 22 Apr 2012 14:12:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 48CA120E40E0; Sun, 22 Apr 2012 17:12:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335129162; bh=8mo8Pf3OAZnOcpK3aB+x/q4kWrPh3SG6B43qMN2SkoA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=dTzgTKPubzNV2zraM1TVdlsomw4QzD2nQ9hBXfnG4fIMCCn1ZBEOew5TsRpo3zwEr QbvFECsT8lhk4PGT4Ta/72zz92lWeSNNbyHdvTorB+6DXh79+6o5R3NDIMHHmPbESl L9M1FAfQVuD9JZTz+rgwrJdCQkfgi/K38vbgOvIM= Received: from scott-latitude-e6320.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 ESMTPSA id 2A44920E4091; Sun, 22 Apr 2012 17:12:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 22 Apr 2012 17:12:41 -0400 Message-ID: <27817694.IMgqELHbEC@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 21:12:43 -0000 On Sunday, April 22, 2012 04:58:23 PM Barry Leiba wrote: > OLD > Due to the absence of consensus behind one or the other, and because > Sender-ID supported use of the same policy statement defined by SPF, > the IESG at the time was concerned that an implementation of > Sender-ID might erroneously apply that statement to a message and, > depending on selected recipient actions, could improperly interfere > with message delivery. > > This seems to have a significant SPF bias. May I suggest this?: > > NEW > Due to the absence of consensus behind one or the other and because > SPF and Sender-ID supported use of the same policy statement with > different semantics, the IESG at the time was concerned that > implementations of SPF or Sender-ID might erroneously apply a > statement that had been published with the semantics of the other, > and, depending on selected recipient actions, could improperly > interfere with message delivery. The current text is correct. The issue was Sender ID reusing SPF policy statements (of which there were a large number published before this change was introduced into Sender ID) not a generic "they both use the same data". I think the other changes you proposed are all good and make the document better for its intended purpose. Scott K From msk@cloudmark.com Sun Apr 22 14:28: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 24C4E21F8568 for ; Sun, 22 Apr 2012 14:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk+paG2CO2Nu for ; Sun, 22 Apr 2012 14:28:12 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 99BBC21F855F for ; Sun, 22 Apr 2012 14:28:12 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 19U01j0030ZaKgw019U0dy; Sun, 22 Apr 2012 14:28:00 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=0-aEOF3Vybt34qgo:21 a=avZxOnd31odspS2s:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 14:28:00 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anzRGA//+OihA= Date: Sun, 22 Apr 2012 21:27:59 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FEA8F@exch-mbx901.corp.cloudmark.com> References: <27817694.IMgqELHbEC@scott-latitude-e6320> In-Reply-To: <27817694.IMgqELHbEC@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335130080; bh=DZi20zYYnvp2hN1vJkU00SQElBeHu4pdqoaFPhyDIVM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=aZfCSW9sR9to2cQ6nCYC08SQ3nbcM518dWxq9faWg0btuxNvlLgpFpxzxa0OzfGZw av9MOGPG0bQwohbVfMxtfV+Q0a5E7+cHR7xhFkW6XdURcgaFhNgHq9KoW1r2+1EgJi l769XDtwCOLqDavvCqRnhMaqZeTiIHsII6EJbfZk= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 21:28:13 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Sunday, April 22, 2012 2:13 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > The current text is correct. The issue was Sender ID reusing SPF > policy statements (of which there were a large number published before > this change was introduced into Sender ID) not a generic "they both use > the same data". Is it necessary to be that precise in this document's context? > I think the other changes you proposed are all good and make the > document better for its intended purpose. +1. -MSK From spf2@kitterman.com Sun Apr 22 14:38: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 05EF621F85A1 for ; Sun, 22 Apr 2012 14:38:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBM83cvkX4Yx for ; Sun, 22 Apr 2012 14:38:18 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7110821F851B for ; Sun, 22 Apr 2012 14:38:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 027CF20E40E0; Sun, 22 Apr 2012 17:38:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335130695; bh=/2ox2TaM919uaJbXKLqG+YyRr+JDJ0SlADFgEs9S8T0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=H1BksH2wQVux+LgKsDaNAVDQqRvXZDRAzBwAaGtnV3HUMrcCMhRbfg+wOTLfpy0k4 aVxe39tozKt7qR1EfqMYiRFavGMrtj9pNA1SkNZNYlcNrHPE41Rt2P4IL94dXfYei0 /VZOb+sxWompZL6CDK16ypjl3zM/wtSgOZNcwrxM= Received: from scott-latitude-e6320.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 ESMTPSA id D811520E4091; Sun, 22 Apr 2012 17:38:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 22 Apr 2012 17:38:14 -0400 Message-ID: <3850142.Cln9WJldGb@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FEA8F@exch-mbx901.corp.cloudmark.com> References: <27817694.IMgqELHbEC@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FEA8F@exch-mbx901.corp.cloudmark.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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 21:38:19 -0000 On Sunday, April 22, 2012 09:27:59 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Sunday, April 22, 2012 2:13 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 > > > > The current text is correct. The issue was Sender ID reusing SPF > > policy statements (of which there were a large number published before > > this change was introduced into Sender ID) not a generic "they both use > > the same data". > > Is it necessary to be that precise in this document's context? It was an important enough issue at the time that IESG [1] and IAB [2] appeals on the practice were filed. I think pretending that this was an even handed data reuse issue is flat out wrong. In short, on this issue, yes. Scott K [1] http://www.ietf.org/iesg/appeal/mehnle-2005-08-25.txt [2] http://www.iab.org/appeals/2006-2/appeal-against-iesg-decision-by-julian- mehnle-8-february-2006/ P.S. This is unrelated to the question of hard feelings about MARID, which we are supposed to avoid. This is related to post-MARID design decisions made by Microsoft. From sm@elandsys.com Sun Apr 22 16:23: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 036F521F8609 for ; Sun, 22 Apr 2012 16:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7tftSovjg5B for ; Sun, 22 Apr 2012 16:23: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 6F12F21F84E1 for ; Sun, 22 Apr 2012 16:23:38 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.236]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3MNNJPv028477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2012 16:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335137014; i=@elandsys.com; bh=+WwuQbXxhc335R4oxqdc4sF7g+jnLTZ6lttDABvZPVQ=; h=Date:To:From:Subject:Cc; b=wIFK8n9QYmz9WsMUrI1xo+FkK4birCzgYPeGI50ILDKbvUIr5bGfQr3qna/52JwCE d59HIVYblCB3fmUTf3b1S2p9Sijm5bpgRb31RekCu9QuoQeMZeZDrqbXySu9HsH0tl OFQV3kstAYnVssmmuuXMC3oUkrvHyhV1R+6b7vVI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335137014; i=@elandsys.com; bh=+WwuQbXxhc335R4oxqdc4sF7g+jnLTZ6lttDABvZPVQ=; h=Date:To:From:Subject:Cc; b=B9tdUm2KLNi4bxQyz/+dPVSB3oO/RKymP75+gt6FK4pNjjJmmmy0uUrgW9yFp7a+K cGq/aR9f4z90r54JF2xM42b4j0MbVbyGr1VJ+rQzIAj3ukxWTf7zlRfzapm6g0nHDK bYtvlBGzew2kB3okYy3ky/m11RpuWzJ69u7h3lM8= Message-Id: <6.2.5.6.2.20120422160923.09940d30@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 22 Apr 2012 16:21:31 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: [spfbis] IETF83 SPFBIS minutes - Version 0.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Apr 2012 23:23:41 -0000 The SPFBIS WG held a meeting at IETF83. This is Version 0.1 of the minutes. Please email me if there are any changes. SPF Update Working Group Minutes Meeting : IETF83, Friday 30 March, 2012 Location: Paris, 09:00 to 11:00 Chairs : Andrew Sullivan Minutes : John Levine Version 0.1 AGENDA A. Meeting Administrivia Note well Agenda bashing B. RFC 4408 issues C. SPF RR Type and TXT RR (issue #9) D. DNS amplification attacks E. Is a deployment document needed F. Path authorization/updating SMTP G. Adoption of draft-kucherawy-spfbis-experiment-03 describing the SPF/Sender-ID experiment and discussion H. Any Other Business A. Meeting Administrivia Andrew Sullivan chaired the IETF83 SPFBIS Working Group meeting in Paris, France. John Levine was the scribe and Murray S. Kucherawy and Tony Hansen were the Jabber scribes. There were 20 people in the room. The Chair brought the Note Well to the attention of the meeting participants, asked them to sign the blue sheets, bashed the agenda. B. RFC 4408 issues RFC 4408 issues are listed at http://trac.tools.ietf.org/wg/spfbis/trac/report/1 Issue #5 is about some ambiguities in the specification. Issue #7, #8 and #16 are there to be tracked. The working group will work on text once it has adopted a draft. Issue #15 is about MAIL FROM. Some of the issues have not been opened for discussion on the list yet. Issue #18 is about adding a SMTP code. It is not clear whether it is within the charter. The Chair mentioned that SERVFAIL is not an error in DNS. Scott Kitterman asked via Jabber how can we know whether we are done if there is no text to agree on. The Chair explained that the basic idea is that once substantive discussion is done, what needs to be done is to agree on text. Arguing on the details of the text is easier once the working group agrees on what it wants to say. The Chair mentioned that errata have to be addressed in a bis document and that it is straight-forward. Issue #4 was ruled as out of scope. There wasn't any objection. The Chair asked the floor for opinions about Issue #10 which is about replacing the Received-SPF: header. Scott Kitterman commented that it cannot be deprecated as there are still people using them. Tony Hansen explained that deprecation means not to use it in future implementations as it will go away at some point, it does not mean that it is no longer supported in the specification. There were two people in the Jabber room in favor of deprecating and using the Authentication-Results: header. Doug Otis commented on having the IP address in Authentication-Results: like Received-SPF: does. The Chair called for a hum for: (i) Received-SPF is deprecated (ii) Not to do anything about Received-SPF: The hum favored deprecation. As somebody was not in favor of deprecation, the Chair asked for the person to explain why. Alessandro Vesely considered that deprecation is the wrong word. The Chair clarified that if people believe that the header is useful,it should stay, otherwise, it should go away. Alessandro Vesely stated thyat it should go away but it should be deprecated for servers and not for clients. Scott Kitterman mentioned that things can be deprecated for a long time before they actually get removed; the working group could state a preference. S. Moonesamy, as an individual, commented that deprecation can be done by clients not sending it but receivers supporting it, meaning that things will continue parsing the header for some time. The Chair pointed out that there were three possibilities on the table: (i) Servers complain but clients continue to use it (ii) Clients keep sending it but servers do not say anything when they get one (iii) We just deprecate it and maybe people get warnings Pete Resnick, as Area Director, asked for comments about the interoperability problem if people continued to use Received-SPF; i.e. what the problem with keeping it around is. He asked that if there wasn't a problem with generating them, what's the use of deprecating them. The idea was about long-term simplification. John Levine mentioned that if you were allowed to generate both headers, they could disagree. The Chair suggested that someone send their best arguments to the mailing list for deprecating and someone else sends arguments for deprecating. The Chair also suggested that Doug Otis makes the argument for "do not deprecate, leave it alone" on the mailing list and Doug agreed. Murray Kucherawy commented on Issue #11 saying that check_host() looks awfully lot like an API whereas the IETF does not define APIs. Pete Resnick, as Area Director, preferred to see the specification to be written in terms of semantics of the protocol elements rather than processing. Murray Kucherawy volunteered to write a paragraph to mention that it is merely an illustration. The discussion on the mailing list about Issue #13 was inconclusive. The Chair asked whether Best -Guess SPF was in scope at all and if so what does the working group want to say about it, with the default being not to say anything. Scott Kitterman pointed out that it was not left out of RFC 4408 by accident. Murray Kucherawy argued that as there are places such as gmail.com which makes use of this, it would help to have some clarifying text about it. Murray Kucherawy asked whether the IESG has an opinion about widely deployed or whether it only wants to see whetehr the working group did its homework. The Chair commented that "widely deployed" can be done on a case by case basis and based on the Conclusions that the working group draws. There wasn't any objections. The Chair commented that he did not completely understand what the issue was with Issue #14. Nobody argued that the working group must deprecate local-part macros. The Chair closed the issue with "won't fix". The Chair will reconsider the issue if there is text to go in the Security considerations section of the document. John Levine pointed out that as there is only one person in favor of the argument, it should be closed. The Chair stated that if there is a legitimate argument, it should go into the security considerations section. John Levine revised a previous comment he made by pointing out that there are a vast number other of ways to generate an attack. The Chair pointed out that SPF sucks does not belong in the document. Pete Resnick, as Area Director, explained what he understood from the discussion of Issue #14: the working group sufficiently considered the issue and agreed not to deprecate the feature; it can add clarification in the Security Considerations section. The Chair stated that the issue will be closed with "won't fix" and a new issue can be added saying that the working group will add text in the security considerations section. Alessandro Vesely asked a clarifying question about whether a domain using local-part macros is badly administered. Scott Kitterman objected to adding text about this issue in the Security Considerations section. Pete Resnick, as Area Director, mentioned that he can object to the new issue and provide reasons for why the text should not be added. Eliot Lear pointed out that the discussion was about two sentences which were non-normative where the risk does not even have to be characterized. The Chair asked whether anyone would like to argue about Issue #16, in favor of relaxing the syntax checking. As there were no arguments, the issue was closed with "won't fix". Issue #16 is about the PTR mechanism. There was support on the mailing list for adding "SHOULD NOT" text about this. The issue was closed pending the new document. C. SPF RR Type and TXT RR (issue #9) The were people on the mailing list in favor of using the TXT RR appeared to be a modest majority and there were people who argued for SPF RR Type on the grounds of DNS hygiene. The Chair explained that it appears as an empirical matter, overwhelmingly, the TXT RR is used but RRTYPE 99 does not qualify under the unused provision of the SPFBIS charter. Dave Crocker mentioned that we have not had consensus about the definition of "unused" and pointed about that the definition is hugely required in this case. Dave Crocker agreed with the Chair that there was little adoption of RRTYPE 99 and mentioned that functionally, after this many years, it is serving as cruft, it is redundant and offers no benefit after this long. He suggested this also as one definition of "unused". Tony Hansen asked whether any sites publishing RRTYPE 99 were found in the surveys done. Murray Kucherawy pointed out that if this was the case, the position stated by Dave Crocker would be false. The Chair reminded the working group about a comment from Scott Kitterman stating that if people were publishing RRTYPE 99 only, it is an indication of them not knowing what they were doing anyway. Peter Koch suggested changing some of the experimental components into production if the experiment was successful. It pointed out the working group does not own the TXT RR or the zone apex and it should probably keep that in mind. He reminded the working group that there has been this humongous argument about deployed base within the IETF. He considered it ill-advised to make decisions which may have long term consequences based on the results of the experiment only. The Chair mentioned that the evidence suggests that SPF is widely deployed, likely more widely deplyed than IPv6. Scott Kitterman mentioned that there was an interoperability issue which would have to be clarified. Pete Resnick, as Area Director, in response to Peter Koch's comments, mentioned that in the deal with the IESG, as a general statement, the working can removed what is unused and put in what is widely deployed. He pointed out that saying that TXT RR is part of an experiment is contrary to the agreement made with the IESG. His opinion is that either way, the proposal is stuck with TXT RR and that it is not an issue. The only issue is whether the proposal can remove the SPF RRTYPE as unused. Eliot Lear did not see the point of keeping the SPF RRTPE given the results of the survey. He mentioned that he did not hear a compelling technical argument for keeping the RRTYPE. Murray Kucherawy suggested adding an appendix to the conclusion document about the experience in developing the RRTYPE given recent discussions on other IETF mailing lists. He proposed that it would be better if it was done as an IESG statement. Pete Resnick, as Area Director, did not think that an IESG statement is appropriate. The conclusion reached by the Chair was that the document will say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99. In the experiment result document that 166 out of 251,000 domains surveyed published only RRTYPE 99. On a procedural point, the Area Director stated that he would like the working group to document that fact. The IESG consider that fact should it come up in an appeal. Tony Hansen commented that when you write a protocol, there is definite harm if there is a choice in what you publish and what you look for. He is of the view that there is a definite bug in RFC 4408. D. DNS amplification attacks The Chair proposed that the working group asks the DNS Directorate whether there is a serious issue (#24) here because there has been previous analysis of this issue. Peter Koch stated as a member of the DNS Directorate his preference for the question to be more open or more to the point. He would like a little less ambiguity in the question; adding that a straight yes or no answer should not be expected. The Chair commented that he was not expecting a straight answer; he would never expect a straight yes or no answer from anybody with any question having to do with DNS. E. Is a deployment document needed The Chair mentioned that he does not think the the charter allows for a deployment document. The Chair asked for a three-way hum: 1. Don't do anything at all and let someone else produce deployment guide 2. Add some deployment notes as an appendix in the bis document 3. Separate document There was a little bit for 1, a tiny noise for 2 and a medium noise for 3. Hector Santos commented that a deployment document may be outside the scope of the working group. Dave Crocker suggested writing the text and figuring out where it should go and the Chair agreed. F. Path authorization/updating SMTP The Chair explained that this is mainly about mail forwarding (Issue #12) and that the discussion on the mailing list was completely inconclusive. Alessandro Vesely commented on the important of having forwarding procedures devised. They Chair asked whether that was protocol advice or deployment advice. Alessandro Vesely pointed out that the specification is not in accordance with the SMTP specification which mentions that one can forward while keeping the Return-path unaltered. John Levine commented that SMTP is designed to deliver mail over whichever path is supposed to work and it can be argued that SPF is broken by design; SPF takes the practical path by assuming that all mail is delievred over a predictable path. The Chair stated that this issue is deployment advice. Alessandro Vesely did not object to the statement. G. Adoption of draft-kucherawy-spfbis-experiment-03 draft-kucherawy-spfbis-experiment-03 was adopted as a working group I-D. Due to a technical glitch in the datatracker, the filename of the draft could not be changed. The Chair pointed out that there has not been any alternative proposal. Murray Kucherawy gave a presentation of the document describing the SPF/Sender-ID experiment. http://www.ietf.org/proceedings/83/slides/slides-83-spfbis-0.ppt He will shortly have extensive data on published SPF records. Several people commented on other material that might be reported, e.g., how often to checks succeed or fail, and how well do SPF and Sender-ID describe legitimate mail flows. He will add some text. The Chair noted that people who want this to move ahead need to help finish the experiment report. There was a comment to add some methodology. [This part is not extensive due to an audio cut] H. Any Other Business The meeting was adjourned at 10:17 a.m. Regards, S. Moonesamy From msk@cloudmark.com Sun Apr 22 20:03: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 5F23621F84E6 for ; Sun, 22 Apr 2012 20:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5B2nWkgvupvA for ; Sun, 22 Apr 2012 20:03:11 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id CAD2C21F84D9 for ; Sun, 22 Apr 2012 20:03:11 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 1F3B1j0010as01C01F3Bxu; Sun, 22 Apr 2012 20:03:11 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 20:03:11 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anzRGA//+OihCAAHiZAP//5Qzw Date: Mon, 23 Apr 2012 03:03:10 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FECB6@exch-mbx901.corp.cloudmark.com> References: <27817694.IMgqELHbEC@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FEA8F@exch-mbx901.corp.cloudmark.com> <3850142.Cln9WJldGb@scott-latitude-e6320> In-Reply-To: <3850142.Cln9WJldGb@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335150191; bh=EBomImG+cvpeWH6vkyEljtb6+8ZvVmyiKoHinoPu2VY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ds6qVwJqHT4rQ28tbAIM7IphRiy186LaTSIrtX/hXhluSEC8U4KoYrY/2L1sT3kCo qrzHNfZ+AJzC0fWel9BV7T+PVdJQU6TKO6Bctejbyq/s/nz6Z0chui0WylCSPi/Jhy ibjmIiZ+aJ0dhIUpVtIfu93NaTE3yCKkHobbDc/U= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 03:03:12 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Sunday, April 22, 2012 2:38 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > > Is it necessary to be that precise in this document's context? >=20 > It was an important enough issue at the time that IESG [1] and IAB [2] > appeals on the practice were filed. I think pretending that this was > an even handed data reuse issue is flat out wrong. In short, on this > issue, yes. How does it further frame or resolve the investigation into which one has e= njoyed more uptake than the other? At this point, that's the filter it app= ears we should be using. -MSK From spf2@kitterman.com Sun Apr 22 20:28: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 01C3A21F8531 for ; Sun, 22 Apr 2012 20:28: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFW2+sLX19Hg for ; Sun, 22 Apr 2012 20:28:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4807F21F8526 for ; Sun, 22 Apr 2012 20:28:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9FB3620E40E0; Sun, 22 Apr 2012 23:28:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335151721; bh=kRz4A4rgbwBhpwsFGwzmeZ30t97P3UVfrb7fXzMbcto=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ijMChft9cgvY7mNCxEQtHJbt0rW1mTx4gmJsVk29Z3dvuORp2UOV1Z6fbPC6wv/Xr Srgs79IvbDeNCueT2JgK2lOsIh6IAXqxDg0yUkdOyjN7J95eSHBTLxQciLhD7fPOT5 mtg+5VBwWXstOnBsmIY7bn/ReU7TmsfHxhPFdIK8= Received: from scott-latitude-e6320.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 ESMTPSA id 82DCC20E4091; Sun, 22 Apr 2012 23:28:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 22 Apr 2012 23:28:41 -0400 Message-ID: <16903045.7Ta8mtnNKj@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FECB6@exch-mbx901.corp.cloudmark.com> References: <3850142.Cln9WJldGb@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FECB6@exch-mbx901.corp.cloudmark.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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 03:28:43 -0000 On Monday, April 23, 2012 03:03:10 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Sunday, April 22, 2012 2:38 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 > > > > > Is it necessary to be that precise in this document's context? > > > > It was an important enough issue at the time that IESG [1] and IAB [2] > > appeals on the practice were filed. I think pretending that this was > > an even handed data reuse issue is flat out wrong. In short, on this > > issue, yes. > > How does it further frame or resolve the investigation into which one has > enjoyed more uptake than the other? At this point, that's the filter it > appears we should be using. Since Sender ID makes use of SPF records, it is possible to make the claim that lack of publishing Sender ID specific records is not a sign of disinterest in Sender ID, but in fact a sign that few senders find problems with publishing an SPF records for both. Since a large number of domains (I don't have a number I can support, but it's clear that SPF was widely adopted before the Sender ID RFCs were published) published records before they were used for both protocols, I think it's an important point that all those domains were opt-ed in to the Sender ID experiment involuntarily. There are any number of ways we could re-write history to make things more palatable, but I think it's important that what we say be correct. Scott K From msk@cloudmark.com Sun Apr 22 20:40: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 9DB0521F84E6 for ; Sun, 22 Apr 2012 20:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpCGXEdUrbDe for ; Sun, 22 Apr 2012 20:40:24 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8F321F84E1 for ; Sun, 22 Apr 2012 20:40:24 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1FgN1j0010ZaKgw01FgN8Q; Sun, 22 Apr 2012 20:40:22 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=9k2WJzzG7kon74edPhkA:9 a=ijHgvR0mi_SDZDHKJJoA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=aiZyTcQNIzHW0AqmVFsA:9 a=5CRaVbMV4vx6eK5jyJcA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 20:40:22 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anwbsg Date: Mon, 23 Apr 2012 03:40:21 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280FED0Dexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335152422; bh=d53kQ4Catf+sNjZunlffGn/NKEfm9D099ui/k9jOcuo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=N4ch/Qn9LJqv7plLVrABCSTgyVtHvHlViHI5sXB9/4yYNytMkl2N+Yl3k47xD9pca TiwK5pG1Hj0+77zHQMDniJwakiKUrfgm26fUChVMoVqaXl6kdJ1OLSkv6kFs7WIuz9 G9ylP6vOtsutkhgfA+gX3tlzTtQSg0NGr/fnHrIU= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 03:40:27 -0000 --_000_9452079D1A51524AA5749AD23E0039280FED0Dexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline (alas): From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Barry Leiba Sent: Sunday, April 22, 2012 1:58 PM To: spfbis@ietf.org Subject: [spfbis] Review of draft-ietf-spfbis-experiment-05 OLD 3. Although the two mechanisms often used different email addresses as the subject being evaluated, no data collected showed any substantial operational benefit (e.g., cheaper processing, improved accuracy) to using Sender-ID over SPF. I suggest "to using either mechanism over the other." [MSK: I don't think that's correct. Sender ID has a substantially higher p= rocessing cost given that it requires accepting the DATA part of the messag= e and has an obviously higher cost to extract the various identifiers the P= RA algorithm considers. SPF, purely compute-wise, is cheaper. However, th= eir accuracy is comparable. If we want to be clear, we can say their accur= acies are about the same, but SPF is operationally cheaper.] --_000_9452079D1A51524AA5749AD23E0039280FED0Dexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments inline (alas):

 <= /p>

From: spfbis-b= ounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Barry Leiba
Sent: Sunday, April 22, 2012 1:58 PM
To: spfbis@ietf.org
Subject: [spfbis] Review of draft-ietf-spfbis-experiment-05

 

OLD

   3.  Although the two mechanisms of= ten used different email addresses

       as the subject being eval= uated, no data collected showed any

       substantial operational b= enefit (e.g., cheaper processing,

       improved accuracy) to usi= ng Sender-ID over SPF.

 

I suggest "to using either mechanism over the o= ther."


[MSK: I don’t think that’s correct.  Sender ID has a subst= antially higher processing cost given that it requires accepting the DATA p= art of the message and has an obviously higher cost to extract the various = identifiers the PRA algorithm considers.  SPF, purely compute-wise, is cheaper.  However, their accuracy is comparable. &nb= sp;If we want to be clear, we can say their accuracies are about the same, = but SPF is operationally cheaper.]

 

--_000_9452079D1A51524AA5749AD23E0039280FED0Dexchmbx901corpclo_-- From msk@cloudmark.com Sun Apr 22 20:51: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 181F521F84DF for ; Sun, 22 Apr 2012 20:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au0CNDX+xKq8 for ; Sun, 22 Apr 2012 20:51:46 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 52E9F21F84F8 for ; Sun, 22 Apr 2012 20:51:46 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 1Frl1j0010as01C01FrlB8; Sun, 22 Apr 2012 20:51:45 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=6oOKkq69zweqNnNsXDwA:9 a=82MWxT46JCWIyOdjoGUA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=uDqZWuVI5siDKuBy:21 a=kWv-wJhs9-teDX1_:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 20:51:45 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anzRGA//+OihCAAHiZAP//5QzwgAB83oD//46t8A== Date: Mon, 23 Apr 2012 03:51:45 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FED45@exch-mbx901.corp.cloudmark.com> References: <3850142.Cln9WJldGb@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FECB6@exch-mbx901.corp.cloudmark.com> <16903045.7Ta8mtnNKj@scott-latitude-e6320> In-Reply-To: <16903045.7Ta8mtnNKj@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335153105; bh=8SxkyV6FN+RQVgvtS8h/mIQ1D+TpBqAElifTOxj9tfw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KaYHD5wSbK2xbeKd7oQnhC3NJQZfCMxCaMaN+XKGcivHGmwEdEBzst2kFGARUarR+ Ic/jnIQO2D0j9ASp9nTd8dJ3Zdmk+Ia+qIUBta/6p8BqVZWg8YDvALrfkENfjt+YQ5 VpFR42YPbPq4TtiErh24heGTyV7FnTmAL6Vp0Dh4= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 03:51:47 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Sunday, April 22, 2012 8:29 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > Since Sender ID makes use of SPF records, it is possible to make the > claim that lack of publishing Sender ID specific records is not a sign > of disinterest in Sender ID, but in fact a sign that few senders find > problems with publishing an SPF records for both. >=20 > Since a large number of domains (I don't have a number I can support, > but it's clear that SPF was widely adopted before the Sender ID RFCs > were published) published records before they were used for both > protocols, I think it's an important point that all those domains were > opt-ed in to the Sender ID experiment involuntarily. Taken together, this says early SPF adopters became unwitting participants = in the Sender ID experiment, but it didn't make a difference in the end bec= ause it didn't cause any problems. If that's the case, then why is highlig= hting who was "here" first (in terms of the DNS mechanism) an important thi= ng? > There are any number of ways we could re-write history to make things > more palatable, but I think it's important that what we say be correct. I think there's a difference between deliberate historical revisionism and = an effort to avoid details that don't appear to be relevant to the matter a= t hand. The actual history is well-documented if the curious want to go un= earth it. We aren't trying to hide anything; we're just trying to (and nee= d to) avoid showing bias. -MSK From spf2@kitterman.com Sun Apr 22 21:02: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 D879D21F852D for ; Sun, 22 Apr 2012 21:02:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5FyHJYFU4il for ; Sun, 22 Apr 2012 21:02:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8B121F848E for ; Sun, 22 Apr 2012 21:02:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9019320E40E0; Mon, 23 Apr 2012 00:02:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335153776; bh=wD6Dm/+VCL8djc9kUOpDMy0M2pb2fmE9E9XFB2N7ruA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=PwCuvE+mvc+IYy7e89y5rVD3uw93lhXFqu0sU/ktP4WRcNPYYOlikIB7PSiePUtBC fTS9NeActaN7T9rtTI/8h6kch4kmf5+zwYcCAkSZe8UjblNablHTOi6rlElFYnacCN QNm3T3LdCW9NKXFgp39FQO4Ap3LQRD6T1WVAk/mE= Received: from scott-latitude-e6320.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 ESMTPSA id 72F2420E4091; Mon, 23 Apr 2012 00:02:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Apr 2012 00:02:55 -0400 Message-ID: <2738361.74YB1Lktta@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FED45@exch-mbx901.corp.cloudmark.com> References: <16903045.7Ta8mtnNKj@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FED45@exch-mbx901.corp.cloudmark.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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 04:02:58 -0000 On Monday, April 23, 2012 03:51:45 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Sunday, April 22, 2012 8:29 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 > > > > Since Sender ID makes use of SPF records, it is possible to make the > > claim that lack of publishing Sender ID specific records is not a sign > > of disinterest in Sender ID, but in fact a sign that few senders find > > problems with publishing an SPF records for both. > > > > Since a large number of domains (I don't have a number I can support, > > but it's clear that SPF was widely adopted before the Sender ID RFCs > > were published) published records before they were used for both > > protocols, I think it's an important point that all those domains were > > opt-ed in to the Sender ID experiment involuntarily. > > Taken together, this says early SPF adopters became unwitting participants > in the Sender ID experiment, but it didn't make a difference in the end > because it didn't cause any problems. If that's the case, then why is > highlighting who was "here" first (in terms of the DNS mechanism) an > important thing? > > There are any number of ways we could re-write history to make things > > more palatable, but I think it's important that what we say be correct. > > I think there's a difference between deliberate historical revisionism and > an effort to avoid details that don't appear to be relevant to the matter > at hand. The actual history is well-documented if the curious want to go > unearth it. We aren't trying to hide anything; we're just trying to (and > need to) avoid showing bias. Facts are not bias. Wanting to sweep them under the rug is bias. What I am asking for is the exact opposite of bias. Scott K From spf2@kitterman.com Sun Apr 22 21:07: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 D326621E8018 for ; Sun, 22 Apr 2012 21:07:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXv-9On9758r for ; Sun, 22 Apr 2012 21:07:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 04C4521E8013 for ; Sun, 22 Apr 2012 21:07:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8940F20E40E0; Mon, 23 Apr 2012 00:07:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335154030; bh=tj2fKImPS+qsASoAzD6fOOCMzJ9kZGTdzZV7mRPTwHk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=bf0tq6jlnXg1+m/hg7MOWg1iiQrT5VEc0N3F+Pl8j1F3bIx+l8tGaaq9c1ftm+G+E OThN8OLELYrs/oxnmrq7o+dLkyzZDlsrUzyUcdIhBXcXNeWQgAmgXSZbxr+48HSfN7 Vx8wBrdJLuc/sF9DIkqMeEyZxSWJ5Xbfs2Sidrf0= Received: from scott-latitude-e6320.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 ESMTPSA id 5550320E4091; Mon, 23 Apr 2012 00:07:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Apr 2012 00:07:09 -0400 Message-ID: <1464772.NHJB6P54Ra@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 04:07:12 -0000 On Monday, April 23, 2012 03:40:21 AM Murray S. Kucherawy wrote: > Comments inline (alas): > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of > Barry Leiba Sent: Sunday, April 22, 2012 1:58 PM > To: spfbis@ietf.org > Subject: [spfbis] Review of draft-ietf-spfbis-experiment-05 > > OLD > 3. Although the two mechanisms often used different email addresses > as the subject being evaluated, no data collected showed any > substantial operational benefit (e.g., cheaper processing, > improved accuracy) to using Sender-ID over SPF. > > I suggest "to using either mechanism over the other." > > [MSK: I don't think that's correct. Sender ID has a substantially higher > processing cost given that it requires accepting the DATA part of the > message and has an obviously higher cost to extract the various identifiers > the PRA algorithm considers. SPF, purely compute-wise, is cheaper. > However, their accuracy is comparable. If we want to be clear, we can say > their accuracies are about the same, but SPF is operationally cheaper.] SPF is also not fundamentally incompatible with existing internet standards in a way that prevents it from being advanced, documented in a different appeal [1]. One very good answer to "Why advance SPF and not Sender ID?" is that there are standards issues with Sender ID that don't exist with SPF. Even if they had equivalent operational complexity/cost, that would, IMO, be enough to be determinant. Scott K [1] http://www.ietf.org/iesg/appeal/leibzon-2005-08-29.txt From msk@cloudmark.com Sun Apr 22 21:08: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 C4D6421E8018 for ; Sun, 22 Apr 2012 21:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.638 X-Spam-Level: X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqQ-Ve5quFNo for ; Sun, 22 Apr 2012 21:08:45 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3880B21E8013 for ; Sun, 22 Apr 2012 21:08:45 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1G8u1j0010ZaKgw01G8uqc; Sun, 22 Apr 2012 21:08:54 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 21:08:33 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anzRGA//+OihCAAHiZAP//5QzwgAB83oD//46t8AAPXI6AAA6FPMA= Date: Mon, 23 Apr 2012 04:08:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FED69@exch-mbx901.corp.cloudmark.com> References: <16903045.7Ta8mtnNKj@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FED45@exch-mbx901.corp.cloudmark.com> <2738361.74YB1Lktta@scott-latitude-e6320> In-Reply-To: <2738361.74YB1Lktta@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335154134; bh=Keaspy+WSxVcJeD5Y3Fpj/Y8vIqJ4M8jpl6eptC0NLs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=p3AoQzw/YAgxpZsd9e9ZMNgayhT9JWPU/xDSTOwo+XUjOO74dOj6V95xX7piyoGCi 25hMtEmoDp3NIJXT/YJZFUDk59wZYuPGOmfP4QXsFZLnd4Hx2JnkUkam6EkRwk5Fsj q8LEBs1eD+FVDolfbruB0Ey3GGugUDbve4+YCATI= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 04:08:45 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Sunday, April 22, 2012 9:03 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > Facts are not bias. Wanting to sweep them under the rug is bias. What > I am asking for is the exact opposite of bias. At this point I think I'll leave it to working group consensus. I don't ha= ve any desire, nor I believe does Barry, to obscure facts that are relevant= to the question. -MSK From spf2@kitterman.com Sun Apr 22 21:26: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 C06A821F849D for ; Sun, 22 Apr 2012 21:26:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU56YBfLZBFV for ; Sun, 22 Apr 2012 21:26:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 214D121F847D for ; Sun, 22 Apr 2012 21:26:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6DD4020E40E0; Mon, 23 Apr 2012 00:25:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335155159; bh=UBduUXc5tKMV7/aUAlKqnyOIkcZxONlfbhKxliY/Fnk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=OdHCDYjLR75ToYfXR7NUuoGoBPMReM1fqX2sY+65EA6MWGd3z5zA/9ZAcH53Joz2Z ADta4VWUwwgOTnOxC/cXJRcoFy9XUtGyC7L1L7VofLRKVo7i2+CQSmFiKSfyQSIQ2u /bNnhiXbfCDvUlbn/vzmSzF54z5mdLMB8GdjJ+yA= Received: from scott-latitude-e6320.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 ESMTPSA id 5516C20E4091; Mon, 23 Apr 2012 00:25:59 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Apr 2012 00:25:58 -0400 Message-ID: <1846527.ofYFpyJhPr@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FED69@exch-mbx901.corp.cloudmark.com> References: <2738361.74YB1Lktta@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FED69@exch-mbx901.corp.cloudmark.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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 04:26:00 -0000 On Monday, April 23, 2012 04:08:33 AM Murray S. Kucherawy wrote: > I don't have any desire, nor I believe does Barry, to obscure facts that are > relevant to the question. I don't believe you or Barry does either. Scott K From barryleiba.mailing.lists@gmail.com Sun Apr 22 21:52: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 335E821F8542 for ; Sun, 22 Apr 2012 21:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V8mJeiw-joE for ; Sun, 22 Apr 2012 21:52:31 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9903B21F8537 for ; Sun, 22 Apr 2012 21:52:30 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6817559ghb.31 for ; Sun, 22 Apr 2012 21:52:29 -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=cbSwb98IdzLACKBxmPF1cTFDeppIEVeNZTdV+rh/IN8=; b=HA6QzFE8jcPjGzYSkMcGttMdt4a/3b+7fxImqWm6GeOUBg17OS3epYAqNdbZ4vl5Lp GW5FWoyAvhBOC2NgSfWbzCLVnYklMppbKNSjnJK26Yek7WPlxkXxNEs99BvvnvK8CFs1 NAXgbBPT7RC7TgcGZFueP3LfJlsPG4xpXWkiLwHUmPr0EsUC2s6vlPv6o52r5H1rfCPg pjmOLpxLkwfvMAd8EssBTb8ArkBnyLY1kkenWnABNfGsloaxCMTR25e6iI8jzKEr3jS9 pk4tGR/r+AYVOv2pdIVvJfvCtcusTtcAXRP6jPxonI5XQFKNHAD8FKvH1WTMpy0oqs3x G3sA== MIME-Version: 1.0 Received: by 10.236.154.35 with SMTP id g23mr13331799yhk.107.1335156749413; Sun, 22 Apr 2012 21:52:29 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.152.14 with HTTP; Sun, 22 Apr 2012 21:52:29 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> Date: Mon, 23 Apr 2012 00:52:29 -0400 X-Google-Sender-Auth: p_SMr3inyJjLbn9VBkqJ0-8e2qg Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=20cf303b427dc4ab4704be516732 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 04:52:34 -0000 --20cf303b427dc4ab4704be516732 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ah... Then the whole item 3 needs to be reworded to say what is actually the case with respect to processing cost and accuracy. If there actually is a benefit to SPF here, say so. Barry On Sunday, April 22, 2012, Murray S. Kucherawy wrote: > Comments inline (alas):**** > > ** ** > > *From:* spfbis-bounces@ietf.org 'spfbis-bounces@ietf.org');> [mailto:spfbis-bounces@ietf.org] > *On Behalf Of *Barry Leiba > *Sent:* Sunday, April 22, 2012 1:58 PM > *To:* spfbis@ietf.org > *Subject:* [spfbis] Review of draft-ietf-spfbis-experiment-05**** > > ** ** > > OLD**** > > 3. Although the two mechanisms often used different email addresses**= * > * > > as the subject being evaluated, no data collected showed any**** > > substantial operational benefit (e.g., cheaper processing,**** > > improved accuracy) to using Sender-ID over SPF.**** > > ** ** > > I suggest "to using either mechanism over the other."**** > > > [MSK: I don=92t think that=92s correct. Sender ID has a substantially hi= gher > processing cost given that it requires accepting the DATA part of the > message and has an obviously higher cost to extract the various identifie= rs > the PRA algorithm considers. SPF, purely compute-wise, is cheaper. > However, their accuracy is comparable. If we want to be clear, we can sa= y > their accuracies are about the same, but SPF is operationally cheaper.]**= * > * > > ** ** > --20cf303b427dc4ab4704be516732 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ah... Then the whole item 3 needs to be reworded to say what is actually th= e case with respect to processing cost and accuracy. =A0If there actually i= s a benefit to SPF here, say so.

Barry

On Sunday, April 22, 2012, Murray S. Kucherawy wrote:

Comments inline (alas):

=A0<= /p>

From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Barry Leiba
Sent: Sunday, April 22, 2012 1:58 PM
To: spfbis@ietf.org
Subject: [spfbis] Review of draft-ietf-spfbis-experiment-05

=A0

OLD

=A0 =A03. =A0Although the two mechanisms often used = different email addresses

=A0 =A0 =A0 =A0as the subject being evaluated, no da= ta collected showed any

=A0 =A0 =A0 =A0substantial operational benefit (e.g.= , cheaper processing,

=A0 =A0 =A0 =A0improved accuracy) to using Sender-ID= over SPF.

=A0

I suggest "to using either mechanism over the o= ther."


[MSK: I don=92t think that=92s correct.=A0 Sender ID has a substantially hi= gher processing cost given that it requires accepting the DATA part of the = message and has an obviously higher cost to extract the various identifiers= the PRA algorithm considers.=A0 SPF, purely compute-wise, is cheaper.=A0 However, their accuracy is comparable. =A0If = we want to be clear, we can say their accuracies are about the same, but SP= F is operationally cheaper.]

=A0

--20cf303b427dc4ab4704be516732-- From msk@cloudmark.com Sun Apr 22 22:02: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 4653F21F84DF for ; Sun, 22 Apr 2012 22:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgLbx1nmqGSF for ; Sun, 22 Apr 2012 22:02:53 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1263921F84C2 for ; Sun, 22 Apr 2012 22:02:52 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 1H3C1j0010as01C01H3C20; Sun, 22 Apr 2012 22:03:12 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=gdJdk1cwjiL5HxsOaA8A:9 a=T7UO-ZstTS2PPFDYeXkA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=SW0DC1kVWCxFyQ5Ln38A:9 a=o8SeYtZ8310z8KSlTWUA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 22:02:52 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anwbsggACLzYD//4ztsA== Date: Mon, 23 Apr 2012 05:02:51 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FEDE1@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280FEDE1exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335157392; bh=sRuI2868gFheuk1Yt80hjRKo2USGeT3U9Ga8U5eoV2M=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ayphv+z4gVgEcOA+LoE2LFeA8OX9+CBdudsZmRJP5A5BcbLzb4JmNd2/w5vWPXgaJ ehUAF/FWzX4qqtcTk1BvF8L7MFOgbDoRuyyVBt3umO/SdZP/NuZDZEgLWfoJwsKHqW qOR/6/+aS09XXL2njHd4bl7k858WrDH3ImpyQCxI= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 05:02:54 -0000 --_000_9452079D1A51524AA5749AD23E0039280FEDE1exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, I don't think we need to get into the benefits of one over the ot= her. We're merely measuring and reporting on adoption since publication, n= ot the "why" part. That's already covered in the "people voted with their = feet" bit. So the net change, I think, is to remove the mention of cheaper processing,= and just say the accuracy of the two is comparable. From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of= Barry Leiba Sent: Sunday, April 22, 2012 9:52 PM To: Murray S. Kucherawy Cc: spfbis@ietf.org Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 Ah... Then the whole item 3 needs to be reworded to say what is actually th= e case with respect to processing cost and accuracy. If there actually is = a benefit to SPF here, say so. --_000_9452079D1A51524AA5749AD23E0039280FEDE1exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, I don’t t= hink we need to get into the benefits of one over the other.  We’= ;re merely measuring and reporting on adoption since publication, not the “why” part.  That’s already covered in the “p= eople voted with their feet” bit.

 <= /p>

So the net change, I thin= k, is to remove the mention of cheaper processing, and just say the accurac= y of the two is comparable.

 <= /p>

From: spfbis-b= ounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Barry Leiba
Sent: Sunday, April 22, 2012 9:52 PM
To: Murray S. Kucherawy
Cc: spfbis@ietf.org
Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05=

 

Ah... Then the whole item 3 needs to be reworded to = say what is actually the case with respect to processing cost and accuracy.=  If there actually is a benefit to SPF here, say so.

 

 

--_000_9452079D1A51524AA5749AD23E0039280FEDE1exchmbx901corpclo_-- From john@jlc.net Mon Apr 23 03:07: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 0B3BB21F869A for ; Mon, 23 Apr 2012 03:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.034 X-Spam-Level: X-Spam-Status: No, score=-106.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eieNOOxw+quf for ; Mon, 23 Apr 2012 03:07:53 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DE40921F8682 for ; Mon, 23 Apr 2012 03:07:52 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 701FD33C21; Mon, 23 Apr 2012 06:07:52 -0400 (EDT) Date: Mon, 23 Apr 2012 06:07:52 -0400 From: John Leslie To: Barry Leiba Message-ID: <20120423100752.GQ99904@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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 10:07:54 -0000 Barry Leiba wrote: >... > > OLD > Due to the absence of consensus behind one or the other, and because > Sender-ID supported use of the same policy statement defined by SPF, > the IESG at the time was concerned that an implementation of > Sender-ID might erroneously apply that statement to a message and, > depending on selected recipient actions, could improperly interfere > with message delivery. > > This seems to have a significant SPF bias. May I suggest this?: > > NEW > Due to the absence of consensus behind one or the other and because > SPF and Sender-ID supported use of the same policy statement with > different semantics, the IESG at the time was concerned that > implementations of SPF or Sender-ID might erroneously apply a > statement that had been published with the semantics of the other, > and, depending on selected recipient actions, could improperly > interfere with message delivery. Both of these try to put words in the mouth of an IESG of many years ago (before either Barry or I was scribing). I advise against doing so. Please, consider the actual IESG statement: --------------------------------cut here-------------------------------- Date: Wed, 22 Sep 2004 15:52:55 -0400 From: The IESG Subject: WG Action: Conclusion of MTA Authorization Records in DNS (marid) To: IETF-Announce@ietf.org Cc: ietf-mxcomp@imc.org, "Marshall T. Rose" , Andrew Newton The MTA Authorization Records in DNS (MARID) working group in the Applications Area has concluded. The IESG contact persons are Ted Hardie and Scott Hollenbeck. The mailing list will remain active. After an assessment of the current state of the MARID working group, its charter, and its milestones, the working group chairs and Area Advisor concluded that the MARID working group should be terminated. The group was originally chartered with a very tight time frame, with the expectation that a focused group of engineers would be able to produce in relatively short order a standard in the area of DNS-stored policies related to and accessible by MTAs. The group has had no lack of energy. From the outset, however, the working group participants have had fundamental disagreements on the nature of the record to be provided and the mechanism by which it would be checked. Technical discussion of the merits of these mechanisms has not swayed their proponents, and what data is available on existing deployments has not made one choice obviously superior. Each represents trade-offs, and the working group has not succeeded in establishing which trade-offs are the most appropriate for this purpose. These assessments have been difficult in part because they have been moved out of the realm of pure engineering by the need to evaluate IPR and licensing related to at least one proposal in the light of a variety of licenses associated with the deployed base of MTAs. Efforts to reach consensus by compromise and by inclusion have been attempted on multiple occasions. Despite early hopes of success after each such attempt, post-facto recycling of technical issues which these efforts should have closed has shown that the group remains divided on very basic issues. The working group chairs and Area Advisor are agreed that the working group has no immediate prospect of achieving its primary milestone: Aug 04 Submit working group document on MTA Authorization Record in DNS to PS --------------------------------cut here-------------------------------- Fundamentally, IMHO, the IESG of 2004 considered MARID a failed WG. --------------------------------cut here-------------------------------- Rather than spin in place, the working group chairs and Area Advisor believe that the best way forward is experimentation with multiple proposals and a subsequent review of deployment experience. The working group chairs and Area Advisor intend to ask that the editors of existing working group drafts put forward their documents as non-working group submissions for Experimental RFC status. Given the importance of the world-wide email and DNS systems, it is critical that IETF-sponsored experimental proposals likely to see broad deployment contain no mechanisms that would have deleterious effects on the overall system. The Area Directors intend, therefore, to request that the experimental proposals be reviewed by a focused technology directorate. This review group has not yet been formed but, as with all directorates, its membership will be publicly listed at http://www.ietf.org/u/ietfchair/directorates.html once it has been constituted. Concluding a group without it having achieved its goals is never a pleasant prospect, and it is always tempting to believe that just a small amount of additional time and energy will cause consensus to emerge. After careful consideration, however, the working group chairs and area advisor have concluded that such energy would be better spent on gathering deployment experience. --------------------------------cut here-------------------------------- The WG list remained quite active for a while, among other things speaking unkindly of the "directorate" mentioned above. In due course Individual I-Ds were submitted which became RFCs 4405-4408. We should be careful in saying anything in spfbis-experiment which puts words beyond the above into the mouth of the 2004 IESG. I believe at the time the above message was sent, the IESG believed that a limited group of reviewers (the "directorate") would be able to enforce sanity on a discussion which seemed to the 2004 IESG to be religious posturing. (That did not happen, of course.) But I don't believe my interpretation belongs in spfbis-experiment, either. I don't believe either "OLD" or "NEW" from Barry's email is appropriate. I could suggest: " " Since the MARID WG was closed without reaching consensus on either, " the 2004 IESG left it to each sub-group to describe the usage they " proposed in Experimental RFCs, with evaluation to be done by some " other body after a period of experimentation. " " This document will discuss the effects of applying different semantics " to the same DNS record but makes no claim to tell the whole story. I'm not at all attached to that particular wording: I just believe that we need to be careful in attributing intent to the 2004 IESG. If, OTOH, you get Ted Hardie's approval to either of those statments, it'd be OK with me. -- John Leslie From spf2@kitterman.com Mon Apr 23 03:50: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 2FF7321F86CB for ; Mon, 23 Apr 2012 03:50:01 -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.017, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXqI3ONuqjKr for ; Mon, 23 Apr 2012 03:50:00 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6FC21F86B2 for ; Mon, 23 Apr 2012 03:50:00 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 6987DD0408C; Mon, 23 Apr 2012 05:49:59 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335178199; bh=mu7Eb0UvV0UI2SVBiNq6F2KZREVQUE9ZuH8tsKphElA=; h=References:In-Reply-To:MIME-Version:Content-Type:Subject:From: Date:To:Message-ID; b=cWwCI9W6fL/wqSXeVz4HYc8hPKflp5fkwe0lXNVY4hnue9yE2n/+GXYEnOs+tGLID N/zjudfIM+Tr4o+iQe474FGSdeJ1gN2yjcPym8egfMoU1xpeQdNuEvaZW9K2WO9z26 y4DG2hyK64W5EOXUP34ooJOnhsZLnA2bIfBTNjfs= Received: from [192.168.111.101] (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 mailout03.controlledmail.com (Postfix) with ESMTPSA id 248CED0404B; Mon, 23 Apr 2012 05:49:58 -0500 (CDT) References: <20120423100752.GQ99904@verdi> User-Agent: K-9 Mail for Android In-Reply-To: <20120423100752.GQ99904@verdi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----9WVYC35508UZZ94784C0ZL2O4A3GG8" From: Scott Kitterman Date: Mon, 23 Apr 2012 06:50:06 -0400 To: "spfbis@ietf.org" Message-ID: <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 10:50:01 -0000 ------9WVYC35508UZZ94784C0ZL2O4A3GG8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Snip. That's all true, but not, I think relevant to the question of record reuse. There was consensus in MARID that reuse of SPF records for Sender ID PRA assessments was technically inappropriate. I don't think it's correct to apply words about the MARID shutdown to changes that were made later. Scott K ------9WVYC35508UZZ94784C0ZL2O4A3GG8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Snip.

That's all true, but not, I think relevant to the question of record reuse. There was consensus in MARID that reuse of SPF records for Sender ID PRA assessments was technically inappropriate.

I don't think it's correct to apply words about the MARID shutdown to changes that were made later.

Scott K ------9WVYC35508UZZ94784C0ZL2O4A3GG8-- From john@jlc.net Mon Apr 23 04:19: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 5569C21F86AF for ; Mon, 23 Apr 2012 04:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.062 X-Spam-Level: X-Spam-Status: No, score=-106.062 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN09HDMLFg6c for ; Mon, 23 Apr 2012 04:19:31 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7235421F86AA for ; Mon, 23 Apr 2012 04:19:31 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2731333C20; Mon, 23 Apr 2012 07:19:30 -0400 (EDT) Date: Mon, 23 Apr 2012 07:19:30 -0400 From: John Leslie To: Scott Kitterman Message-ID: <20120423111930.GR99904@verdi> References: <20120423100752.GQ99904@verdi> <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> User-Agent: Mutt/1.4.1i Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:19:32 -0000 (I see by the threading that Scott replied to my email...) Scott Kitterman wrote: > > Snip. > > That's all true, but not, I think relevant to the question of record > reuse. Perhaps Scott might say _what_ he thinks not relevant. Mostly, I was quoting the IESG post closing the MARID WG. > There was consensus in MARID that reuse of SPF records for Sender ID > PRA assessments was technically inappropriate. Um... No. There was a widespread belief among MARID participants that Sender ID use of already published SPF records was inappropriate, but it was never a WG consensus. > I don't think it's correct to apply words about the MARID shutdown to > changes that were made later. Scott loses me here. I agree that the Sender ID RFCs were not exactly what was discussed before MARID closed -- neither was the SPF RFC... But I was only criticizing wording which purported to state an IESG _intent_. The IESG posting I quoted (in its entirety) is by definition the best source for IESG intent. (Barry and I know firsthand how IESG statements like this are generated.) We also have, of course, the IESG statement in the RFCs in question, which also represents an IESG consensus (though IMHO probably less work went into it than into closing a very-active WG): --------------------------------cut here-------------------------------- RFC 4405 SMTP Responsible Submitter Extension April 2006 ... 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. The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them. Note that the Sender ID experiment may use DNS records that may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt. Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict. Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem. The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future. --------------------------------cut here-------------------------------- (Perhaps Scott sees some IESG "changes" in this; but I don't...) -- John Leslie From vesely@tana.it Mon Apr 23 04:37: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 C2EE021F86B2 for ; Mon, 23 Apr 2012 04:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13N8xhjgH2nN for ; Mon, 23 Apr 2012 04:37:14 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0528421F85A7 for ; Mon, 23 Apr 2012 04:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335181025; bh=VNhVYHg8fV7gOfwCj4OGsZD6UJfjxUk9h/XrC3VOtow=; l=1689; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MUaHGVWeg7KnANeMteIvL/6vBheLWdJuIZ+iC7jPPzIS6CUkVoYKGTIZdhiloPoiU rluKKsuylFyBeBah+/1zvgpVOgh59d0wf2swQMfvWMk9FCZFiP04DIBylaJe5bKwva nhkZ8o9WyIaTm13yrtw/jMI7ESAq1o2raDU8v77w= 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, 23 Apr 2012 13:37:05 +0200 id 00000000005DC033.000000004F953EE1.00003F60 Message-ID: <4F953EE1.50600@tana.it> Date: Mon, 23 Apr 2012 13:37:05 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120422160923.09940d30@elandnews.com> In-Reply-To: <6.2.5.6.2.20120422160923.09940d30@elandnews.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] #10 on Received-SPF deprecation, was IETF83 SPFBIS minutes - Version 0.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:37:19 -0000 On Mon 23/Apr/2012 13:08:19 +0200 S Moonesamy wrote: > > As somebody was not in favor of deprecation, the Chair asked for > the person to explain why. Alessandro Vesely considered that > deprecation is the wrong word. The Chair clarified that if people > believe that the header is useful,it should stay, otherwise, it > should go away. Alessandro Vesely stated thyat it should go away > but it should be deprecated for servers and not for clients. Scott > Kitterman mentioned that things can be deprecated for a long time > before they actually get removed; the working group could state a > preference. S. Moonesamy, as an individual, commented that > deprecation can be done by clients not sending it but receivers > supporting it, meaning that things will continue parsing the header > for some time. What I meant to say is that it is the servers who should deprecate Received-SPF, so that their clients stop checking it and check Authentication-Results instead. That is, 4408bis can recommend that servers deprecate the old field while they add the new. > (ii) Clients keep sending it but servers do not say anything when > they get one Is it me or "server" and "client" were meant w.r.t. the header field usage, rather than SMTP? > John Levine mentioned that if you were allowed to generate both > headers, they could disagree. Yup, there will have to be a "MUST agree at least on the results" (could disagree on the authserv-id, though). > The Chair suggested that someone send their best arguments to the > mailing list for deprecating and someone else sends arguments for > deprecating. There are no arguments for _not_ deprecating ;-) From spf2@kitterman.com Mon Apr 23 04:49: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 D494D21F86D7 for ; Mon, 23 Apr 2012 04:49:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRmOnrWrKD+t for ; Mon, 23 Apr 2012 04:49:58 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF021F86CF for ; Mon, 23 Apr 2012 04:49:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EAE5620E40E0; Mon, 23 Apr 2012 07:49:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335181797; bh=69QdoULq8lGyodmU/ORc1Fqaje1D4tdH5t1wlHi+9FY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=YeUlI2vn9sCMqWAbXe4IhKerEWLoK1ZGoV0elQqa3+TsZQh8H9z3kBU/lPQUqLTxW zFEvuuZAqC87pqe6BMERJ2TJLEVIq6Y4TtfJxHqJpdByq6NaFrtoyvfluvoUI+tNnU XYmjZXBVx/q2U538hZCQ3o3faZyly0VMvxjQtBbQ= Received: from scott-latitude-e6320.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 ESMTPSA id CC97D20E408E; Mon, 23 Apr 2012 07:49:56 -0400 (EDT) From: Scott Kitterman To: "spfbis@ietf.org" Date: Mon, 23 Apr 2012 07:49:52 -0400 Message-ID: <7258848.rfiuW4u4rt@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120423111930.GR99904@verdi> References: <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> <20120423111930.GR99904@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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:49:59 -0000 On Monday, April 23, 2012 07:19:30 AM John Leslie wrote: > (I see by the threading that Scott replied to my email...) Sorry about that. > Scott Kitterman wrote: > > Snip. > > > > That's all true, but not, I think relevant to the question of record > > reuse. > > Perhaps Scott might say _what_ he thinks not relevant. Mostly, I was > quoting the IESG post closing the MARID WG. > > > There was consensus in MARID that reuse of SPF records for Sender ID > > PRA assessments was technically inappropriate. > > Um... No. > > There was a widespread belief among MARID participants that Sender ID > use of already published SPF records was inappropriate, but it was never > a WG consensus. > > > I don't think it's correct to apply words about the MARID shutdown to > > changes that were made later. > > Scott loses me here. I agree that the Sender ID RFCs were not exactly > what was discussed before MARID closed -- neither was the SPF RFC... > But I was only criticizing wording which purported to state an IESG > _intent_. > > The IESG posting I quoted (in its entirety) is by definition the best > source for IESG intent. > > (Barry and I know firsthand how IESG statements like this are > generated.) > > We also have, of course, the IESG statement in the RFCs in question, > which also represents an IESG consensus (though IMHO probably less work > went into it than into closing a very-active WG): > > --------------------------------cut here-------------------------------- > RFC 4405 SMTP Responsible Submitter Extension April 2006 > ... > 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. > > The IESG takes no position about which approach is to be preferred > and cautions the reader that there are serious open issues for each > approach and concerns about using them in tandem. The IESG believes > that documenting the different approaches does less harm than not > documenting them. > > Note that the Sender ID experiment may use DNS records that may have > been created for the current SPF experiment or earlier versions in > this set of experiments. Depending on the content of the record, > this may mean that Sender-ID heuristics would be applied incorrectly > to a message. Depending on the actions associated by the recipient > with those heuristics, the message may not be delivered or may be > discarded on receipt. > > Participants relying on Sender ID experiment DNS records are warned > that they may lose valid messages in this set of circumstances. > Participants publishing SPF experiment DNS records should consider > the advice given in section 3.4 of RFC 4406 and may wish to publish > both v=spf1 and spf2.0 records to avoid the conflict. > > Participants in the Sender-ID experiment need to be aware that the > way Resent-* header fields are used will result in failure to receive > legitimate email when interacting with standards-compliant systems > (specifically automatic forwarders which comply with the standards by > not adding Resent-* headers, and systems which comply with RFC 822 > but have not yet implemented RFC 2822 Resent-* semantics). It would > be inappropriate to advance Sender-ID on the standards track without > resolving this interoperability problem. > > The community is invited to observe the success or failure of the two > approaches during the two years following publication, in order that > a community consensus can be reached in the future. > --------------------------------cut here-------------------------------- > > (Perhaps Scott sees some IESG "changes" in this; but I don't...) It is likely that I am not sufficiently separating myself from the issue since I do have strong feelings on the issues of both Microsoft's and the IESG's roles in all this, so after this I'll drop it. I will, however, make one more attempt. Here is a quote from the IESG statement: > Note that the Sender ID experiment may use DNS records that may have > been created for the current SPF experiment or earlier versions in > this set of experiments. The IESG did not say something like "SPF and Sender-ID supported use of the same policy statement with different semantics". That sounds much closer to "Sender-ID supported use of the same policy statement defined by SPF" to me. If the group wants to stick closely to what the IESG at the time said, then, looping back to my original point about Barry's comment: > OLD > > Due to the absence of consensus behind one or the other, and because > Sender-ID supported use of the same policy statement defined by SPF, > the IESG at the time was concerned that an implementation of > Sender-ID might erroneously apply that statement to a message and, > depending on selected recipient actions, could improperly interfere > with message delivery. > > This seems to have a significant SPF bias. May I suggest this?: > > NEW > > Due to the absence of consensus behind one or the other and because > SPF and Sender-ID supported use of the same policy statement with > different semantics, the IESG at the time was concerned that > implementations of SPF or Sender-ID might erroneously apply a > statement that had been published with the semantics of the other, > and, depending on selected recipient actions, could improperly > interfere with message delivery. Murray's text (labeled "OLD" here) very closely reflects what the IESG said and not any kind of bias, but whatever the group wants is fine by me. Scott K From hsantos@isdg.net Mon Apr 23 04: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 B431E21F86DB for ; Mon, 23 Apr 2012 04:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6Ntcd56qZXQ for ; Mon, 23 Apr 2012 04:53:49 -0700 (PDT) Received: from listserv.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 831C821F86D1 for ; Mon, 23 Apr 2012 04:53:49 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2434; t=1335182027; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=n3W0JAX3iY/s9wSsYSJiFh5ROV8=; b=WQD7rYa7nQl6JMqO5tTB xI/fcZfehOFT5q94pLryGWLxH2lHFI1tC2rwRFsOg/6ArZ+FjPNI8TTKDvJEKxUm QmzinS+lEiM+NQiCKFddKmbR/y34xhT7hbkYM1lmMLFUUyqsgNxzOKJDy+28a7Yz eV2qWTrsAaNUwx05PSV5Enw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 23 Apr 2012 07:53: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4088844335.34908.2680; Mon, 23 Apr 2012 07:53:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2434; t=1335181686; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4Ojlcpu QJ2KLsNnem0bLlG91kkr81BKoqeCUiI4is70=; b=fjSi7amDG9b3lKPqq2fNgQr XytjFabasiF5uqRY2o6XuAcsLiUeC6mEnAY73suxZAcwGyMnG97AFme5oTJIiPj9 UTj9j4aeodPM3I3VG9lfL921qClKhNJGquARxbHpghVXzG2v+SeoKP0XPD2mTEQ+ GSIb0Em6ARWHm65DgUG8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 23 Apr 2012 07:48:06 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 392774612.2930.460; Mon, 23 Apr 2012 07:48:05 -0400 Message-ID: <4F954297.6010003@isdg.net> Date: Mon, 23 Apr 2012 07:52: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" References: <20120423100752.GQ99904@verdi> <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> In-Reply-To: <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:53:50 -0000 Scott Kitterman wrote: > Snip. > > That's all true, but not, I think relevant to the question of record reuse. There was consensus > in MARID that reuse of SPF records for Sender ID PRA assessments was technically inappropriate. Inappropriate in what way was not always agreed. > I don't think it's correct to apply words about the MARID shutdown to changes that were made later. As an active participant before marid, during marid and after marid, and maybe because my perspective of how all these ideas can work together, my assessment was much different. I didn't see precisely what the SPF v1.0 group were concern about, but then again at the time, I still had a hard time seeing how the PRA would address the #1 key concern where SPF broke down - path independent. After all, that is what gave birth to the other proposals and it was the MARKETING reason presented in the news rags. Putting aside all subjective politics, the technical problems when CEP was presented with its PRA concept: - XML format for DNS records, - PAYLOAD PRA defeated the high focus with SMTP IP and Envelope methods to address the accept bounce issue, The PAYLOAD/PRA concerned was resolved with the SUBMITTER idea. And I believe it was pretty clear we didn't want to add more DNS overhead with XML records and processing, it didn't seem this will help make it a standard and there was also high interest to consider the new thing - a new RR type. Considering, over 80% of the use cases did not require the PRA, IMO, it was technically appropriate to consider getting rid of the XML format and used a single source language to covered both. The claim that there was potential for errors seems to be based on the idea that implementators and publishers would do it wrong - not that the protocols were incorrect because they were both technically distinct with a tag. I didn't get that part of it, and FWIW, I felt that it could be integrated smoothly without problems. Waste? Perhaps. Lower use cases? Perhaps. But to me, it was more did PRA help (not cure) with the SPFv1.0 path problem that was the #1 criticism it had. I just feel if the SPFBIS focus was on the integrated experiment question which would include resolving the DNS record conflict claims, then there would be a different set of interest. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From dotzero@gmail.com Mon Apr 23 05:58: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 BC37B21F84E4 for ; Mon, 23 Apr 2012 05:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0q0sdtCV2B7 for ; Mon, 23 Apr 2012 05:58:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50CF021F849B for ; Mon, 23 Apr 2012 05:58:00 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so3854324pbb.31 for ; Mon, 23 Apr 2012 05:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lforEDMHdw/dEm/xzYofEPSzJ8cIWdyer6GvEnzmiyM=; b=btW7XqvMety2gpd5FxwSGEXxmC7aV4IdPlUrXKn3MX4dF0dmEV20SLp+oDFDoPT9Nu SdN5h1LoGWBrFz8ihX27cGj8cKACOoLz7hwZbtsTWDeR94A2oMeo1UQp7I3Da8zbN+1T +HnigE+X3qPPSvJG0aG03WC+UMVTM9OWcHkL2tNNL3YciC7w4sl6KFPvzBero4u/mFv5 Eh3vNZFFJC39hi7V8FRSy5dN5u/PGu/LiNv8lcmsMBtXCPw+mdtdTrYzOH1h/coWLL/p 4KmOthVB5M/kg/BsXHu2cDvqvjrSC/9zxMfcYLkIjiUH1PSKa8URHjqOGmW8PeXqHjfz dMkw== MIME-Version: 1.0 Received: by 10.68.218.198 with SMTP id pi6mr36249206pbc.121.1335185879988; Mon, 23 Apr 2012 05:57:59 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Mon, 23 Apr 2012 05:57:59 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> Date: Mon, 23 Apr 2012 08:57:59 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 12:58:00 -0000 On Sun, Apr 22, 2012 at 11:40 PM, Murray S. Kucherawy w= rote: > Comments inline (alas): > > > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of > Barry Leiba > Sent: Sunday, April 22, 2012 1:58 PM > To: spfbis@ietf.org > Subject: [spfbis] Review of draft-ietf-spfbis-experiment-05 > > > > OLD > > =A0 =A03. =A0Although the two mechanisms often used different email addre= sses > > =A0 =A0 =A0 =A0as the subject being evaluated, no data collected showed a= ny > > =A0 =A0 =A0 =A0substantial operational benefit (e.g., cheaper processing, > > =A0 =A0 =A0 =A0improved accuracy) to using Sender-ID over SPF. > > > > I suggest "to using either mechanism over the other." > > > [MSK: I don=92t think that=92s correct.=A0 Sender ID has a substantially = higher > processing cost given that it requires accepting the DATA part of the > message and has an obviously higher cost to extract the various identifie= rs > the PRA algorithm considers.=A0 SPF, purely compute-wise, is cheaper. > However, their accuracy is comparable. =A0If we want to be clear, we can = say > their accuracies are about the same, but SPF is operationally cheaper.] > > > > Murray, It is absolutely incorrect to say that their accuracies are about the same. I can consistently game PRA to get a neutral outcome regardless of what the originating domain publishes in it's record. If there is a Sender field then that is the PRA per the spec. I cannot do the the same for SPF. From ajs@anvilwalrusden.com Mon Apr 23 07:26: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 53B4521F868A for ; Mon, 23 Apr 2012 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0bhItvHEPiu for ; Mon, 23 Apr 2012 07:26:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C4BBF21F8623 for ; Mon, 23 Apr 2012 07:26:56 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id F267C1ECB41C for ; Mon, 23 Apr 2012 14:26:55 +0000 (UTC) Date: Mon, 23 Apr 2012 10:26:54 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120423142646.GE55520@mail.yitter.info> References: <16903045.7Ta8mtnNKj@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FED45@exch-mbx901.corp.cloudmark.com> <2738361.74YB1Lktta@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2738361.74YB1Lktta@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:26:57 -0000 No hat. On Mon, Apr 23, 2012 at 12:02:55AM -0400, Scott Kitterman wrote: > > Facts are not bias. Wanting to sweep them under the rug is bias. What I am > asking for is the exact opposite of bias. This doesn't respond to Murray's question of relevance. It might be that there were a large number of people unwittingly pulled into an experiment when the publication decisions were made. That does not help us in any way to determine the relative uptake of the different technologies. The document is about the results of the experiment, to the extent there was one, and not about the conditions of the experiment as such. Quite frankly, if we had to do an evaluation of this as an experiment, we would have to criticise the experimental design in many ways, and the accidental pollution of the sample base is the least of the problems. But that's not what we're trying to do. So, without discussing the factuality of the claims, why are they relevant? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Apr 23 07:30: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 EC1A021F849C for ; Mon, 23 Apr 2012 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcZ16HwQQAPf for ; Mon, 23 Apr 2012 07:30:44 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6216A21F8497 for ; Mon, 23 Apr 2012 07:30:44 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id B34041ECB41C for ; Mon, 23 Apr 2012 14:30:43 +0000 (UTC) Date: Mon, 23 Apr 2012 10:30:42 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120423143037.GF55520@mail.yitter.info> References: <20120423100752.GQ99904@verdi> <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Moderator note (was: Review of draft-ietf-spfbis-experiment-05) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:30:45 -0000 Moderator note. On Mon, Apr 23, 2012 at 06:50:06AM -0400, Scott Kitterman wrote: > reuse. There was consensus in MARID that reuse of SPF records for We are not going to debate on this list whether there was or was not consensus in MARID on anything. Thank you. A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Mon Apr 23 07:34: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 E814121F866D for ; Mon, 23 Apr 2012 07:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSoEVIuzcY26 for ; Mon, 23 Apr 2012 07:34:05 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 12BE421F8666 for ; Mon, 23 Apr 2012 07:34:05 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1Sa41j0010ZaKgw01Sa472; Mon, 23 Apr 2012 07:34:04 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=-GmIE1zMRuB1fiFNIq0A:9 a=NJetClNIaKjXGwQwfxsA:7 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 07:34:04 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anwbsggAETc4D//6ThEA== Date: Mon, 23 Apr 2012 14:34:03 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335191644; bh=WSyp2GV8gKJjzJZRoc5e966hzcCpSVHVSD6nRUsdB1c=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=u0Ss2ZZBn+yf8Yvk21Pz7wg2w3yo26rh44wMC8RQDMOZkf2sFU+s4MgTI4LqIMqlH JwehZ03A/x057zokGr1k4tKHfm5cAMfJN5qxPXs4Nra8swsRiA32z3W8i/knqsy38I 1AXo+IX/8zTtVdNTelMTrKE9jg/896KAl9VJCwPs= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:34:06 -0000 > -----Original Message----- > From: Dotzero [mailto:dotzero@gmail.com] > Sent: Monday, April 23, 2012 5:58 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > It is absolutely incorrect to say that their accuracies are about the > same. I can consistently game PRA to get a neutral outcome regardless > of what the originating domain publishes in it's record. If there is a > Sender field then that is the PRA per the spec. I cannot do the the > same for SPF. Based on the data collected about actual live mail streams, SPF and Sender = ID reach the same pass/fail conclusion about messages at least 80%, and as = much as 95%, of the time. Do you have different data? We're specifically not doing a comparison of the weaknesses of the two. We= 're only citing empirical data. -MSK From spf2@kitterman.com Mon Apr 23 07:52: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 CF3CD21F85D6 for ; Mon, 23 Apr 2012 07:52:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hLXbziCHSt8 for ; Mon, 23 Apr 2012 07:51:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6FF21F85A7 for ; Mon, 23 Apr 2012 07:51:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9CC5C20E40E3; Mon, 23 Apr 2012 10:51:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335192713; bh=mvFvTPu/WBhV6JKCM1G3FU0q4HyOfjFtDVa7uWY3+jI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TlOk7teukrsymW12oFqRJ+RCFg5ecRuuNVQpmDDXFyZd4Wt3SVkZaRm6eSTfVTOJ8 Ba81zKtP8GYcFDb2BhtDXBdrY2bVrcOfiAteOMWFoZaEhF7JBt9D78RX6qIEQMJgtx 40vEwWBgl+999s2xmJT98cgHlOdOPh7HOBKqGtiI= Received: from scott-latitude-e6320.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 ESMTPSA id 7F11820E408E; Mon, 23 Apr 2012 10:51:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Apr 2012 10:51:49 -0400 Message-ID: <3365685.ptXhF5PY8S@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120423142646.GE55520@mail.yitter.info> References: <2738361.74YB1Lktta@scott-latitude-e6320> <20120423142646.GE55520@mail.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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:52:01 -0000 On Monday, April 23, 2012 10:26:54 AM Andrew Sullivan wrote: > No hat. > > On Mon, Apr 23, 2012 at 12:02:55AM -0400, Scott Kitterman wrote: > > Facts are not bias. Wanting to sweep them under the rug is bias. What I > > am asking for is the exact opposite of bias. > > This doesn't respond to Murray's question of relevance. > > It might be that there were a large number of people unwittingly > pulled into an experiment when the publication decisions were made. > That does not help us in any way to determine the relative uptake of > the different technologies. > > The document is about the results of the experiment, to the extent > there was one, and not about the conditions of the experiment as such. > Quite frankly, if we had to do an evaluation of this as an experiment, > we would have to criticise the experimental design in many ways, and > the accidental pollution of the sample base is the least of the > problems. But that's not what we're trying to do. > > So, without discussing the factuality of the claims, why are they > relevant? I think it's highly relevant to how the data on usage is interpreted. Scott K From ajs@anvilwalrusden.com Mon Apr 23 07:59: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 6570921F86B5 for ; Mon, 23 Apr 2012 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCpbp0nkgcKN for ; Mon, 23 Apr 2012 07:59:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF121F86C1 for ; Mon, 23 Apr 2012 07:59:53 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 51E221ECB41C for ; Mon, 23 Apr 2012 14:59:53 +0000 (UTC) Date: Mon, 23 Apr 2012 10:59:51 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120423145947.GH55520@mail.yitter.info> References: <2738361.74YB1Lktta@scott-latitude-e6320> <20120423142646.GE55520@mail.yitter.info> <3365685.ptXhF5PY8S@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3365685.ptXhF5PY8S@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:59:56 -0000 No hat. On Mon, Apr 23, 2012 at 10:51:49AM -0400, Scott Kitterman wrote: > I think it's highly relevant to how the data on usage is interpreted. How? I don't see it. If you're arguing for inclusion, the burden of proof is on you. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Mon Apr 23 08: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 86CD921F86D7 for ; Mon, 23 Apr 2012 08:00:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb5NJhT5dzFd for ; Mon, 23 Apr 2012 08:00:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2C41D21F86E8 for ; Mon, 23 Apr 2012 08:00:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8E14120E40E3; Mon, 23 Apr 2012 11:00:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335193223; bh=8eNNZx6carWwUQQLqxr4Dm36uPWCSr6B7iiHQikCtak=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=dtyNbkymZmSB4JQt/p8tkHQFYG9+vFtyMR2bWXKzqiR67SJtAfo07ZbvIa+qdKKlJ mZWIh4cma6fG+u1Ye11iSJMmmlx2VF69C2MvHJy40XB2u6T/+Upf3tyoXSI/A1kJjQ 5JzAxzSj8TfoGrOYEucLxu1/viPiHfMie33ZxejQ= Received: from scott-latitude-e6320.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 ESMTPSA id 819F020E408E; Mon, 23 Apr 2012 11:00:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Apr 2012 11:00:23 -0400 Message-ID: <1929165.QqZ6YMCCuh@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120423143037.GF55520@mail.yitter.info> References: <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> <20120423143037.GF55520@mail.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] Moderator note (was: Review of draft-ietf-spfbis-experiment-05) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:00:26 -0000 On Monday, April 23, 2012 10:30:42 AM Andrew Sullivan wrote: > Moderator note. > > On Mon, Apr 23, 2012 at 06:50:06AM -0400, Scott Kitterman wrote: > > reuse. There was consensus in MARID that reuse of SPF records for > > We are not going to debate on this list whether there was or was not > consensus in MARID on anything. As long as we equally don't debate what was in the IESG/directorate's minds when they shut down MARID, I think that's wonderful. Scott K From spf2@kitterman.com Mon Apr 23 08:00: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 ADB3F21F85AE for ; Mon, 23 Apr 2012 08:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zhNsLHpha-p for ; Mon, 23 Apr 2012 08:00:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C3FBF21F859F for ; Mon, 23 Apr 2012 08:00:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 499A820E40E3; Mon, 23 Apr 2012 11:00:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335193256; bh=WtEDk0B2CdtkerpShPCDlcKI9qmvv9zFWPZ3HQDWqOs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TLERNkRjBPpOzJn2HY69s8fEz7TJmbssEB5L8aGpk2KakRZ2HJY8L6Ix/lXeB9Jwy G3OGWByfkeZBFnJ9niL9QztT25O+g57r6wBg9JOBxyLurAHjq1E3abSYQZh+q6akKP szEW1N6OX4AfDxNY9y1eCA6fbIQERwqDs42lUWN0= Received: from scott-latitude-e6320.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 ESMTPSA id 3DE6F20E408E; Mon, 23 Apr 2012 11:00:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Apr 2012 11:00:56 -0400 Message-ID: <63583111.FeGGmhBaS4@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120423145947.GH55520@mail.yitter.info> References: <3365685.ptXhF5PY8S@scott-latitude-e6320> <20120423145947.GH55520@mail.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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:00:58 -0000 On Monday, April 23, 2012 10:59:51 AM Andrew Sullivan wrote: > No hat. > > On Mon, Apr 23, 2012 at 10:51:49AM -0400, Scott Kitterman wrote: > > I think it's highly relevant to how the data on usage is interpreted. > > How? I don't see it. If you're arguing for inclusion, the burden of > proof is on you. No. I'm arguing that the current text remain. Scott K From ajs@anvilwalrusden.com Mon Apr 23 08:08: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 BE68221F85E1 for ; Mon, 23 Apr 2012 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R2DG12JhRYf for ; Mon, 23 Apr 2012 08:08:08 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 48EC921F85DB for ; Mon, 23 Apr 2012 08:08:08 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 901FC1ECB41C for ; Mon, 23 Apr 2012 15:08:07 +0000 (UTC) Date: Mon, 23 Apr 2012 11:08:05 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120423150800.GK55520@mail.yitter.info> References: <84f787db-1601-47e5-a8e4-2d3301e12b11@email.android.com> <20120423143037.GF55520@mail.yitter.info> <1929165.QqZ6YMCCuh@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1929165.QqZ6YMCCuh@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Moderator note (was: Review of draft-ietf-spfbis-experiment-05) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:08:08 -0000 On Mon, Apr 23, 2012 at 11:00:23AM -0400, Scott Kitterman wrote: > As long as we equally don't debate what was in the IESG/directorate's minds > when they shut down MARID, I think that's wonderful. I fully agree, although we do have statements from the IESG. Particularly, we have the IESG notes on the published documents, which stated that there was no technical consensus. Since those are notes from the IESG, we can correctly read it as making a claim about the judgement of the IESG at the time of publication. But going any further is a bad idea, I very strongly agree. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dotzero@gmail.com Mon Apr 23 08:13: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 D64FC21F8714 for ; Mon, 23 Apr 2012 08:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILfp4CekZkU3 for ; Mon, 23 Apr 2012 08:13:36 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4125C21F8682 for ; Mon, 23 Apr 2012 08:13:36 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so4007078pbb.31 for ; Mon, 23 Apr 2012 08:13: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=NwjXlWjs1Ryt8DBtZlmqjh4k9SLjr1kZy8IXYBJuq6c=; b=e8WLRAOzLzgMqcKiyhqfEKgl6J1CoX2z8S13Bhb8OV39dEEOtX8PZTZ5EzHBTwwpNE OUKBQcWIMHKtxUC6Oa1t3H4zIszfWq2pj+psNYyg3h1KpHzKkplPniVJxQvUzaq2CysI tBBuOSCud5NOkdNuwDESJGhQG7NnCsI0f7cSB9UA+0g7Vh3N49zpIwhKfPgk0bjcPVrk XdRPYLT/P4X1AWhCtejm31BX/w4pFOkL/pTqV88BcEi/Uedx7hIXFxRsAhpOFYdevTH1 ysgoWBV+ADBQq9tmn4QR/wNVw3URwx3uIH7vw3AT5SjwAVSO8gP+XjjIQbxOxPQ2rwYA NBXg== MIME-Version: 1.0 Received: by 10.68.229.73 with SMTP id so9mr31418086pbc.163.1335194016015; Mon, 23 Apr 2012 08:13:36 -0700 (PDT) Received: by 10.68.217.105 with HTTP; Mon, 23 Apr 2012 08:13:35 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> Date: Mon, 23 Apr 2012 11:13:35 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:13:37 -0000 On Mon, Apr 23, 2012 at 10:34 AM, Murray S. Kucherawy w= rote: >> -----Original Message----- >> From: Dotzero [mailto:dotzero@gmail.com] >> Sent: Monday, April 23, 2012 5:58 AM >> To: Murray S. Kucherawy >> Cc: spfbis@ietf.org >> Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >> >> It is absolutely incorrect to say that their accuracies are about the >> same. I can consistently game PRA to get a neutral outcome regardless >> of what the originating domain publishes in it's record. If there is a >> Sender field then that is the PRA per the spec. I cannot do the the >> same for SPF. > > Based on the data collected about actual live mail streams, SPF and Sende= r ID reach the same pass/fail conclusion about messages at least 80%, and a= s much as 95%, of the time. =A0Do you have different data? > > We're specifically not doing a comparison of the weaknesses of the two. = =A0We're only citing empirical data. > You stated that their accuracies are comparable. Given the known weakness of PRA (based on emperical data/testing), that is an incorrect statement. The whole point of SPF (and presumably SIDF) is to mitigate abuse. You have not provided complete details about the dataset you are referring to so it is hard to draw detailed conlusions regarding key points: 1) What percentage of the dataset does not have a Sender field? 2) For data points where there is a Sender field, what percentage of those data points have a Sender field that is aligned with the Mail >From (and conceivably From)? 3) What percentage of the messages were "abusive"? Would the mail stream selected be a likely target for the particular type of abuse I am pointing out? If not, why would you expect to see this particular type of abuse? 4) To what extent is the dataset representative of the mail streams that various types and sizes of receivers might receive? That is, is the dataset truly representative or are there potential issues with self selection, etc? From sm@elandsys.com Mon Apr 23 08:54: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 5F72121F8758 for ; Mon, 23 Apr 2012 08:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4irmifPEaf3 for ; Mon, 23 Apr 2012 08:54:52 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E34C221F8755 for ; Mon, 23 Apr 2012 08:54:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.236]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3NFsZ0C026570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 08:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335196488; i=@elandsys.com; bh=O4D4b53VYL6+YLSvv8j/64tHOxrnByEwiCwugEp0swk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UPglki1Hb9+br8vTFrSyFVhOQaGzwd0C5IjwNjSsL/WQR8R/FPuMm3nyqkLQNE3Dw TV4j2t8pWeeOCeFlOzCiow2mP/4HFaNZmWVg2T2SG0PraNOKtqbmwV+nNwrzBhL/cn EEvztAGmZnnvGsIKAG1ZA7ydZDHqgpZgPHDwFmog= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335196488; i=@elandsys.com; bh=O4D4b53VYL6+YLSvv8j/64tHOxrnByEwiCwugEp0swk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ND5WSpveixX2V2rLwjyjhZO/W+Mf019RrLrd4zCKUpKDvBLpb+/L4uifR3KTn5LYg rhIc0BPX3J9haZcEFM03t57cGAzRTPpnXRUoJiT9/sowWkZYBM3JkFN9mrTL8Qd0G2 PbYscEGeWYJ14FySV9BZK/bHnjbsLE1EIKdSh/tA= Message-Id: <6.2.5.6.2.20120423083219.0633a548@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Apr 2012 08:35:55 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4F953EE1.50600@tana.it> References: <6.2.5.6.2.20120422160923.09940d30@elandnews.com> <4F953EE1.50600@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #10 on Received-SPF deprecation, was IETF83 SPFBIS minutes - Version 0.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:54:54 -0000 Hi Alessandro, At 04:37 23-04-2012, Alessandro Vesely wrote: >What I meant to say is that it is the servers who should deprecate >Received-SPF, so that their clients stop checking it and check >Authentication-Results instead. That is, 4408bis can recommend that >servers deprecate the old field while they add the new. I'll go over the audio again before making the correction you suggested. >Is it me or "server" and "client" were meant w.r.t. the header field >usage, rather than SMTP? See above. >There are no arguments for _not_ deprecating ;-) Ok. We won't have to spend more time on this issue if everyone agrees to the above. Please note that it is appropriate to suggest corrections to the minutes through this mailing list if you believe that it does not reflect what was discussed during the meeting. Regards, S. Moonesamy From barryleiba.mailing.lists@gmail.com Mon Apr 23 09:13: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 CECAC21F872B for ; Mon, 23 Apr 2012 09:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgnv-UkfEdig for ; Mon, 23 Apr 2012 09:13:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18FD221F8725 for ; Mon, 23 Apr 2012 09:13:57 -0700 (PDT) Received: by ghbg16 with SMTP id g16so7224004ghb.31 for ; Mon, 23 Apr 2012 09:13: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=Zol7pD5IlW2IdRwMMQ40AJcKrldxCtE1tTtOwJlxm/4=; b=RlyMNxtn5eHV54DOptecqpK8Q/rNTDEy+sUmOZFQTVQfFQrdO8UGTECq0rUMUJuUvs XZaG/WLJZyS7IKmFE0b7MTI8cBldbFYooFZCd0jTKYsYiqegBhPYudgdHKpGZD8IuD6x B+l+ShKiSEXEsQPvXdNR1UrnlntKwtQdtjoSXfOSZWuOAyxQlASYptb/rlJAdXVOhgjF z2/r5Vo49y51dwSoM5+wXmTlM/8snkkx5JLBTBXRh9TJNg1BFd2lDJwob1HCEaaU+HCG ycsxBE+nHs6CWKecDYqt3HpZrPmqQyi3LhbIIklJbTWFu8pTX9+GsIZnsmtL2ZBTcQK6 m1FQ== MIME-Version: 1.0 Received: by 10.101.58.1 with SMTP id l1mr4677024ank.67.1335197636706; Mon, 23 Apr 2012 09:13:56 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.152.14 with HTTP; Mon, 23 Apr 2012 09:13:56 -0700 (PDT) In-Reply-To: <63583111.FeGGmhBaS4@scott-latitude-e6320> References: <3365685.ptXhF5PY8S@scott-latitude-e6320> <20120423145947.GH55520@mail.yitter.info> <63583111.FeGGmhBaS4@scott-latitude-e6320> Date: Mon, 23 Apr 2012 12:13:56 -0400 X-Google-Sender-Auth: aAoG0gyBvowHyuvoPqRq2U_I1yA Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: multipart/alternative; boundary=001636eee35ad7438504be5aeccc Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:13:57 -0000 --001636eee35ad7438504be5aeccc Content-Type: text/plain; charset=ISO-8859-1 > I'm arguing that the current text remain. Scott is right that because what's there has rough consensus, he does not need to establish consensus to leave it there. That said, I think the current text ill-serves the document, so let me try again. How about this, which I think does not attempt to attribute anything but the Experimental requirement to the old IESG: OLD Due to the absence of consensus behind one or the other, and because Sender-ID supported use of the same policy statement defined by SPF, the IESG at the time was concerned that an implementation of Sender-ID might erroneously apply that statement to a message and, depending on selected recipient actions, could improperly interfere with message delivery. As a result, the IESG required the publication of all of these documents as Experimental, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication in order to determine a reasonable path forward. NEW Consensus did not clearly support one protocol over the other, and there was significant concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents as Experimental, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication in order to determine a reasonable path forward. Does that work? I think it says what it needs to say without trying to either blame anyone or get into historical details that are not necessary in this document. Barry --001636eee35ad7438504be5aeccc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I'm arguing that the c= urrent text remain.

Scott is right that because wh= at's there has rough consensus, he does not need to establish consensus= to leave it there.

That said, I think the current text ill-serves the docu= ment, so let me try again. =A0How about this, which I think does not attemp= t to attribute anything but the Experimental requirement to the old IESG:

OLD
=A0 =A0Due to the absence of consensus be= hind one or the other, and because
=A0 =A0Sender-ID supported use= of the same policy statement defined by SPF,
=A0 =A0the IESG at = the time was concerned that an implementation of
=A0 =A0Sender-ID might erroneously apply that statement to a message a= nd,
=A0 =A0depending on selected recipient actions, could imprope= rly interfere
=A0 =A0with message delivery. =A0As a result, the I= ESG required the
=A0 =A0publication of all of these documents as Experimental, and requ= ested
=A0 =A0that the community observe deployment and operation = of the protocols
=A0 =A0over a period of two years from the date = of publication in order to
=A0 =A0determine a reasonable path forward.

N= EW
=A0 =A0Consensus did not clearly support one protocol over the= other, and
=A0 =A0there was significant concern that the two wou= ld conflict in some
=A0 =A0significant operational situations, interfering with message de= livery.
=A0 =A0The IESG required the publication of all of these = documents as
=A0 =A0Experimental, and requested=A0that the community observe deployment
=A0 =A0and operation of the pro= tocols=A0over a period of two= years from the date
=A0 =A0of publication in order to=A0determine a reasonable path forward.

Does that work? =A0I think it says what it = needs to say without trying to either blame anyone or get into historical d= etails that are not necessary in this document.

Barry
 --001636eee35ad7438504be5aeccc-- From barryleiba@gmail.com Mon Apr 23 09: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 973F321F8742 for ; Mon, 23 Apr 2012 09:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mx4Ql9htoaf for ; Mon, 23 Apr 2012 09:19:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5FA21F8738 for ; Mon, 23 Apr 2012 09:19:32 -0700 (PDT) Received: by yhkk25 with SMTP id k25so7211582yhk.31 for ; Mon, 23 Apr 2012 09:19:32 -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=GLkAyxfqDckR1us1FQ4TNhJH758g/n8584y0Qgc+CUY=; b=K3K5Zd6w2lc9t7IyZRbNk1b952ssyE6NnwBkNWv7DjhB/j7J8z+En6+prmCTiQFMqm FIXSnpfph4Knv+MUR3zvTat/Q0zde3Cf1jfzvau3pEHEGN63VL/gxLrsDDFTuFO3Y3li GIIZ1SfQufxRzL7glCXxns9KCwdQyYmtXhtWPAN6E0sAMTG4gVhRjffeuXps7/NqJXhY mPFI8j2N1s1DqVezenDlF83gkyKUElhsIZx+Uuax4FXafvReixwsADI6NM2AJ1lJa1Xr F0AHGWDtvHUndM7So1KJwaCoBmT5R23wq8erY3Qbk0Cme7LGvS4XSGc80EHvASySDCRN 5KXg== MIME-Version: 1.0 Received: by 10.60.11.166 with SMTP id r6mr8748941oeb.2.1335197972498; Mon, 23 Apr 2012 09:19:32 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Mon, 23 Apr 2012 09:19:32 -0700 (PDT) In-Reply-To: <4F947B8D.2000008@gmail.com> References: <4F947B8D.2000008@gmail.com> Date: Mon, 23 Apr 2012 12:19:32 -0400 X-Google-Sender-Auth: mikmKB_BEX-ruC9xx_PUNVpomHA Message-ID: From: Barry Leiba To: "dcrocker@bbiw.net" Content-Type: multipart/alternative; boundary=e89a8fb20228db099c04be5b00ec Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:19:33 -0000 --e89a8fb20228db099c04be5b00ec Content-Type: text/plain; charset=ISO-8859-1 > Still, in the sense that we use it > here, references that are central to the understanding of the document > at hand are usually considered to be normative. DNS is arguable, but > I'd say no. I think the references to PRA, SENDER-ID, SPF, and > SUBMITTER are normative. You think that SPF or Sender ID could function without the DNS specification??? That is, what is it you think might be arguable about classing it as a normative reference? [Barry] No. I'm saying that you need to understand SPF, etc, to understand this doc, but you probably don't need to understand DNS to understand this doc. Normativity isn't transitive. That said, because there is talk in here about the RR types, I'm happy if we also say that DNS is a normative reference. I'm not happy to have the RFC 440x docs NOT be normative. Barry --e89a8fb20228db099c04be5b00ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Still, in the sense that w= e use it
> here, references that are central to the understand= ing of the document
> at hand are usually considered to be nor= mative. =A0DNS is arguable, but
> I'd say no. =A0I think the references to PRA, SENDER-ID, SPF,= and
> SUBMITTER are normative.

You t= hink that SPF or Sender ID could function without the DNS specification??? = =A0That is, what is it you think might be arguable about classing it as a n= ormative reference?

[Barry] =A0No. =A0I'm saying that you need to under= stand SPF, etc, to understand this doc, but you probably don't need to = understand DNS to understand this doc. =A0Normativity isn't transitive.=

That said, because there is talk in here about the RR t= ypes, I'm happy if we also say that DNS is a normative reference. =A0I&= #39;m not happy to have the RFC 440x docs NOT be normative.

Barry
 --e89a8fb20228db099c04be5b00ec-- From WebMaster@Commerco.Net Mon Apr 23 11:10: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 59D1421F863D for ; Mon, 23 Apr 2012 11:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmUTAKL58UPs for ; Mon, 23 Apr 2012 11:10:48 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id CA6D121F858F for ; Mon, 23 Apr 2012 11:10:48 -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=AnSCDGmXmBCN+OcPigBksUfZYpQFcvMVJ2vy3ovHXvabquJzbm9UNL3yDMWpJvsrtmYWKxAYeatJemVVTKI5NvbjzRKBJ14+gTTpXXNz5wjy46YnIHoEsJPBuHGu+BGFveF+t2gmkLx3nDvUkbo/VzFzw7/BVhgG59krMpQeYDI= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Mon, 23 Apr 2012 18:10:45 +0000 Message-ID: <4F959B1F.6020007@Commerco.Net> Date: Mon, 23 Apr 2012 12:10:39 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <3365685.ptXhF5PY8S@scott-latitude-e6320> <20120423145947.GH55520@mail.yitter.info> <63583111.FeGGmhBaS4@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:10:55 -0000 On 4/23/2012 10:13 AM, Barry Leiba wrote: >> I'm arguing that the current text remain. > > Scott is right that because what's there has rough consensus, he does > not need to establish consensus to leave it there. > > That said, I think the current text ill-serves the document, so let me > try again. How about this, which I think does not attempt to attribute > anything but the Experimental requirement to the old IESG: > > OLD > Due to the absence of consensus behind one or the other, and because > Sender-ID supported use of the same policy statement defined by SPF, > the IESG at the time was concerned that an implementation of > Sender-ID might erroneously apply that statement to a message and, > depending on selected recipient actions, could improperly interfere > with message delivery. As a result, the IESG required the > publication of all of these documents as Experimental, and requested > that the community observe deployment and operation of the protocols > over a period of two years from the date of publication in order to > determine a reasonable path forward. > > NEW > Consensus did not clearly support one protocol over the other, and > there was significant concern that the two would conflict in some > significant operational situations, interfering with message delivery. > The IESG required the publication of all of these documents as > Experimental, and requested that the community observe deployment > and operation of the protocols over a period of two years from the date > of publication in order to determine a reasonable path forward. > > Does that work? I think it says what it needs to say without trying to > either blame anyone or get into historical details that are not > necessary in this document. > > Barry > New looks cleaner. Would it be possible (and does it make sense) to add something like - "Measurement data gathered for both the Sender-ID and SPF experiments indicate SPF adoption levels in the community as the preferred protocol, thus offering the reasonable path forward." - to the end of the paragraph? Alan M. From spf2@kitterman.com Mon Apr 23 12:08: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 8525121E8026 for ; Mon, 23 Apr 2012 12:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByPLUOk+UV3x for ; Mon, 23 Apr 2012 12:08:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BA7BD21E801B for ; Mon, 23 Apr 2012 12:08:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 121BB20E40E9; Mon, 23 Apr 2012 15:08:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335208090; bh=O2NNlqmuPEfbVGi+M4SG4zJWSX6ycx9nR48HYzq4R9I=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=R/LeASBXghXh26qeHqhCfYdwF2jQZo689qLJ2WADuQT2rxYcjgvxYXht17YAJYmoE b8aJfKRjxGZBdQhqW5Q1Cc+oevzDGWJUkCGXl0ATvJiXrwilYX9Y8jFgvID5fiypAv WnHSLDxEW424efKISHn0s5hm+Yerc0+79xb7jvy8= Received: from scott-latitude-e6320.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 ESMTPSA id E87C520E40E3; Mon, 23 Apr 2012 15:08:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Apr 2012 15:08:09 -0400 Message-ID: <1663186.LKXEFjErpA@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: References: <63583111.FeGGmhBaS4@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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:08:11 -0000 On Monday, April 23, 2012 12:13:56 PM Barry Leiba wrote: > > I'm arguing that the current text remain. > > Scott is right that because what's there has rough consensus, he does not > need to establish consensus to leave it there. > > That said, I think the current text ill-serves the document, so let me try > again. How about this, which I think does not attempt to attribute > anything but the Experimental requirement to the old IESG: > > OLD > Due to the absence of consensus behind one or the other, and because > Sender-ID supported use of the same policy statement defined by SPF, > the IESG at the time was concerned that an implementation of > Sender-ID might erroneously apply that statement to a message and, > depending on selected recipient actions, could improperly interfere > with message delivery. As a result, the IESG required the > publication of all of these documents as Experimental, and requested > that the community observe deployment and operation of the protocols > over a period of two years from the date of publication in order to > determine a reasonable path forward. > > NEW > Consensus did not clearly support one protocol over the other, and > there was significant concern that the two would conflict in some > significant operational situations, interfering with message delivery. > The IESG required the publication of all of these documents as > Experimental, and requested that the community observe deployment > and operation of the protocols over a period of two years from the date > of publication in order to determine a reasonable path forward. > > Does that work? I think it says what it needs to say without trying to > either blame anyone or get into historical details that are not necessary > in this document. > > Barry I think it is biased towards Sender ID by pretending an equivalence that is incorrect, but it's not worth arguing over. Go ahead with it as far as I'm concerned. Scott K From spf2@kitterman.com Mon Apr 23 12:46: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 65F3521E8015 for ; Mon, 23 Apr 2012 12:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4jyjNEDHh+d for ; Mon, 23 Apr 2012 12:46:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8E21F84FB for ; Mon, 23 Apr 2012 12:45:59 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 391F820E40E9; Mon, 23 Apr 2012 15:45:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335210359; bh=bH3zeFRYbfk5OCHcJluGZ867hdwVRavPPnnKHj/1Q24=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ERqsj5Ybb5Up1gLCEhGcmnpuk7B33cj2AsoPI3GVzsiLREDKuCRlyGxGzHcwxn+OV xWcX2Dg6iFMD22JKbj2NMJ2fzSH20sUNMVjk6pHhQBau/j1l4a8GL3618K0DTE9Pns ut9NJKWlg0K7wkEzT8hoZSHzaZHFmwzuPMB2njUU= Received: from scott-latitude-e6320.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 ESMTPSA id 1DB9E20E40E3; Mon, 23 Apr 2012 15:45:58 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Apr 2012 15:45:58 -0400 Message-ID: <2620539.Fpf1xB4moR@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: References: <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:46:01 -0000 On Monday, April 23, 2012 11:13:35 AM Dotzero wrote: > On Mon, Apr 23, 2012 at 10:34 AM, Murray S. Kucherawy wrote: > >> -----Original Message----- > >> From: Dotzero [mailto:dotzero@gmail.com] > >> Sent: Monday, April 23, 2012 5:58 AM > >> To: Murray S. Kucherawy > >> Cc: spfbis@ietf.org > >> Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 > >> > >> It is absolutely incorrect to say that their accuracies are about the > >> same. I can consistently game PRA to get a neutral outcome regardless > >> of what the originating domain publishes in it's record. If there is a > >> Sender field then that is the PRA per the spec. I cannot do the the > >> same for SPF. > > > > Based on the data collected about actual live mail streams, SPF and Sender > > ID reach the same pass/fail conclusion about messages at least 80%, and > > as much as 95%, of the time. Do you have different data? > > > > We're specifically not doing a comparison of the weaknesses of the two. > > We're only citing empirical data. > You stated that their accuracies are comparable. Given the known > weakness of PRA (based on emperical data/testing), that is an > incorrect statement. The whole point of SPF (and presumably SIDF) is > to mitigate abuse. You have not provided complete details about the > dataset you are referring to so it is hard to draw detailed conlusions > regarding key points: > > 1) What percentage of the dataset does not have a Sender field? > 2) For data points where there is a Sender field, what percentage of > those data points have a Sender field that is aligned with the Mail > From (and conceivably From)? > 3) What percentage of the messages were "abusive"? Would the mail > stream selected be a likely target for the particular type of abuse I > am pointing out? If not, why would you expect to see this particular > type of abuse? > 4) To what extent is the dataset representative of the mail streams > that various types and sizes of receivers might receive? That is, is > the dataset truly representative or are there potential issues with > self selection, etc? Perhaps it would be enough to say that there isn't any evidence of accuracy improvement associated with the additional complexity of Sender ID? Scott K From hsantos@isdg.net Mon Apr 23 13:40: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 C294221F863B for ; Mon, 23 Apr 2012 13:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07pRUqYpPQRx for ; Mon, 23 Apr 2012 13:40:03 -0700 (PDT) Received: from ntbbs.santronics.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6314B21F8639 for ; Mon, 23 Apr 2012 13:40:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2719; t=1335213597; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=qZmWDnv0dhmV0zNci+N6bgCxlso=; b=pvMWUP1eiiVsK3fx2G7H TvH0jYnTB8qwpHsUaD5qWHAIr8GAJie/PTBJDTtg065NSZi4UQfcFB3T0dcPUDgN Ax3oHkwzyrPlgSOtbELyKY63ZwZUxq4p7p+Fq/Q25YsfI0UK+v5b1NkkjtLAfrrY Pnod6h2ldJKb9pygc5Jh2xE= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 23 Apr 2012 16:39:57 -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 v6.4.454.1) with ESMTP id 4120414804.34908.5072; Mon, 23 Apr 2012 16:39:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2719; t=1335213258; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ye8PxnI nM4tQC5W5S3h9JNf6FrfcHZErsipccwZcK/4=; b=j9gLdDQqlj5M/nSBnZBRMPw eBExVEhwUhTHKU+fhDEq1kKYPmZCJ/EuABTC+3vBkvfNvOz8XH5VpNhbBA4C0+cB 5qGNDCR/zmbkdwQlbTN8C5iu3T02Mvk0lKpNyIKqYoHtRmHynvKZTkBxC/qlYdCm 0p92gUkFV+eb7l4w7f1Y= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 23 Apr 2012 16:34:18 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 424346472.2968.6816; Mon, 23 Apr 2012 16:34:17 -0400 Message-ID: <4F95BDEB.2040002@isdg.net> Date: Mon, 23 Apr 2012 16:39:07 -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: <3365685.ptXhF5PY8S@scott-latitude-e6320> <20120423145947.GH55520@mail.yitter.info> <63583111.FeGGmhBaS4@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 20:40:04 -0000 Barry Leiba wrote: > NEW > Consensus did not clearly support one protocol over the other, and > there was significant concern that the two would conflict in some > significant operational situations, interfering with message delivery. > The IESG required the publication of all of these documents as > Experimental, and requested that the community observe deployment > and operation of the protocols over a period of two years from the date > of publication in order to determine a reasonable path forward. > > Does that work? I think it says what it needs to say without trying to > either blame anyone or get into historical details that are not necessary > in this document. I believe another approach for the report is to restructure the introduction outlining: 1) Restating the industry problem the protocols attempted address, 2) Summarize their goals and approaches, and 3) Summarize the concerns and conflicts. and allow the collection 6+ years of deployment experiences show if the original problem(s) was addressed with the goals and approaches and what were the concerns and conflicts. I also would include insight if any new industry solutions altered the goals and approaches and perhaps help resolve some of the conflicts and concerns. The latter point is not a focus of replacing, but how the deployment decisions was altered that may help explain the 6+ years deployment data. If there was a "bias" for lack of a better term, it was the advocates for a backend only solution versus a more complete and integrated total solution with all mail system components involved. Despite the extra complexity, this is what SenderID brought to the table as described in its intro: This document describes a mechanism such that receiving Mail Transfer Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents (MUAs) can recognize mail in the above category and take appropriate action. For example, an MTA might refuse to accept a message, an MDA might discard a message rather than placing it into a mailbox, and an MUA might render that message in some distinctive fashion. The conflict was not just cited DNS records between SPFv1 and SPFv2, but other considerations as well: - DNS record conflicts (SPFv1 vs SPFv2) - DNS optimization (considering new RR type) - PRA Payload concern (use of SUBMITTER) - Marking vs Rejection - both must have the same result/outcome for security reasons, - 4405 is more RFC2119 forceful with REJECT only than 4406, 4407 and 4408. - Helping users where the backend was yet compliant (or just marking it) -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From dotis@mail-abuse.org Mon Apr 23 14: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 88F8521F8555 for ; Mon, 23 Apr 2012 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdaCayhUU3jF for ; Mon, 23 Apr 2012 14:01:02 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id DC75B21F853F for ; Mon, 23 Apr 2012 14:01:02 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id F38AD17403F3 for ; Mon, 23 Apr 2012 21:01:01 +0000 (UTC) Message-ID: <4F95C30D.5070903@mail-abuse.org> Date: Mon, 23 Apr 2012 14:01:01 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:01:03 -0000 On 4/23/12 8:13 AM, Dotzero wrote: > On Mon, Apr 23, 2012 at 10:34 AM, Murray S. Kucherawy wrote: >>> -----Original Message----- >>> From: Dotzero [mailto:dotzero@gmail.com] >>> Sent: Monday, April 23, 2012 5:58 AM >>> To: Murray S. Kucherawy >>> Cc: spfbis@ietf.org >>> Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >>> >>> It is absolutely incorrect to say that their accuracies are about the >>> same. I can consistently game PRA to get a neutral outcome regardless >>> of what the originating domain publishes in it's record. If there is a >>> Sender field then that is the PRA per the spec. I cannot do the the >>> same for SPF. >> Based on the data collected about actual live mail streams, SPF and Sender ID reach the same pass/fail conclusion about messages at least 80%, and as much as 95%, of the time. Do you have different data? >> >> We're specifically not doing a comparison of the weaknesses of the two. We're only citing empirical data. >> > You stated that their accuracies are comparable. Given the known > weakness of PRA (based on emperical data/testing), that is an > incorrect statement. The whole point of SPF (and presumably SIDF) is > to mitigate abuse. You have not provided complete details about the > dataset you are referring to so it is hard to draw detailed conlusions > regarding key points: > > 1) What percentage of the dataset does not have a Sender field? > 2) For data points where there is a Sender field, what percentage of > those data points have a Sender field that is aligned with the Mail > > From (and conceivably From)? > 3) What percentage of the messages were "abusive"? Would the mail > stream selected be a likely target for the particular type of abuse I > am pointing out? If not, why would you expect to see this particular > type of abuse? > 4) To what extent is the dataset representative of the mail streams > that various types and sizes of receivers might receive? That is, is > the dataset truly representative or are there potential issues with > self selection, etc? Dear Mike, Agreed. Serious security concerns remain. Publishing domain alignments of various message elements might better illustrate these concerns. Both PRA and Mail parameters suffer similar weaknesses as neither are assured to be visible. Unlike the PRA, the Mail parameter establishes the return-path, however SPF records lack any assurance which identity is intended to correspond with outbound server addresses. Instances where PRA accommodates normal SMTP function (without misuse of Resent-* header fields) allows this scheme to be more compliant. This compliance carries added risk as it requires application of similar out-of-band information necessary for making exceptions as those with the Mail parameters, although the Mail parameter offers less selection uncertainty and much less associated overhead. The SPF HELO/EHLO option does not require use of out-of-band information, does not require exceptions, nor is there more than one possible identity within a message exchange. While HELO/EHLO identity is recognized by SPF, SPF lacks a scope list making it clear whether use was intended exclusively for the HELO/EHLO to authenticate outbound servers, or to authorize third-party servers that might carry a domain's messages. Source authentication using HELO/EHLO offers content assurances lacking with either the PRA or Mail parameters. Additionally, only the HELO/EHLO identity is able to ensure messages not directly originating from their servers can be safely rejected, which to prevent spoofing, requires a separately specified From header field alignment requirement. IMHO, the situation faced today would have been better resolved by agreeing to a scope-id list that included MFROM, PRA, and HELO. The PRA and Mail parameter identities are used to guess whether a particular server may have been authorized to issue the message or whether the server is normally not compatible with either scheme. Clearly, this lacks a solid basis for ensuring message interchange. By not holding the outbound server accountable for issuing spoofed messages, users that have had their accounts compromised are less likely to be made aware of this dangerous situation and there is less incentive for ensuring account security. Regards, Douglas Otis From hsantos@isdg.net Mon Apr 23 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 825C221F859F for ; Mon, 23 Apr 2012 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FULc0OtBXjB for ; Mon, 23 Apr 2012 14:18:36 -0700 (PDT) Received: from catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5DE21F859E for ; Mon, 23 Apr 2012 14:18:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1265; t=1335215907; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=wBEsgSQRtnKG9cQHTjgDHux9LS0=; b=mxRWEouv0ZBFNno8o2cV EJ4CKizGYw3pX4M2tL+svrALEfICdiZadbme3YDNotDqC3e/NLsSZNI4nsb3SWe9 sOu5f4Qkryf1k+ggqoqf9ldSe+k5S+MEp7rjGvxrclF/aj+fNzRXB3zN1AalmZC1 M+p0puPB1uQx2EL4CwS5qkg= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 23 Apr 2012 17:18:27 -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 v6.4.454.1) with ESMTP id 4122724866.34908.5388; Mon, 23 Apr 2012 17:18:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1265; t=1335215567; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=EISfzVP YuYBLkn8GHucy4Y65wNx6ZQ8F9gRsX2my29I=; b=i570Ld1S1qaRF3Cz2asznv0 dCy+19qYr+FGXIV+ZD/Wj6vKr7Ugn+7VkeMfvd7IhhCxWF+LJqUEqjq6ATSZU9B2 SsNb8qno9KbKIq2EYKFok3DanizMcXHkPZDgpnSJlRjnL2XHdK0BvExtc9Wh6NnY UVwBCLek1IEC6g8UwCGA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 23 Apr 2012 17:12:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 426655534.2971.5368; Mon, 23 Apr 2012 17:12:46 -0400 Message-ID: <4F95C6F2.1030504@isdg.net> Date: Mon, 23 Apr 2012 17:17:38 -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: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> <4F95C30D.5070903@mail-abuse.org> In-Reply-To: <4F95C30D.5070903@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:18:37 -0000 Douglas Otis wrote: > > While HELO/EHLO identity is recognized by SPF, SPF lacks a scope list > making it clear whether use was intended exclusively for the HELO/EHLO > to authenticate outbound servers, or to authorize third-party servers > that might carry a domain's messages. Source authentication using > HELO/EHLO offers content assurances lacking with either the PRA or Mail > parameters. Additionally, only the HELO/EHLO identity is able to ensure > messages not directly originating from their servers can be safely > rejected, which to prevent spoofing, requires a separately specified > From header field alignment requirement. IMHO, the situation faced > today would have been better resolved by agreeing to a scope-id list > that included MFROM, PRA, and HELO. I think this works only for protected a GOOD DOMAIN playing the rules. But I don't see it address the legacy abuse problem where by session only contains: EHLO invalid-input MAIL FROM valid-input-but-spoofed-domain How do you address this? To me, thats the problem. The problem is the the good guy playing by the rules, its the bad guy that is not behaving as we him wish to to. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From sm@elandsys.com Mon Apr 23 15:04: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 96BC021F8593 for ; Mon, 23 Apr 2012 15:04:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIcJ288x9y1z for ; Mon, 23 Apr 2012 15:04: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 8ACF921F8592 for ; Mon, 23 Apr 2012 15:04:48 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.59]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3NM4AMY009475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 15:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335218663; i=@elandsys.com; bh=v8SfYwoggUua+YlZi1ehhG7VOwcNGKvbyxbmYcKy6rU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Z3jWKLc6N2n0fvgqYrxkcX7TV2wIYnmfn2XN8Ft82MNyWYZ9sBFbHjqu76cN7Gqie 7j1TrWVZzelMFn7B4Wr7QJcB7mXDjzgDERC9ELqXqvAGCHbwqlVRyt5truwxfWmq/q 7l0Si8CQ2o38OJ9T56o68o+tMkbUahvLteCzkr+U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335218663; i=@elandsys.com; bh=v8SfYwoggUua+YlZi1ehhG7VOwcNGKvbyxbmYcKy6rU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Xazkpp36RMWUsHyMWEXkD+8fRy6VcUkAYW7MixHztQ+8QPqvqrflv7tqwoAPindNG nR9rBDytvJKOW1Y0qUqcCLkJX/K/z8bkVTEjVTprdGYpNzjUU7f4ezEU1zL8ceVwTp V5y3QWPdCnQqyBY56tmIxLrJuV5glJ0AT0xA8jA4= Message-Id: <6.2.5.6.2.20120423142839.0a727ce8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Apr 2012 14:50:10 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F95C6F2.1030504@isdg.net> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> <4F95C30D.5070903@mail-abuse.org> <4F95C6F2.1030504@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan , "Murray S. Kucherawy" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 22:04:49 -0000 Hello, Barry Leiba, as an individual, suggested text at http://www.ietf.org/mail-archive/web/spfbis/current/msg01397.html There is also a discussion about normative references at http://www.ietf.org/mail-archive/web/spfbis/current/msg01398.html It's difficult for me to identify the other issues in draft-ietf-spfbis-experiment-05 based on the messages posted to this thread. I'll ask the document editor to post a new draft based on the latest round of discussions. Although it might not reflect the outcome of the those discussions, it might provide some clarity. The working group can then suggest text for proposed changes. I'll remind the working group of the moderator note posted by Andrew Sullivan at http://www.ietf.org/mail-archive/web/spfbis/current/msg01388.html Regards, S. Moonesamy SPFBIS WG co-chair From dotis@mail-abuse.org Mon Apr 23 15:31: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 3505321E805D for ; Mon, 23 Apr 2012 15:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5pe+f9XRtC1 for ; Mon, 23 Apr 2012 15:31:36 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id B3C8B21E8048 for ; Mon, 23 Apr 2012 15:31:36 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 9F69317401C4 for ; Mon, 23 Apr 2012 22:31:36 +0000 (UTC) Message-ID: <4F95D848.4030404@mail-abuse.org> Date: Mon, 23 Apr 2012 15:31:36 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> <4F95C30D.5070903@mail-abuse.org> <4F95C6F2.1030504@isdg.net> In-Reply-To: <4F95C6F2.1030504@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 22:31:37 -0000 On 4/23/12 2:17 PM, Hector Santos wrote: > Douglas Otis wrote: > > > > While HELO/EHLO identity is recognized by SPF, SPF lacks a scope > > list making it clear whether use was intended exclusively for the > > HELO/EHLO to authenticate outbound servers, or to authorize > > third-party servers that might carry a domain's messages. Source > > authentication using HELO/EHLO offers content assurances lacking > > with either the PRA or Mail parameters. Additionally, only the > > HELO/EHLO identity is able to ensure messages not directly > > originating from their servers can be safely rejected, which to > > prevent spoofing, requires a separately specified From header > > field alignment requirement. IMHO, the situation faced today would > > have been better resolved by agreeing to a scope-id list that > > included MFROM, PRA, and HELO. > > I think this works only for protected a GOOD DOMAIN playing the > rules. But I don't see it address the legacy abuse problem where by > session only contains: > > EHLO invalid-input MAIL FROM valid-input-but-spoofed-domain Dear Hector, Not sure what was meant by EHLO invalid-input. Spoofing EHLO domains should represent adequate and safe grounds for rejection. Adding a From header field domain alignment requirement against HELO/EHLO domains would extend HELO/EHLO rejections to include this field as well. No receiver should have a problem rejecting messages attempting to spoof HELO/EHLO domains, nor should there be any reason to make alignment exceptions based upon HELO/EHLO domains (this might be amended to include ATPS). > How do you address this? To me, thats the problem. The problem is > the the good guy playing by the rules, its the bad guy that is not > behaving as we him wish to to. With IPv6, you need to assume there is essentially an endless supply of IP address prefixes, where the same has always been true for domain names. Restrictions on use of IPv4 addresses has been largely responsible for excluding most email abuse. That is why it is vitally important to track BOTH the domain and source IP address. This tracking permits locating compromised systems and determining which reputation service had a problem with the message. Unfortunately, many SPF records include %i and %s macros which thwart mitigation efforts and their usefulness for identifying their outbound address space. By capturing the IP address in results (which is missing in Authentication-Results headers), critical tracking ability is retained. There soon will be a sea change in how abuse in general can be handled. Any unknown entity must be rate-limited until behaviors can be determined. Responding to abuse is often after-the-fact where malefactors will have already moved on to exploiting different resources. Regards, Douglas Otis From sm@elandsys.com Mon Apr 23 18:30: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 C0F0521F8707 for ; Mon, 23 Apr 2012 18:30:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8u9309b-Nge for ; Mon, 23 Apr 2012 18:30: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 B651B21F8715 for ; Mon, 23 Apr 2012 18:30:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.59]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3O1UAr5007820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 18:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335231022; i=@elandsys.com; bh=s1AH/peeApeMZoMeqE6LN0Fr5YFZ5JVLz4RZAXyr3UI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f+cUIX2cNAXNndWfhMi1vmejBkBbFJI6/fnlriAt6zSZO2fWmB4Boclk7eFHyjjoW k4/hD3Dx+zmwCrPbUdMBAtg8vtmJXI+AEb8Dp+knD7BjzU0ktd1hhTtFj6uAaqodLD rWVBoKcnSFpnPeeZHQtdNl//Jta9R/pPB8Iy7V/M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335231022; i=@elandsys.com; bh=s1AH/peeApeMZoMeqE6LN0Fr5YFZ5JVLz4RZAXyr3UI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=S1KehiikLuRtaCbtbViFXbG8UiEBLiQgtajBTeAJlQrcCOejgm0vOWcEuEdzvF7zu 8r8TRFSaMtKH+owKzD1Lrj+rHTAXROi+9JRM5qNfTPpQmx8FmLFMf7LOXoH/q8Yv3b 3DCk+kzyCN+OBGBcyeXypgjTWUvtsSrJAc9MbGuc= Message-Id: <6.2.5.6.2.20120423172037.0a053330@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Apr 2012 17:57:04 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4F953EE1.50600@tana.it> References: <6.2.5.6.2.20120422160923.09940d30@elandnews.com> <4F953EE1.50600@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #10 on Received-SPF deprecation, was IETF83 SPFBIS minutes - Version 0.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 01:30:24 -0000 Hi Alessandro, At 04:37 23-04-2012, Alessandro Vesely wrote: >What I meant to say is that it is the servers who should deprecate >Received-SPF, so that their clients stop checking it and check >Authentication-Results instead. That is, 4408bis can recommend that >servers deprecate the old field while they add the new. I edited the text and added the above. >Is it me or "server" and "client" were meant w.r.t. the header field >usage, rather than SMTP? This part was for a three-way hum (questions asked by the Chair). I'll keep it as it is as the results of the hum are below that text. I don't fully understand the question you asked. I'll ask my co-chair about this once the final minutes are done. If anyone in this working group wants to object the following they can contact the WG Chairs or the Responsible Area Director. I gather that English is not your native language. You can expect more leeway. :-) It is fine with me if you raise objections or ask for clarification if you do not understand something I said. Regards, S. Moonesamy From hsantos@isdg.net Mon Apr 23 20:12: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 674D121F84C9 for ; Mon, 23 Apr 2012 20:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r-tAb-jZY9c for ; Mon, 23 Apr 2012 20:12:14 -0700 (PDT) Received: from dkim.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C470B21F84C8 for ; Mon, 23 Apr 2012 20:12:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7477; t=1335237128; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=8KRJ87kEWI2k6oApg6YbRonQ04I=; b=PSg9m1rA4Kzjiwo7+Iz8 GRbpJNkLoyBbz0nxZHVJeK+vuDJ1Hma/owpU4EML2SatjnN9sUfWhrjNyVJWhYOB lIJc/tQK8s64meNgluLbY/g/XykXcH21ELXreiOZihyFa+791IBvE6QxHdfcnvg8 OviAoVElbm0mT0yPWtjIa68= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 23 Apr 2012 23:12:08 -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 v6.4.454.1) with ESMTP id 4143945168.34908.4836; Mon, 23 Apr 2012 23:12:07 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7477; t=1335236787; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=G9R6srd olDyksGbK9z1q1Z8tue9d0K3je43lJLjwXz0=; b=wkMcGu3mB5jip5s+bLyiybo 9up09vDFRkSK11ESxR7jvDVeykQhNe+a+kEZcT1Hecs0ZNEOWyuz58JM5qegVWNX DaWpSyNrsgwxVeHNR2B02l0CpIMFQPsa0BcCEFj7WAcnnZsN8Cc/WwxoSOV9itDI C1/x65sUzcrdd6yqd7JE= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Mon, 23 Apr 2012 23:06:27 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 447876269.3004.6496; Mon, 23 Apr 2012 23:06:27 -0400 Message-ID: <4F9619D7.2040405@isdg.net> Date: Mon, 23 Apr 2012 23:11:19 -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: <6.2.5.6.2.20120422160923.09940d30@elandnews.com> In-Reply-To: <6.2.5.6.2.20120422160923.09940d30@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis-chairs@tools.ietf.org" Subject: Re: [spfbis] IETF83 SPFBIS minutes - Version 0.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 03:12:15 -0000 S Moonesamy wrote: > Hector Santos commented that a deployment document may be outside the > scope of the working group. Dave Crocker suggested writing the text and > figuring out where it should go and the Chair agreed. I don't believe that was I stated. If that is how it was scribed, it was not my intent to say it would be out of scope. Thats because very early on in the SPFBIS, offlist, I proposed the to AD if I could write a deployment guide as I saw it might be useful. So it wasn't much about being out of scope because I already believed in an integrated solution. My version of a SPFBIS deployment would be to focus on existing SPF methods, SPF + SIDF + SUBMITTER, a "How To Guide" and also help address the cited conflicts in DNS record conflicts, better describe lookup for dual TXT/99 and also perhaps offer a way to "inject" DKIM/ADSP into the picture since there has been cited interest in the area of SPF SOFTFAIL plus ADSP. However, realistically if a deployment was agreed I would not be the editor and the concern was how an fast track Information RFC could be used to change the scope of the SPFBIS charter with DKIM and other new methods and that is based on the experience with DKIM WG and how the Informational DKIM Deployment Guide helped change and reshaped DKIM-BIS as a Reputation based design despite the face Reputation as an out of scope in the DKIM charter. I did not wish to experience this again using an SPFBIS Deployment injected integrated methods like DKIM, REPUTATION and overall, replaced SIDF and end up with a less deterministic mail filtering model it offers today. 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. See below. > Issue #4 was ruled as out of scope. There wasn't any objection. > > The Chair asked the floor for opinions about Issue #10 which is about > replacing the Received-SPF: header. Scott Kitterman commented that it > cannot be deprecated as there are still people using them. Tony Hansen > explained that deprecation means not to use it in future implementations > as it will go away at some point, it does not mean that it is no longer > supported in the specification. There were two people in the Jabber > room in favor of deprecating and using the Authentication-Results: > header. Doug Otis commented on having the IP address in > Authentication-Results: like Received-SPF: does. > > The Chair called for a hum for: > > (i) Received-SPF is deprecated > (ii) Not to do anything about Received-SPF: > I would like to see a review on this with a new issue of defining what "MARK-ON-FAIL" means. For the sake of discussion, 4408 states there are two modes a receiver can work with for FAIL policy results: MARK-ON-FAIL REJECT-ON-FAIL A REJECT-ON-FAIL will not have any 5322.Received-SPF or any 5322.Authentication-Result header since the message is never accepted. 4408 does not define MARK-ON-FAIL and the idea is only stated once in section 2.5.4 as "mark the mail". In my technical view, a local site SPF deployment decision to either MARK-ON-FAIL or REJECT-ON-FAIL, SHOULD offer the same negative classification and MUA notification of message failure to the user. A MARK-ON-FAIL mode of operation by the backend SHOULD separate the stream for the user so that offline MUA POP3 access does not mix these marked messages with the user's normal email. Marked messages directly benefit the backend with Online MUA methods which separate and present the good vs bad folders. Examples of such online MUAs are: - Web Mail - RFC-based MUA with IMAP support and a backend offering IMAP access - Proprietary MUAs like Window Live with a HTTP protocol to access and present the backend folders in a IMAP fashion. I presented an example here: http://www.ietf.org/mail-archive/web/spfbis/current/msg01361.html where an spoof -ALL failed policy message was accepted by hotmail.com and it effectively did a MARK-ON-FAIL idea but also separated the message into a Junk Email Folder. The user was protected due this separation with Window Live access and also via ThunderBird POP3 access because the POP3 stream did not include the Junk Email separation. [NOTE: The example also used no headers in DATA, and its possible, the email was marked as Junk-Email because of this and not necessarily because of SPF.] Nonetheless, in my view, this may be an example where MARK-ON-FAIL offers a near similar outcome as REJECT-ON-FAIL by separating the stream and lowering the user exposed risk. If separation semantics is not defined for a MARK-ON-FAIL, then there is an increased designed presumption and dependency for advanced POP3 MUAs to exist and support Received-SPF and/or Authentication-Result headers. If Authentication-Result are used, then it SHOULD have the equivalent Received-SPF FAIL result interpretation if its could be viewed as an alternative, i.e. it is missing the IP address. This is just "starter text" for proposing 2.5.4 text changes: NEW: 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 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. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From sm@elandsys.com Mon Apr 23 20:48: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 4FFED21F869D for ; Mon, 23 Apr 2012 20:48:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ws1YAuOBuaS for ; Mon, 23 Apr 2012 20:48: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 B3A4021F8693 for ; Mon, 23 Apr 2012 20:48:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.59]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3O3luw7021619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 20:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335239289; i=@elandsys.com; bh=HogfSsUEGx/20PasEDv168MIGSAssxiZAz1mvuPwg2E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dZXyfxGctqAfNZYmHc0tsFyd+ah4Pi5JuDtaBif1qj+uRP1PR6M+mJC5hciH0gl6p OvXgP5C2zeoS3hEYVCGK+oXPpxbn2w46L8MTxwAndI25U9TCiKv46CZ0MhxYwfH/rH Pv3cMm5GE5sqlcI0uT2puzEIPJWccA31jvc4W7Ys= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335239289; i=@elandsys.com; bh=HogfSsUEGx/20PasEDv168MIGSAssxiZAz1mvuPwg2E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PJ8uviI5Q92cMx0B8RiyiBIxxEq/DafAX4K17OaG97YjBTw2sbE4ARXt66N1OYxyn iKY0Q0PrJCJ4Zl2kxHeo9M7hxbfDOuflcriBIwCblu86RCdMhY6VXzjLsCMKUDQy9N V+kpIuCw8pECF6Lj3bxPx0mKdDj+rRm/4b4imEkQ= Message-Id: <6.2.5.6.2.20120423201727.0ae82bb0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Apr 2012 20:39:06 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <4F9619D7.2040405@isdg.net> References: <6.2.5.6.2.20120422160923.09940d30@elandnews.com> <4F9619D7.2040405@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] IETF83 SPFBIS minutes - Version 0.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 03:48:11 -0000 Hi Hector, At 20:11 23-04-2012, Hector Santos wrote: >I don't believe that was I stated. If that is how it was scribed, it >was not my intent to say it would be out of scope. Thats because >very early on in the SPFBIS, offlist, I I received the raw notes. I worked from the audio ( http://www.ietf.org/audio/ietf83/ietf83-252a-20120330-0855-am.mp3 ) to get what was said during the SPFBIS session. The Jabber log is at http://www.ietf.org/jabber/logs/spfbis@jabber.ietf.org/2012-03-30.html I can remove the sentence from the minutes. >However, realistically if a deployment was agreed I would not be the >editor and the Ok. BTW, it is up to the WG Chairs to select a document editor. >I would like to see a review on this with a new issue of defining >what "MARK-ON-FAIL" means. Noted. Regards, S. Moonesamy SPFBIS WG co-chair From dhc@dcrocker.net Mon Apr 23 21:35: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 DA76821F848E for ; Mon, 23 Apr 2012 21:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=-1.820, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ9X-UpVVBZi for ; Mon, 23 Apr 2012 21:35:05 -0700 (PDT) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC221F848B for ; Mon, 23 Apr 2012 21:35:04 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id q3O4Yrmd021945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 21:34:57 -0700 Message-ID: <4F95A639.9000101@dcrocker.net> Date: Mon, 23 Apr 2012 11:58:01 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Barry Leiba References: <3365685.ptXhF5PY8S@scott-latitude-e6320> <20120423145947.GH55520@mail.yitter.info> <63583111.FeGGmhBaS4@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 (sbh11.songbird.com [72.52.113.11]); Mon, 23 Apr 2012 21:34:57 -0700 (PDT) Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 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, 24 Apr 2012 04:35:06 -0000 wfm. d/ On 4/23/2012 9:13 AM, Barry Leiba wrote: > > Does that work? I think it says what it needs to say without trying to > either blame anyone or get into historical details that are not > necessary in this document. -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Tue Apr 24 08:46: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 63F7A21F8681 for ; Tue, 24 Apr 2012 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdyovqZzyXhn for ; Tue, 24 Apr 2012 08:46:40 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 49F2921F85ED for ; Tue, 24 Apr 2012 08:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335282398; bh=pZduk7AVsH/chXwcecbOvjbD9tZf+GaIUs6s+HbbR0c=; l=653; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=fLXsLleY1MCN/6bG0p9+Zheap6EO82VZ5oiDdHxQXTZf9k3b+EA44Wa8ON6Ni/Fcq Ml4IKXfUmSWMSf+6n2BTbYQ/5tp6qTWSjqZNgalYhhejMWTYGxC/arYYR476pfgPYg qQGLuoIoBkZX7S4EHnVuK0GRAw0okVhfKG6JINqc= 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, 24 Apr 2012 17:46:38 +0200 id 00000000005DC048.000000004F96CADE.000053C4 Message-ID: <4F96CADD.5010000@tana.it> Date: Tue, 24 Apr 2012 17:46:37 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <16903045.7Ta8mtnNKj@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280FED45@exch-mbx901.corp.cloudmark.com> <2738361.74YB1Lktta@scott-latitude-e6320> <20120423142646.GE55520@mail.yitter.info> In-Reply-To: <20120423142646.GE55520@mail.yitter.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 15:46:41 -0000 On Tue 24/Apr/2012 17:39:50 +0200 Andrew Sullivan wrote: > > Quite frankly, if we had to do an evaluation of this as an experiment, > we would have to criticise the experimental design in many ways, and > the accidental pollution of the sample base is the least of the > problems. But that's not what we're trying to do. Discussing the experimental setup is not our main task. However, I think that if we have precise critics to make we should go ahead, especially if our experience could be useful for other experiments. For example, we could answer why it took so many more years than anticipated in order to reach a community consensus. From vesely@tana.it Tue Apr 24 09:00: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 3847021F87C4 for ; Tue, 24 Apr 2012 09:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.120, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdspCCWo6uvs for ; Tue, 24 Apr 2012 09:00:20 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E2CDE21F8755 for ; Tue, 24 Apr 2012 09:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335283217; bh=VE1rxD27HUHFT3lg+2zJG2YMUQxnU2DO7JoDIW8daR8=; l=5451; h=Message-ID:Date:From:Mime-Version:To; b=fnLQNie0PTHOIU8GMsIc0wrSvs1FD0MCPS8Tlx6j+Q98NN6OoCjZeXypKyKkuIYVb C1JuNG0o7J7oGDlbSmsmJsILY06ryu6m/PbJeY079nB6wezgk6Hk4xyegrP761Mw4M Tv7YqI8KAk0sgnkPmaBOw352kk7e5HoQxGgRfkhI= 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, 24 Apr 2012 18:00:16 +0200 id 00000000005DC048.000000004F96CE10.0000570D Message-ID: <4F96CE10.8060703@tana.it> Date: Tue, 24 Apr 2012 18:00:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-22285-1335283216-0001-2" To: spfbis Subject: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 24 Apr 2012 16:00:24 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-22285-1335283216-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Murray amd all, we often concluded that it's not feasible to complement the experiment I-D with data about SPF checks deployment. Perhaps, we can just ask it, no? I attach proposed questions. Opinions? --=_north-22285-1335283216-0001-2 Content-Type: text/plain; charset=windows-1252; name="SPF-survey.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SPF-survey.txt" VDoNCkFmdGVyIDYrIHllYXJzIG9mIGV4cGVyaW1lbnRhbCBkZXBsb3ltZW50LCB0aGUgU1BG IHByb3RvY29sIGlzIHVuZGVyZ29pbmcgYSByZXZpZXcuIFRoaXMgc3VydmV5IGlzIGRlc2ln bmVkIHRvIGNvbXBsZW1lbnQgcHVibGljbHkgYWNjZXNzaWJsZSBTUEYgZGF0YSBhbmQgdHJh ZmZpYyBpbmZvcm1hdGlvbiBmcm9tIHNlbGVjdGVkIHNlcnZlcnMuICBJdCBhc2tzIHlvdSBx dWVzdGlvbnMgYWJvdXQgInlvdXIgZW1haWwgZG9tYWluIjogdGhpcyBpcyB0aGUgZW1haWwg ZG9tYWluIHRoYXQgeW91IHdvcmsgZm9yLCBvciBoYXBwZW4gdG8ga25vdyBwYXJ0aWN1bGFy bHkgd2VsbCBmb3IgYSBzaW1pbGFyIHJlYXNvbi4gIFRoZSBlbWFpbCBkb21haW4gaXRzZWxm IG1heSBiZSBrZXB0IGFub255bW91cy4NCg0KLS0tLS0NClE6DQpXaGF0IGVtYWlsIGRvbWFp biBhcmUgeW91IGFuc3dlcmluZyBmb3I/DQoob3B0aW9uYWwsIGVudGVyIGFuIGVtYWlsIGFk ZHJlc3MsIGUuZy4gdGhlIHBvc3RtYXRlcidzIGFkZHJlc3MsIHRvIGRpc2Nsb3NlIHRoZSBk b21haW4gbmFtZS4pDQoNCkE6IChzaW5nbGUgdGV4dCwgY2hlY2sgZW1haWwgYWRkcmVzcykN Cg0KLS0tLS0NClE6DQpXaGF0IGlzIHRoZSBhcHByb3hpbWF0ZSB2b2x1bWUgb2YgZGFpbHkg bWVzc2FnZXMgKGV4Y2x1ZGluZyBzcGFtKT8NCg0KQTogKGRyb3AtZG93biBtZW51KQ0KbGVz cyB0aGFuIDEwLDAwMA0KMTAsMDAwIHRvIDEgbWlsbGlvbg0KMSBtaWxsaW9uIHRvIDEwMCBt aWxsaW9uDQptb3JlIHRoYW4gMTAwIG1pbGxpb24NCg0KLS0tLS0NClE6DQpXaGF0IGlzIHlv dXIgcm9sZSB3aXRoaW4gdGhhdCBkb21haW4/DQooY2hlY2sgYWxsIHJvbGVzIHRoYXQgYXBw bHkgdG8geW91KQ0KDQpBOiAobXVsdGlwbGUgY2hvaWNlcykNCkkgYWRtaW5pc3RlciB0aGUg c2l0ZSBvciBtYWtlIGRlY2lzaW9ucyBvbiBtYWlsIHNlcnZlcnMgc2V0dGluZ3MNCkkgaW1w bGVtZW50L2NvbmZpZ3VyZSBtYWlsIHNlcnZlcnMgYWNjb3JkaW5nIHRvIGFkbWlucyBkZWNp c2lvbnMNCkkgd3JpdGUgY29kZSB0byBpbXBsZW1lbnQgbWFpbCBzZXJ2ZXJzIGZ1bmN0aW9u cw0KSSBjb21wbGFpbiBmb3IgbGFjayBvciBtaXNjb25maWd1cmF0aW9uIG9mIG1haWwgc2Vy dmVycycgZnVuY3Rpb25hbGl0aWVzDQpJIHN1cHBvcnQgbWFpbCB1c2Vycw0KSSB1c2UgdGhl IG1haWwgc2VydmVycyBieSBpbnRlcmFjdGluZyB3aXRoIG9uZSBvciBtb3JlIG1haWwgY2xp ZW50cw0KDQotLS0tLQ0KUToNCkRvZXMgdGhlIGRvbWFpbnMgcHVibGlzaCBTUEYgaW5mb3Jt YXRpb24/DQooY2hlY2sgYWxsIHRoYXQgYXBwbHkpDQoNCkE6IChtdWx0aXBsZSBjaG9pY2Vz KQ0KSXQgcHVibGlzaGVzIGJvdGggU1BGIGFuZCBTZW5kZXIgSUQgKGEuay5hLiBzcGYyLjAp DQpJdCBwdWJsaXNoZXMgU1BGIHJlY29yZHMgZm9yIGVhY2ggbWFpbCBob3N0DQpJdCBwdWJs aXNoZXMgU1BGIHJlY29yZHMgZm9yIGFueSBob3N0IGhhdmluZyBvbmUgb3IgbW9yZSBJUCBh ZGRyZXNzZXMNCg0KLS0tLS0NClE6DQpEb2VzIHRoZSBkb21haW4gTVhlcyB2ZXJpZnkgU1BG IG9uIGluY29taW5nIG1lc3NhZ2VzPw0KKGNoZWNrIGFsbCB0aGF0IGFwcGx5KQ0KDQpBOiAo bXVsdGlwbGUgY2hvaWNlcykNClRoZXkgY2hlY2sgdGhlIG1mcm9tIGlkZW50aXR5DQpUaGV5 IGNoZWNrIHRoZSBwcmEgaWRlbnRpdHkNClRoZXkgY2hlY2sgdGhlIGhlbG8gaWRlbnRpdHkN ClJlY2VpdmVkLVNQRiBoZWFkZXIgZmllbGRzIGFyZSBhZGRlZCB0byBpbmNvbWluZyBtZXNz YWdlcw0KQXV0aGVudGljYXRpb24tUmVzdWx0cyBoZWFkZXIgZmllbGRzIGFyZSBhZGRlZCB0 byBpbmNvbWluZyBtZXNzYWdlcw0KDQotLS0tLQ0KUToNCklmIFNQRiBpcyBjaGVja2VkLCB3 aGF0IGlzIHRoZSByZXN1bHQgdXNlZCBmb3I/DQooY2hlY2sgYWxsIHRoYXQgYXBwbHkpDQoN CkE6IChtdWx0aXBsZSBjaG9pY2VzKQ0KU1BGIHJlc3VsdHMgY29udHJpYnV0ZSB0byBtZXNz YWdlIHNjb3JlDQpTUEYgcmVzdWx0cyBhcmUgd3JpdHRlbiBvbiBoZWFkZXIgZmllbGRzIGZv ciBldmFsdWF0aW9uIGF0IG9yIGFmdGVyIGRlbGl2ZXJ5DQpBbiBTUEYgcmVzdWx0IG9mIEZB SUwgY2F1c2VzIHRoZSBtZXNzYWdlIHRvIGJlIHJlamVjdGVkIGltbWVkaWF0ZWx5DQpTUEYg RkFJTCBjYW4gY2F1c2UgcmVqZWN0aW9uLCBhY2NvcmRpbmcgdG8gdGhlIHJlY2lwaWVudHMn IGNvbmZpZ3VyYXRpb24NClNQRiBGQUlMIGNhbiBjYXVzZSByZWplY3Rpb24sIGJ1dCBvbmx5 IGlmIHRoZSBzZW5kaW5nIGhvc3QgaXMgbm90IG9uIGEgd2hpdGUgbGlzdA0KU1BGIEZBSUwg Y2FuIGNhdXNlIHJlamVjdGlvbiwgYnV0IG9ubHkgaWYgbm8gdmFsaWQgREtJTSBzaWduYXR1 cmVzIGV4aXN0DQoNCi0tLS0tDQpROg0KU29tZXRpbWVzIGEgcmVjaXBpZW50J3MgYWRkcmVz cyBpcyBleHBhbmRlZCBhbmQgdGhlIG1lc3NhZ2UgZm9yd2FyZGVkIHRvIG9uZSBvciBmZXcg YWRkcmVzc2VzIChub3QgbWFpbGluZyBsaXN0cyBub3IgbmV3c2xldHRlcnMuKSAgSG93IGlz IHRoYXQgZG9uZT8NCihjaGVjayBhbGwgdGhhdCBhcHBseSkNCg0KQTogKG11bHRpcGxlIGNo b2ljZXMpDQpNYWlsYm94IG93bmVycyBjYW4gY29uZmlndXJlIGFsbCBvciBwYXJ0IG9mIHRo ZWlyIG1haWwgdG8gYmUgZm9yd2FyZGVkIHRvIGV4dGVybmFsIGFkZHJlc3Nlcw0KRm9yd2Fy ZGVkIG1lc3NhZ2VzIGFyZSBzZW50IHVzaW5nIGEgZGlmZmVyZW50IElQIGFkZHJlc3MgdGhh biBvcmRpbmFyeSBtYWlsDQpUaGUgZG9tYWluIGRlcGxveXMgc29tZSBmb3JtIG9mIFNSUyBy ZXdyaXRpbmcNCkZvcndhcmRlZCBtZXNzYWdlcyBhcmUgc2VudCB3aXRoIGFuIGVtcHR5IGVu dmVsb3BlIHNlbmRlciAoTUZST00pIGFkZHJlc3MsIHNvIHRoYXQgdGhleSB3b24ndCBib3Vu Y2UNClRoZSBNRlJPTSBhZGRyZXNzIGlzIGtlcHQgaW50YWN0LCBzbyB0aGF0IGJvdW5jZXMg Z28gdG8gd2hlcmUgdGhleSB3ZXJlIG9yaWdpbmFsbHkgYm91bmQgdG8gZ28NClRoZSBNRlJP TSBhZGRyZXNzIGlzIGFsdGVyZWQgc28gdGhhdCBib3VuY2VzIGdldCBiYWNrIHRvIG91ciBk b21haW4gaW4gYW55IGNhc2UNCg0KLS0tLS0NClE6DQpBcmUgdGhlcmUgcHJvdmlzaW9ucyBm b3IgZ2V0dGluZyBtZXNzYWdlcyB0aGF0IHdlcmUgZGVzdGluZWQgdG8gYW4gZXh0ZXJuYWwg bWFpbGJveD8NCihjaGVjayBhbGwgdGhhdCBhcHBseSkNCg0KQTogKG11bHRpcGxlIGNob2lj ZXMpDQpPdXIgc2VydmVycyBjYW4gZmV0Y2ggbWVzc2FnZXMgZnJvbSBleHRlcm5hbCBQT1Az L0lNQVAgdXNlciBhY2NvdW50cw0KV2UgbWFpbnRhaW4gYSB3aGl0ZSBsaXN0IG9mIGZvcndh cmRlcnMgdGhhdCBmcmVxdWVudGx5IGZhaWwgU1BGIGNoZWNrcw0KVXNlcnMgY2FuIGFzayB0 aGF0IGZvcndhcmRpbmcgZG9tYWlucyBiZSB3aGl0ZWxpc3RlZCB0byBza2lwIFNQRiBjaGVj a3MNCg== --=_north-22285-1335283216-0001-2-- From spf2@kitterman.com Tue Apr 24 09:06: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 644A011E80A5 for ; Tue, 24 Apr 2012 09:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh1-D8M-qKy9 for ; Tue, 24 Apr 2012 09:06:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5C811E80B1 for ; Tue, 24 Apr 2012 09:06:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 825BF20E40E9; Tue, 24 Apr 2012 12:06:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335283587; bh=TJ6qhrcJqTl5ee8eyI140+4FFCae2P/7l6w5O0UXJJ4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=mBNzviQrG+j60gJJVNi6fV4nvh2rJsnWxMmqIdO5nnM91Rqt9IyGPjhuVuDrVygyE uo4gFas56TgoVwReZTUxWHQY74vPRGGOL8V5WfSiTCx3SniL2tER3DxfT0BwhNhHLv FkH3V/AQfXKoMnvE7VJU6s8jc9XVHd0v1ZuvRzog= Received: from scott-latitude-e6320.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 ESMTPSA id 682C120E4089; Tue, 24 Apr 2012 12:06:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 24 Apr 2012 12:06:26 -0400 Message-ID: <6957082.s7XD7iz3sE@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F96CADD.5010000@tana.it> References: <20120423142646.GE55520@mail.yitter.info> <4F96CADD.5010000@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] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 16:06:29 -0000 On Tuesday, April 24, 2012 05:46:37 PM Alessandro Vesely wrote: > On Tue 24/Apr/2012 17:39:50 +0200 Andrew Sullivan wrote: > > Quite frankly, if we had to do an evaluation of this as an experiment, > > we would have to criticise the experimental design in many ways, and > > the accidental pollution of the sample base is the least of the > > problems. But that's not what we're trying to do. > > Discussing the experimental setup is not our main task. However, I > think that if we have precise critics to make we should go ahead, > especially if our experience could be useful for other experiments. > For example, we could answer why it took so many more years than > anticipated in order to reach a community consensus. I really don't think there is value in going down this road. Personally, I don't think technical considerations were a significant factor in what was decided in 2006, so any attempt to understand the technical aspects of the decision in retrospect are doomed to failure, confusion, and doubt. Scott K From ajs@anvilwalrusden.com Tue Apr 24 09:49: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 2A55D21E808E for ; Tue, 24 Apr 2012 09:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaeNKwrGEuSY for ; Tue, 24 Apr 2012 09:49:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49921E8015 for ; Tue, 24 Apr 2012 09:49:03 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id D64F51ECB41C for ; Tue, 24 Apr 2012 16:49:02 +0000 (UTC) Date: Tue, 24 Apr 2012 12:49:01 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120424164901.GK55967@mail.yitter.info> References: <4F96CE10.8060703@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F96CE10.8060703@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 24 Apr 2012 16:49:04 -0000 No hat. On Tue, Apr 24, 2012 at 06:00:16PM +0200, Alessandro Vesely wrote: > I-D with data about SPF checks deployment. Perhaps, we can just ask > it, no? Whom do we ask? How do we select that sample? Moreover, how do we make sure that the sample isn't biased? What you're asking for is a self-selected sample. They're notoriously tricky to use. (I don't know very much, but I know really quite a lot about survey design, and I urge all of you not to give me the opportunity to bore you.) A -- Andrew Sullivan ajs@anvilwalrusden.com From internet-drafts@ietf.org Tue Apr 24 09:58: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 D4FF921E8097; Tue, 24 Apr 2012 09:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI06IpHQy83o; Tue, 24 Apr 2012 09:58:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEF221E804D; Tue, 24 Apr 2012 09:58:37 -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.01p1 Message-ID: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> Date: Tue, 24 Apr 2012 09:58:37 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 16:58:38 -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 : Resolution of The SPF and Sender ID Experiments Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-06.txt Pages : 11 Date : 2012-04-24 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Because of possible interoperability issues, particularly but not only those created by simultaneous use of the two protocols by a receiver, the IESG was unable to determine technical consensus and decided it was best to publish all of RFC4405, RFC4406, RFC4407 and RFC4408 as Experimental documents. The IESG invited the community to observe their deployments for a period of time, and expressed hope for later convergence of opinion. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ From vesely@tana.it Tue Apr 24 10:17: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 175E321F881B for ; Tue, 24 Apr 2012 10:17:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmDwEc44JCPX for ; Tue, 24 Apr 2012 10:17:11 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3D16E21F863F for ; Tue, 24 Apr 2012 10:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335287830; bh=+6sa6QYjtq3dPV0qRXFWM7cI6eak7yg+kUftI9bXE8A=; l=868; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QYUa1tnQ+/XcoMnrxDyJ2yM2kiNiOY6hYI4gGxtehUsJjBX1ZzZebdXlpfjFIzacB 1Of6P5wMXy541jb7bTJYXNuNysInsW/t6MUtc4vkPuHo9sXBpl3OzPK1asHr+bl/Ms UkgGlfYEfp83uoO3i6OrlZ6NWpK20/0yqFJXuEkI= 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, 24 Apr 2012 19:17:10 +0200 id 00000000005DC035.000000004F96E016.000069DC Message-ID: <4F96E016.1030905@tana.it> Date: Tue, 24 Apr 2012 19:17:10 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> In-Reply-To: <20120424164901.GK55967@mail.yitter.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 24 Apr 2012 17:17:12 -0000 On Tue 24/Apr/2012 19:02:15 +0200 Andrew Sullivan wrote: > On Tue, Apr 24, 2012 at 06:00:16PM +0200, Alessandro Vesely wrote: >> I-D with data about SPF checks deployment. Perhaps, we can just ask >> it, no? > > Whom do we ask? How do we select that sample? Posting to the mailing lists we know of. > Moreover, how do we make sure that the sample isn't biased? What > you're asking for is a self-selected sample. They're notoriously > tricky to use. Well, I think we'll be able to see if answers make some sense. In addition, it may allow us and the readers of the experiment to take the pulse of the current interest in SPF. > (I don't know very much, but I know really quite a lot about survey > design, and I urge all of you not to give me the opportunity to > bore you.) If you have some practical advice, I think it wouldn't be boring. From barryleiba.mailing.lists@gmail.com Tue Apr 24 10:22: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 D311821E8090 for ; Tue, 24 Apr 2012 10:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX23zH2B13lv for ; Tue, 24 Apr 2012 10:22:50 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 196FE21F86F3 for ; Tue, 24 Apr 2012 10:22:49 -0700 (PDT) Received: by yhkk25 with SMTP id k25so672606yhk.31 for ; Tue, 24 Apr 2012 10:22:48 -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:content-type :content-transfer-encoding; bh=kvOjSkCjvQpSob+co1q3vh6hog+rzHdhqfjyO+vRNOw=; b=l7BVfQ12qf9A4gNQd8W7cAUD7gUz2SiCrdmPcN9sPJYEvu4LOcbiGByd1OXK92t2SJ xAzvrJs7fAnvrQ/iTVQApP1xXxxvhdXZ1bJMvWMYm7FFAerOrRzcM2qYteXuo2vza+TC 8PgFpRx5SyMVRuT7RH24ZLdXo1g2Ekun4wF99dfMYR4zvjbhPr3m8AGFg8UBL/Ic964k Dcmp7mkVZbHvw0NN0T1V8ieGV/GPKB7VmcsbFGm439s/Ypv3v98ZsYtvQSfcC85gcDOA y74IdmcRRHdxiXKA9g8rrGfQ2SJ1J3Q8MDw5+z32stS++kLrPU4OqztHSUjULUJnIcSL cpcw== MIME-Version: 1.0 Received: by 10.236.185.10 with SMTP id t10mr19227937yhm.112.1335288168658; Tue, 24 Apr 2012 10:22:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.152.14 with HTTP; Tue, 24 Apr 2012 10:22:48 -0700 (PDT) In-Reply-To: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> References: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> Date: Tue, 24 Apr 2012 13:22:48 -0400 X-Google-Sender-Auth: 5BNrGvxBSCUwCcxksh2aVhoyoYY Message-ID: From: Barry Leiba To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 17:22:54 -0000 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the SPF Update Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Resolution of The SPF and Send= er ID Experiments > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Murray S. Kucherawy > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-spfbis-experiment-06.= txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-24 This version addresses all of my comments. I note that Dave Crocker made two substantive comments that I got directly, but that didn't show up on the mailing list (he did CC the list, so I don't know why they're not there). In those, he said that the [DNS] reference should also be normative, and I think he's right because of the discussion of RR types. Apart from that, my participant's opinion is that this version is ready to ship. Barry From vesely@tana.it Tue Apr 24 10:57: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 46D6511E80C1 for ; Tue, 24 Apr 2012 10:57:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlMKCvKPt1ll for ; Tue, 24 Apr 2012 10:57:41 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 75BF511E80C0 for ; Tue, 24 Apr 2012 10:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335290260; bh=2bFiAfYOtkPsF4jQewpsSJBSxQdTa+euIbNgvf0a0CQ=; l=533; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=auP2Pl5JsjJm74I4mMBTBP4OvH4IepDEkezvbYuTRhPzv0vH73nQ4Fc8ohcZOPkYk iq1uCiUgbhaiIkulTPoSUstNkoQ5pDUywTvTXdKIp+FWWNrQJrKAHTdXEaD8UsAa7f KCI3AA/VZr0NCn05JzFyngv/5B6Q7rxnyUsJytVs= 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, 24 Apr 2012 19:57:40 +0200 id 00000000005DC03F.000000004F96E994.00007339 Message-ID: <4F96E994.4050104@tana.it> Date: Tue, 24 Apr 2012 19:57:40 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 17:57:42 -0000 On Tue 24/Apr/2012 19:37:10 +0200 Barry Leiba wrote: > > Apart from that, my participant's opinion is that this version is > ready to ship. May I ask how delivering this I-D affects the WG schedule? The I-D is scheduled for Aug 2012. I like its findings and its conclusions, but it still misses some data that may be relevant. So, /if/ there's no specific reason to ship it now, we could keep it dormant for a few months and proceed as if it were shipped. That way, that missing data could have a chance, however remote. From sm@elandsys.com Tue Apr 24 11:02: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 781F311E80C1 for ; Tue, 24 Apr 2012 11:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+6eHbX0VssV for ; Tue, 24 Apr 2012 11:02: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 4246811E808F for ; Tue, 24 Apr 2012 11:02:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.59]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3OI22rs017232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2012 11:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335290536; i=@elandsys.com; bh=w0Q0vsF2GtyElEEvOfjPNfNiwB+U4SllEmnLe2A2QHo=; h=Date:To:From:Subject:Cc; b=y6MOZ16CFhnbpml9PTEqVppkMcIGCQ4g88EoG9PQc/3K7cpfhj8jKifaaesIQHJHC dYSLimCe1yw4bHiLFrgpij57ZqkCpqgZqO305svcUvK5WS5GT/u3KhXLbRwQXMChSp XBkbG+3SWWAZTcg3rP3X6fkuWk2/sTXhR2Quv+S8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335290536; i=@elandsys.com; bh=w0Q0vsF2GtyElEEvOfjPNfNiwB+U4SllEmnLe2A2QHo=; h=Date:To:From:Subject:Cc; b=fBYEYY73tnMybDDgJ3QOFnn0MUdgzSSMokMAjo5qh2ZzStFG1ET95hfeVIItpCMMp oYkT5NnioLR6U/b3y6ABqssq5Yp4cYovYpyzw+1Uta/lAQ39ANreN/2xF9ifIBSWW7 xClsBrL2aMTyRsXq3ojtsO2nHHtRcXg6fiohV3Ac= Message-Id: <6.2.5.6.2.20120423171049.0a053708@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Apr 2012 10:01:07 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] IETF83 SPFBIS minutes - Version 0.2 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:02:22 -0000 The SPFBIS WG held a meeting at IETF83. This is Version 0.2 of the minutes. Please email me any suggested changes to me. SPF Update Working Group (SPFBIS) Minutes Meeting : IETF83, Friday 30 March, 2012 Location: Room 252A, Paris, 09:00 to 11:00 Chairs : Andrew Sullivan Minutes : John Levine Version 0.2 Audio: http://www.ietf.org/audio/ietf83/ietf83-252a-20120330-0855-am.mp3 AGENDA A. Meeting Administrivia Note well Agenda bashing B. RFC 4408 issues C. SPF RR Type and TXT RR (issue #9) D. DNS amplification attacks E. Is a deployment document needed F. Path authorization/updating SMTP G. Adoption of draft-kucherawy-spfbis-experiment-03 describing the SPF/Sender-ID experiment and discussion H. Any Other Business A. Meeting Administrivia Andrew Sullivan chaired the IETF83 SPFBIS Working Group meeting in Paris, France. John Levine was the minute-taker and Murray S. Kucherawy and Tony Hansen were the Jabber scribes. There were 20 people in the room. The Chair brought the Note Well to the attention of the meeting participants, asked them to sign the blue sheets and bashed the agenda. Slides: http://www.ietf.org/proceedings/83/slides/slides-83-spfbis-1.pptx B. RFC 4408 issues RFC 4408 issues are listed at http://trac.tools.ietf.org/wg/spfbis/trac/report/ Issue #5 is about some ambiguities in the specification. Issue #7, #8 and #16 are there to be tracked. The working group will work on text once it has adopted a draft. Issue #15 is about MAIL FROM. Some of the issues have not been opened for discussion on the list yet. Issue #17 is about uric. There hasn't been any discussion. Some of the issues in the tracker have not been opened for discussion yet as the Chairs have been trying to go through a few issues at a time. Issue #18 is about adding a SMTP reply code for permanent error. It is not clear whether it is within the charter. Issue #22 is about how to handle invalid domain. This is linked to discussions about various cases having to do with DNS. The Chair mentioned that SERVFAIL is not an error in DNS and he has updated the ticket to say how it will be handled. Scott Kitterman asked via Jabber how can we know whether we are done if there is no text to agree on. The Chair explained that the basic idea is that once substantive discussion is done, what needs to be done is to agree on text. Arguing on the details of the text is easier once the working group agrees on what it wants to say. The Chair mentioned that errata have to be addressed in a bis document and that it is straight-forward. Issue #4 was ruled as out of scope. There wasn't any objection. The Chair asked the floor for opinions about Issue #10 which is about replacing the Received-SPF: header. Scott Kitterman commented that it cannot be deprecated as there are still people using them. Tony Hansen explained that deprecation means not to use it in future implementations as it will go away at some point, it does not mean that it is no longer supported in the specification. There were two people in the Jabber room in favor of deprecating and using the Authentication-Results: header. Doug Otis commented on having the IP address in Authentication-Results: like Received-SPF: does. The Chair called for a hum for: (i) Received-SPF is deprecated (ii) Not to do anything about Received-SPF: The hum favored deprecation. As somebody was not in favor of deprecation, the Chair asked for the person to explain why. Alessandro Vesely considered that deprecation is the wrong word. The Chair clarified that if people believe that the header is useful,it should stay, otherwise, it should go away. Alessandro Vesely stated servers should deprecate Received-SPF, so that their clients stop checking it and check Authentication-Results instead, i.e. 4408bis can recommend that servers deprecate the old field while they add the new. Scott Kitterman mentioned that things can be deprecated for a long time before they actually get removed; the working group could state a preference. S. Moonesamy, as an individual, commented that deprecation can be done by clients not sending it but receivers supporting it, meaning that things will continue parsing the header for some time. The Chair pointed out that there were three possibilities on the table: (i) Servers complain but clients continue to use it (ii) Clients keep sending it but servers do not say anything when they get one (iii) We just deprecate it and maybe people get warnings Pete Resnick, as Area Director, asked for comments about the interoperability problem if people continued to use Received-SPF; i.e. what the problem with keeping it around is. He asked that if there wasn't a problem with generating them, what's the use of deprecating them. The idea was about long-term simplification. John Levine mentioned that if you were allowed to generate both headers, they could disagree. The Chair suggested that someone send their best arguments to the mailing list for deprecating and someone else sends arguments for deprecating. The Chair also suggested that Doug Otis makes the argument for "do not deprecate, leave it alone" on the mailing list and Doug Otis agreed. Murray Kucherawy commented on Issue #11 saying that check_host() looks awfully lot like an API whereas the IETF does not define APIs. Pete Resnick, as Area Director, preferred to see the specification be written in terms of semantics of the protocol elements rather than processing. Murray Kucherawy volunteered to write a paragraph to mention that it is merely an illustration. The discussion on the mailing list about Issue #13 was inconclusive. The Chair asked whether Best-Guess SPF was in scope at all and if so what does the working group want to say about it, with the default being not to say anything. Scott Kitterman pointed out that it was not left out of RFC 4408 by accident. Murray Kucherawy argued that as there are places such as gmail.com which makes use of this, it would help to have some clarifying text about it. Murray Kucherawy asked whether the IESG has an opinion about "widely deployed" or whether it only wants to see whether the working group did its homework. The Chair commented that "widely deployed" can be done on a case by case basis and based on the Conclusions that the working group draws. There weren't any objections. The Chair commented that he did not completely understand what the issue was with Issue #14. Nobody argued that the working group must deprecate local-part macros. The Chair closed the issue with "won't fix". The Chair will reconsider the issue if there is text to go in the Security considerations section of the document. John Levine pointed out that as there is only one person in favor of the argument, it should be closed. The Chair stated that if there is a legitimate argument, it should go into the Security Considerations section. John Levine revised his previous comment by pointing out that there are a vast number other of ways to generate an attack. The Chair pointed out that SPF sucks does not belong in the document. Pete Resnick, as Area Director, explained what he understood from the discussion of Issue #14: the working group sufficiently considered the issue and agreed not to deprecate the feature; it can add clarification in the Security Considerations section. The Chair stated that the issue will be closed with "won't fix" and a new issue can be added saying that the working group will add text in the Security Considerations section. Alessandro Vesely asked a clarifying question about whether a domain using local-part macros is badly administered. Scott Kitterman objected to adding text about this issue in the Security Considerations section. Pete Resnick, as Area Director, mentioned that he can object to the new issue and provide reasons for why the text should not be added. Eliot Lear pointed out that the discussion was about two sentences which were non-normative where the risk does not even have to be characterized. The Chair asked whether anyone would like to argue about Issue #16, in favor of relaxing the syntax checking. As there were no arguments, the issue was closed with "won't fix". Issue #27 is about the PTR mechanism and %{p} macro. There was support on the mailing list for adding "SHOULD NOT" text about this. There was support for "SHOULD NOT" from the Jabber room. The issue was closed pending the new document. C. SPF RR Type and TXT RR (issue #9) The were people on the mailing list in favor of using the TXT RR appeared to be a modest majority and there were people who argued for SPF RR Type on the grounds of DNS hygiene. The Chair explained that it appears as an empirical matter, overwhelmingly, the TXT RR is used but RRTYPE 99 does not qualify under the unused provision of the SPFBIS charter. Dave Crocker mentioned that we have not had consensus about the definition of "unused" and pointed about that the definition is hugely required in this case. Dave Crocker agreed with the Chair that there was little adoption of RRTYPE 99 and mentioned that functionally, after this many years, it is serving as cruft, it is redundant and offers no benefit after this long. He suggested this also as one definition of "unused". Tony Hansen asked whether any sites publishing RRTYPE 99 were found in the surveys done. Murray Kucherawy pointed out that if this was the case, the position stated by Dave Crocker would be false. The Chair reminded the working group about a comment from Scott Kitterman stating that if people were publishing RRTYPE 99 only, it is an indication of them not knowing what they were doing anyway. Peter Koch suggested changing some of the experimental components into production if the experiment was successful. It pointed out the working group does not own the TXT RR or the zone apex and it should probably keep that in mind. He reminded the working group that there has been this humongous argument about deployed base within the IETF. He considered it ill-advised to make decisions which may have long term consequences based on the results of the experiment only. The Chair mentioned that the evidence suggests that SPF is widely deployed, likely more widely deplyed than IPv6. Scott Kitterman mentioned that there was an interoperability issue which would have to be clarified. Pete Resnick, as Area Director, in response to Peter Koch's comments, mentioned that in the deal with the IESG, as a general statement, the working can removed what is unused and put in what is widely deployed. He pointed out that saying that TXT RR is part of an experiment is contrary to the agreement made with the IESG. His opinion is that either way, the proposal is stuck with TXT RR and that it is not an issue. The only issue is whether the proposal can remove the SPF RRTYPE as unused. Eliot Lear did not see the point of keeping the SPF RRTPE given the results of the survey. He mentioned that he did not hear a compelling technical argument for keeping the RRTYPE. Murray Kucherawy suggested adding an appendix to the conclusion document about the experience in developing the RRTYPE given recent discussions on other IETF mailing lists. He proposed that it would be better if it was done as an IESG statement. Pete Resnick, as Area Director, did not think that an IESG statement is appropriate. The conclusion reached by the Chair was that the document will say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99. In the experiment result document that 166 out of 251,000 domains surveyed published only RRTYPE 99. On a procedural point, the Area Director stated that he would like the working group to document that fact. The IESG consider that fact should it come up in an appeal. Tony Hansen commented that when you write a protocol, there is definite harm if there is a choice in what you publish and what you look for. He is of the view that there is a definite bug in RFC 4408. D. DNS amplification attacks The Chair proposed that the working group asks the DNS Directorate whether there is a serious issue (#24) here because there has been previous analysis of this issue. Peter Koch stated as a member of the DNS Directorate his preference for the question to be more open or more to the point. He would like a little less ambiguity in the question; adding that a straight yes or no answer should not be expected. The Chair commented that he was not expecting a straight answer; he would never expect a straight yes or no answer from anybody with any question having to do with DNS. E. Is a deployment document needed Hector Santos via Jabber raised a concern is that this "Informative" RFC can be used to alter the scope of the WG even though it may be out of scope. The Chair mentioned that he does not think the charter allows for a deployment document. The Chair asked for a three-way hum: 1. Don't do anything at all and let someone else produce deployment guide 2. Add some deployment notes as an appendix in the bis document 3. Separate document There was a little bit for 1, a tiny noise for 2 and a medium noise for 3. Dave Crocker suggested writing the text and then figuring out where it should go and the Chair agreed. F. Path authorization/updating SMTP The Chair explained that this is mainly about mail forwarding (Issue #12) and that the discussion on the mailing list was completely inconclusive. Alessandro Vesely commented on the important of having forwarding procedures devised. A workaround was presented, including an obligation for forwarders to publish a host policy-record. The Chair commented that "forwarder must publish" + "helo-pass prevents rejection" was slightly different than the solution originally proposed. The Chair asked whether that was protocol advice or deployment advice. Alessandro Vesely pointed out that the specification is not in accordance with the SMTP specification which mentions that one can forward while keeping the Return-path unaltered. John Levine commented that SMTP is designed to deliver mail over whichever path is supposed to work and it can be argued that SPF is broken by design; SPF takes the practical fact assuming that most mail is delivered over a predictable path. The Chair stated that this issue is deployment advice. Alessandro Vesely did not object to the statement. G. Adoption of draft-kucherawy-spfbis-experiment-03 draft-kucherawy-spfbis-experiment-03 was adopted as a working group I-D. Due to a technical glitch in the datatracker, the filename of the draft could not be changed. The Chair pointed out that there has not been any alternative proposal. Murray Kucherawy gave a presentation of the document describing the SPF/Sender-ID experiments. Slides: http://www.ietf.org/proceedings/83/slides/slides-83-spfbis-0.ppt He mentioned that there wasn't any specific guidance on how the experiments should be concluded. He tried to follow the steps of an interoperability report to produce the document. The conclusions will be based on the collected data. He will shortly have extensive data on published SPF records. Tony Hansen asked whether the data is enough to produce a satisfactory report. Murray Kucherawy mentioned that as the working group does not have specific guidance from the IESG, it only has to show that it has done its homework. The data provided by Hotmail will be the missing piece. The Chairs pointed out that they are in a hurry and they would like to get this deliverable winded up so that the working group can work on the 4408bis specification. It would be premature to start work on the 4408bis specification if there isn't significant work to draw the conclusions as this is a necessary condition to proceed with work on the modified specification. Dave Crocker suggested that the working group focus on the questions to answer for the IESG or any reasonable analyst. Someone suggested that the document requires some methodology section. Doug Otis mentioned getting some data about local-part macros. Hector Santos mentioned that more public information data is needed than just ESP domains. The Chair pointed out that these are requests for data sets and asked whether the people asking the questions are volunteering to collect the data. Murray Kucherawy commented that it would not be possible to get information about local-part from the survey he has done. He added that it was not possible to know how many implementations out there check for the RRTYPE. Doug Otis suggested using postmaster for local-part macro tests. The Chair suggested that if Doug Otis has access to a busy mail site and if he can share the data, it would be interesting for the working group; if he does not, the request cannot be satisfied as the working group does not have access to a data source which may provide the information. The Chair asked whether it is reasonable to expect this work to be completed before the next IETF meeting. He mentioned that given the charter, there is no reason the working group cannot be finished with its deliverables by the Fall. H. Any Other Business The Chair stated that no other business came up and reminded the working group to sign the blue sheet. The meeting was adjourned at 10:46 a.m. Regards, S. Moonesamy From sm@elandsys.com Tue Apr 24 11:02: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 DE30211E80C1 for ; Tue, 24 Apr 2012 11:02:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL6i-D7SP6CC for ; Tue, 24 Apr 2012 11:02: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 442F011E808F for ; Tue, 24 Apr 2012 11:02:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.59]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3OI22ru017232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 11:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335290542; i=@elandsys.com; bh=pg1a//CCBsI8kbyPKJPEe4BcmBqSjjHxmzgBPY9sAMA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lF2dFytXjMy54ui4WdjWsjKlX1HXjPddcWm0rVhpYEaVn8s9jZjhxz4dqfKPi0/WA qT0UeHrSPmQiwhqlCwpiIP8dF7+SXePpcDTZyZW7ivotGPb1+gKPvkCv+AVfTvrfb1 zDjULi418WbhdLRDnC7epCd+YNxU4ZskPudX2WfE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335290542; i=@elandsys.com; bh=pg1a//CCBsI8kbyPKJPEe4BcmBqSjjHxmzgBPY9sAMA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xBVvaLPRXWrQbXBgTXj+1X84qMcnIEvzfS53j1P832yLtztzLPSVxYwnexr3u9z7G ph0eBEn805fhD0EgGokIUJN5m+BlCJ2Dd0gXggFyn+OhSLpIZIWQWmLVxwoLHY9O0K zlU0qntHsgqFpYhrgiVJgBy2WMXYIFFB6ppfwYXQ= Message-Id: <6.2.5.6.2.20120424104130.09ca5450@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Apr 2012 10:59:53 -0700 To: Barry Leiba From: S Moonesamy In-Reply-To: References: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:02:31 -0000 Hi Barry, At 10:22 24-04-2012, Barry Leiba wrote: >This version addresses all of my comments. I note that Dave Crocker Thanks for the review and for sending text. >made two substantive comments that I got directly, but that didn't >show up on the mailing list (he did CC the list, so I don't know why Some of Dave Crocker's messages must have gone to the moderation queue as the email address was not subscribed to this mailing list. I think that he cancelled the postings. Regards, S. Moonesamy From ajs@anvilwalrusden.com Tue Apr 24 11:11: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 ED17221F8763 for ; Tue, 24 Apr 2012 11:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVMP0e2y0jID for ; Tue, 24 Apr 2012 11:11:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5953221F879A for ; Tue, 24 Apr 2012 11:11:07 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id AFFDC1ECB41C for ; Tue, 24 Apr 2012 18:11:06 +0000 (UTC) Date: Tue, 24 Apr 2012 14:11:04 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120424181059.GM55967@mail.yitter.info> References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F96E016.1030905@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F96E016.1030905@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 24 Apr 2012 18:11:08 -0000 No hat. On Tue, Apr 24, 2012 at 07:17:10PM +0200, Alessandro Vesely wrote: > > > > Whom do we ask? How do we select that sample? > > Posting to the mailing lists we know of. This is approximately the worst kind of sample there is, I'm afraid. It's actually no better than those "surveys" you see on the sidebar of webpages. The number that comes out of it is a number, all right, but it doesn't measure anything. > Well, I think we'll be able to see if answers make some sense. How? What that really says is, "I already know the answer; I just want to be able to point at something to back it up." I actually think such surveys have negative value, because they tend to be designed to give the presupposed outcome. Surveys are excellent ways to find out what people believe about themselves. They're a lousy way to find out whether those beliefs are true. The evidence we have does not ask anyone to provide their opinion about what they think they do. Instead, it takes actual evidence from deployed systems. I grant you that the cross-section of deployed systems is narrow. It would be considerably better if we had a way of soliciting logs from a wider array of mail providers, or if we had a tool that people could run across their mail logs to answer certain questions. In the absence of someone stepping up to do all that work (and to convince people to share their logs with us), I don't think a survey of admins is the right answer. I'd prefer to stick with narrowly empirical data and draw conclusions from that, with the caveat that we are assuming these mail systems are representative of all mail systems. In > addition, it may allow us and the readers of the experiment to take > the pulse of the current interest in SPF. > > > (I don't know very much, but I know really quite a lot about survey > > design, and I urge all of you not to give me the opportunity to > > bore you.) > > If you have some practical advice, I think it wouldn't be boring. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Andrew Sullivan ajs@anvilwalrusden.com From dcrocker@gmail.com Tue Apr 24 11:17: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 2938521F8815 for ; Tue, 24 Apr 2012 11:17:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5RoBA9Xze75 for ; Tue, 24 Apr 2012 11:17:42 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8144321F854F for ; Tue, 24 Apr 2012 11:17:42 -0700 (PDT) Received: by dady13 with SMTP id y13so1715644dad.27 for ; Tue, 24 Apr 2012 11:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XV+LfPwkVbGG2jcJhi5tiUzsQgFNvidN/SAfl8coL7U=; b=WRCcUkRCgfY7WMeFFX0cZfVyHQ5T+s8mgWkrwK7sFXzNFNvZFB5I9VKtXvWw3h6ena cARO3eR3KEiI5KBqfAgjsj1atBFl+wrYu15Ih9pNF0Y9MvCoMUE2rx59IP/QI42I4rAx JBgRu6+sCfokIGweOlKidSJTe3eVwhPvqA1I/crdoqt38b7JNaSE1g4UUHgxTAwV8E1/ UncDpUBSpuUURFPXnUmP3qRaWf28lofnEUuBV3DgW2Ff+Wg0JaYBDV31IsteQnsajnnB wPQc9sYn6hCX3UGsSQ2koKu6J/HxeADX5GoZ1gaen85F4KNzlIG5FozyXH1JVAU6NRpr KaIg== Received: by 10.68.224.99 with SMTP id rb3mr5668060pbc.79.1335291457983; Tue, 24 Apr 2012 11:17:37 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net. [67.127.58.62]) by mx.google.com with ESMTPS id u5sm18018345pbu.76.2012.04.24.11.17.35 (version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 11:17:36 -0700 (PDT) Message-ID: <4F96EE34.50106@gmail.com> Date: Tue, 24 Apr 2012 11:17:24 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: S Moonesamy References: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120424104130.09ca5450@resistor.net> In-Reply-To: <6.2.5.6.2.20120424104130.09ca5450@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Apr 2012 11:26:45 -0700 Cc: spfbis@ietf.org, Barry Leiba Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:17:43 -0000 On 4/24/2012 10:59 AM, S Moonesamy wrote: > > Some of Dave Crocker's messages must have gone to the moderation queue > as the email address was not subscribed to this mailing list. I think > that he cancelled the postings. I'm having some posting problems from some of my accounts. They are persistent. I didn't cancel the messages. d/ -- Dave Crocker bbiw.net From dcrocker@gmail.com Sun Apr 22 14:44: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 A68B821F85A1 for ; Sun, 22 Apr 2012 14:44:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 748mTOqrlNsm for ; Sun, 22 Apr 2012 14:43:59 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id C46EB21F8573 for ; Sun, 22 Apr 2012 14:43:53 -0700 (PDT) Received: by dady13 with SMTP id y13so20404851dad.27 for ; Sun, 22 Apr 2012 14:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uv3Z2Lokz3H3b+mpB3fY31BlkJ4WyV6YKZJvTvg+Kmc=; b=MKdvTk9+eOc7pJeUBev8D7xDBl5e8hpukPeEiViadHntBUwrh8clZfkjzFTvm+6Gcf GffXG72MX2lykxikj0sRDK5vyZscuqIOjdeqxJoVSgieAvGjltOR3rINkWmCfYBz5pzw 4m3xh9xzIEQ4Zn7NSxmy/ngu03ye5cCGcr+idI2MCMe74OTsdK7T39ABEtQ+SKxDC0FW YPtNjY+0qTINzlovjyYMke6dt3Kw7D4zR7oAD+JTM00nApQZ3D2Y6A5BirMoqqY41GgV EWZJYEpQXM7yAdeeTZZbgpSaINRf2o8bsu4KiXOopjWLfx9mFrFdgOgduRhKsbpt6w9Q rkHg== Received: by 10.68.237.163 with SMTP id vd3mr10576473pbc.33.1335131033606; Sun, 22 Apr 2012 14:43:53 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net. [67.127.58.62]) by mx.google.com with ESMTPS id pg6sm12391084pbb.41.2012.04.22.14.43.51 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 14:43:52 -0700 (PDT) Message-ID: <4F947B8D.2000008@gmail.com> Date: Sun, 22 Apr 2012 14:43:41 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Apr 2012 11:26:59 -0700 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 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, 22 Apr 2012 21:44:00 -0000 On 4/22/2012 1:58 PM, Barry Leiba wrote: > OLD > After six years, sufficient experience and evidence have been > collected that the experiment thus created can be considered > concluded, and a single protocol can be advanced. This document > presents those findings. > > I would prefer that this document avoid making pronouncements and > stating these kinds of opinions ("a single protocol can be advanced"). > The point of this draft is to document results. +1 > OLD > Due to the absence of consensus behind one or the other, and because > Sender-ID supported use of the same policy statement defined by SPF, > the IESG at the time was concerned that an implementation of > Sender-ID might erroneously apply that statement to a message and, > depending on selected recipient actions, could improperly interfere > with message delivery. > > This seems to have a significant SPF bias. May I suggest this?: SPF defined the record. It was there first. Sender ID came afterwards, creating the overload. A 'bias' in this case has rather solid historical precedent. > NEW > Due to the absence of consensus behind one or the other and because > SPF and Sender-ID supported use of the same policy statement with > different semantics, the IESG at the time was concerned that > implementations of SPF or Sender-ID might erroneously apply a > statement that had been published with the semantics of the other, > and, depending on selected recipient actions, could improperly > interfere with message delivery. My above comment notwithstanding, this wording looks fine to me, and in general I concur with this sort of neutral language. > OLD > It is important to note that this document makes no direct technical > comparison of the two protocols in terms of correctness, weaknesses, > or use case coverage. The email community at large has already done > that. > > I suggest "has already done that through its deployment choices." > Otherwise, one might wonder where the comparison that's been done is > documented. ok. > OLD > 3. Although the two mechanisms often used different email addresses > as the subject being evaluated, no data collected showed any > substantial operational benefit (e.g., cheaper processing, > improved accuracy) to using Sender-ID over SPF. > > I suggest "to using either mechanism over the other." Hmmm. Different issue: Often the email addresses are the same. It's the /fields/ that are /always/ different. I suggest changing the wording to say "email address fields". Tidbits of other cleanup: 3. Although the two mechanisms often use different email address fields for evaluation, no data collected showed any substantial operational benefit (e.g., cheaper processing, improved accuracy) to using one mechanism over the other.. > OLD > 3. The absence of significant adoption of the [SUBMITTER] extension, > [SENDER-ID], and [PRA], indicates that there is not a strong > community prepared to develop those mechanisms beyond > experimental status. > > I would MUCH rather see this reported factually, without further > opinion. Something like this: > > NEW > 3. The absence of significant adoption of the [SUBMITTER] extension, > [SENDER-ID], and [PRA], indicates that there is not a strong > community deploying and using these protocols. Here, I think I disagree. Part of the analysis can reasonably note that the analysis period has gone a long time and that a failure to archive much traction after this long is not likely to produce better traction in the future. > OLD > 4. Continued widespread use of [SPF] indicates it is worthy of > consideration for the Standards Track. > > I suggest this: > NEW > 4. [SPF] has widespread implementation and deployment, comparable > to that of many Standards Track protocols. > > -- Security Considerations -- > > OLD > This document contains information for the community, akin to an > implementation report, and does not introduce any new security > concerns. Its implications could, in fact, resolve some. > > That last sentence seems odd. Unless you want to be specific about it, > I suggest removing it. ok. > -- Informative References -- > > We can always argue whether an Informational document, by its nature, > can have "normative" references. There's nothing to argue about. Many Informational documents are specifications. Specifications dictate behavior (within the context of the specifications.) Some of the behaviors that are dictated fundamentally rely on external specifications that are cited. Language that dictates behavior is called 'normative'. This includes such essential citations. I think this is a reasonable summary of the issue: http://stackoverflow.com/questions/6420522/what-does-normative-and-non-normative-mean-in-reference-to-xml I suspect the envisioned debate is caused by confusing normative-ness with standards status... > Still, in the sense that we use it > here, references that are central to the understanding of the document > at hand are usually considered to be normative. DNS is arguable, but > I'd say no. I think the references to PRA, SENDER-ID, SPF, and > SUBMITTER are normative. You think that SPF or Sender ID could function without the DNS specification??? That is, what is it you think might be arguable about classing it as a normative reference? d/ -- Dave Crocker bbiw.net From dcrocker@gmail.com Mon Apr 23 10:09: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 84FDD21F86FD for ; Mon, 23 Apr 2012 10:09:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMh4lajz+Ajq for ; Mon, 23 Apr 2012 10:09:47 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id E5D7821F8701 for ; Mon, 23 Apr 2012 10:09:47 -0700 (PDT) Received: by dady13 with SMTP id y13so21913004dad.27 for ; Mon, 23 Apr 2012 10:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=913IE+EEIqfsGEeBv81+ajOEPaMJxzBjMgepPNjPqoE=; b=TATv74nXkAqGkdFgj4SxhAAZ17r86LhC67xu2cPKyE7JmHk/yZHxevye0L40ay+5JT wDWL8kyTpbZbeaTkQypDTbKVFLbnfSQBuEzCPG2H/G8s7fYMUPU2IqVtUhk1iUW8jxUj e7j7aIfUtUJ6wXuk7NMbGXqwIh5FfNXI9xTAZ8uJu6Opd2jHMzbS9Nj66wVaJSmYiIWX 0Myur3t7RMk6n+QBDOqR1B5nrCIsGcWwiSHy/EBCOsy4CAE4peI/j5i5rBSHQC+lCiaC g4LjC2LyAPDuS9/Vc2oWuLhIwqUR3dXj7hQqbDcSrMvQAOhBUemGojwsr6FiJQ7DINsb tVdQ== Received: by 10.68.129.65 with SMTP id nu1mr13422286pbb.18.1335200987761; Mon, 23 Apr 2012 10:09:47 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net. [67.127.58.62]) by mx.google.com with ESMTPS id o2sm14849108pbq.61.2012.04.23.10.09.45 (version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 10:09:46 -0700 (PDT) Message-ID: <4F958CCF.5010706@gmail.com> Date: Mon, 23 Apr 2012 10:09:35 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4F947B8D.2000008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Apr 2012 11:27:06 -0700 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 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, 23 Apr 2012 17:09:48 -0000 On 4/23/2012 9:19 AM, Barry Leiba wrote: > You think that SPF or Sender ID could function without the DNS > specification??? That is, what is it you think might be arguable about > classing it as a normative reference? > > [Barry] No. I'm saying that you need to understand SPF, etc, to > understand this doc, but you probably don't need to understand DNS to > understand this doc. Of course you do. naming hierarchy. wildcards. RRs (TXT). All of those are core DNS constructs and they need to be understood for the SPF spec, at the risk of otherwise misconfiguring or misapplying SPF. > Normativity isn't transitive. Hold on. Just a sec. OK. My head is now back together. The profundity of the deep philosophical point took me by surprise. And yet I think I agree with you, if the point is that any citations that are normative need to be cited as normative on a case-by-case basis, as appropriate to the document. That said, one would hope that there are some fairly concrete guidelines for what qualifies. Otherwise it's all ad hoc-ery. d/ -- Dave Crocker bbiw.net From sm@elandsys.com Tue Apr 24 11:32: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 68A1621E8042 for ; Tue, 24 Apr 2012 11:32:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq9ogtThgcrb for ; Tue, 24 Apr 2012 11:32: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 86E2021E8015 for ; Tue, 24 Apr 2012 11:32:22 -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 q3OIW0uD014069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 11:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335292333; i=@elandsys.com; bh=XFO3TOIiLv8yWoO8CU46KmKt7U0r+bEn3nIIuYUAupU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SKGO7W4IwoxUjdBAUG6NFq8xq2jQhEVNcSCVj0tEK3ZqDs6OGcJ/0Ho8FJKNGU1ns 41kaY5YFdrNH/uBe8IRCzw1L0q3FQv/QDp0zJRC1h1YYsNi6t71ZDjzyyuswlHZU4V bNb2kgOuvqL6jfVeLNMCKmSymgbZeWSqXcCJS+bE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335292333; i=@elandsys.com; bh=XFO3TOIiLv8yWoO8CU46KmKt7U0r+bEn3nIIuYUAupU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bhvG4kT/DwrX/ymCyE5cCZI3K+1EojSGZYzlv+upC4kOkKxwY35DQ55Kq1DwuoTvz yhprDkIXoDPdd4wVIKshF7X9m85vNqv2+3I18IZH8PWVk/qsinO76n3U8Rb64/sxur 1whs83U+r3FgOB2fnrjBAHB1MojGLxPGtxELU+Qc= Message-Id: <6.2.5.6.2.20120424112013.09adb0d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Apr 2012 11:30:46 -0700 To: Dave Crocker From: S Moonesamy In-Reply-To: <4F96EE34.50106@gmail.com> References: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120424104130.09ca5450@resistor.net> <4F96EE34.50106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Barry Leiba Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:32:23 -0000 Hi Dave, At 11:17 24-04-2012, Dave Crocker wrote: >I'm having some posting problems from some of my accounts. They are >persistent. > >I didn't cancel the messages. I saw the notices about messages posted from your current email address. I didn't approve the messages as we had a conversation some time back about me approving the messages before you had the time to cancel them. I am not sure whether that conversation was about this mailing list. There are three messages, including the one you sent a few minutes ago, in the moderator queue. I approved them and I'll approve other messages as usual. If you still have problems posting to this mailing list, please let me know. Regards, S. Moonesamy SPFBIS WG co-chair From dhc@dcrocker.net Tue Apr 24 11: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 94AC121E809A for ; Tue, 24 Apr 2012 11:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0tiG-Gja65s for ; Tue, 24 Apr 2012 11:44:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B310721E8015 for ; Tue, 24 Apr 2012 11:44:20 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3OIiJVA016567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Apr 2012 11:44:20 -0700 Message-ID: <4F96F479.8070708@dcrocker.net> Date: Tue, 24 Apr 2012 11:44:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120424165837.3747.64469.idtracker@ietfa.amsl.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]); Tue, 24 Apr 2012 11:44:20 -0700 (PDT) Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt 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, 24 Apr 2012 18:44:21 -0000 On 4/24/2012 10:22 AM, Barry Leiba wrote: > I note that Dave Crocker > made two substantive comments that I got directly, but that didn't > show up on the mailing list (he did CC the list, so I don't know why > they're not there). In those, he said that the [DNS] reference should > also be normative, and I think he's right because of the discussion of > RR types. I've been having some mail-posting problems. For the record, here's what I sent... -------- Original Message -------- Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 Date: Sun, 22 Apr 2012 14:43:41 -0700 From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking To: Barry Leiba CC: spfbis@ietf.org On 4/22/2012 1:58 PM, Barry Leiba wrote: > OLD > After six years, sufficient experience and evidence have been > collected that the experiment thus created can be considered > concluded, and a single protocol can be advanced. This document > presents those findings. > > I would prefer that this document avoid making pronouncements and > stating these kinds of opinions ("a single protocol can be advanced"). > The point of this draft is to document results. +1 > OLD > Due to the absence of consensus behind one or the other, and because > Sender-ID supported use of the same policy statement defined by SPF, > the IESG at the time was concerned that an implementation of > Sender-ID might erroneously apply that statement to a message and, > depending on selected recipient actions, could improperly interfere > with message delivery. > > This seems to have a significant SPF bias. May I suggest this?: SPF defined the record. It was there first. Sender ID came afterwards, creating the overload. A 'bias' in this case has rather solid historical precedent. > NEW > Due to the absence of consensus behind one or the other and because > SPF and Sender-ID supported use of the same policy statement with > different semantics, the IESG at the time was concerned that > implementations of SPF or Sender-ID might erroneously apply a > statement that had been published with the semantics of the other, > and, depending on selected recipient actions, could improperly > interfere with message delivery. My above comment notwithstanding, this wording looks fine to me, and in general I concur with this sort of neutral language. > OLD > It is important to note that this document makes no direct technical > comparison of the two protocols in terms of correctness, weaknesses, > or use case coverage. The email community at large has already done > that. > > I suggest "has already done that through its deployment choices." > Otherwise, one might wonder where the comparison that's been done is > documented. ok. > OLD > 3. Although the two mechanisms often used different email addresses > as the subject being evaluated, no data collected showed any > substantial operational benefit (e.g., cheaper processing, > improved accuracy) to using Sender-ID over SPF. > > I suggest "to using either mechanism over the other." Hmmm. Different issue: Often the email addresses are the same. It's the /fields/ that are /always/ different. I suggest changing the wording to say "email address fields". Tidbits of other cleanup: 3. Although the two mechanisms often use different email address fields for evaluation, no data collected showed any substantial operational benefit (e.g., cheaper processing, improved accuracy) to using one mechanism over the other.. > OLD > 3. The absence of significant adoption of the [SUBMITTER] extension, > [SENDER-ID], and [PRA], indicates that there is not a strong > community prepared to develop those mechanisms beyond > experimental status. > > I would MUCH rather see this reported factually, without further > opinion. Something like this: > > NEW > 3. The absence of significant adoption of the [SUBMITTER] extension, > [SENDER-ID], and [PRA], indicates that there is not a strong > community deploying and using these protocols. Here, I think I disagree. Part of the analysis can reasonably note that the analysis period has gone a long time and that a failure to archive much traction after this long is not likely to produce better traction in the future. > OLD > 4. Continued widespread use of [SPF] indicates it is worthy of > consideration for the Standards Track. > > I suggest this: > NEW > 4. [SPF] has widespread implementation and deployment, comparable > to that of many Standards Track protocols. > > -- Security Considerations -- > > OLD > This document contains information for the community, akin to an > implementation report, and does not introduce any new security > concerns. Its implications could, in fact, resolve some. > > That last sentence seems odd. Unless you want to be specific about it, > I suggest removing it. ok. > -- Informative References -- > > We can always argue whether an Informational document, by its nature, > can have "normative" references. There's nothing to argue about. Many Informational documents are specifications. Specifications dictate behavior (within the context of the specifications.) Some of the behaviors that are dictated fundamentally rely on external specifications that are cited. Language that dictates behavior is called 'normative'. This includes such essential citations. I think this is a reasonable summary of the issue: http://stackoverflow.com/questions/6420522/what-does-normative-and-non-normative-mean-in-reference-to-xml I suspect the envisioned debate is caused by confusing normative-ness with standards status... > Still, in the sense that we use it > here, references that are central to the understanding of the document > at hand are usually considered to be normative. DNS is arguable, but > I'd say no. I think the references to PRA, SENDER-ID, SPF, and > SUBMITTER are normative. You think that SPF or Sender ID could function without the DNS specification??? That is, what is it you think might be arguable about classing it as a normative reference? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Tue Apr 24 11:49: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 8DD7021F8692 for ; Tue, 24 Apr 2012 11:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IkJYG1tXQfk for ; Tue, 24 Apr 2012 11:49:35 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 747DF21F868A for ; Tue, 24 Apr 2012 11:49:33 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1swu1j0030ZaKgw01swuQm; Tue, 24 Apr 2012 09:56:54 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=dqudcSL6bu4NoCINdYMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 09:56:33 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5aopaYAgAGPAWA= Date: Tue, 24 Apr 2012 16:56:32 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928100C72@exch-mbx901.corp.cloudmark.com> References: <20120423100752.GQ99904@verdi> In-Reply-To: <20120423100752.GQ99904@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335286614; bh=EX1FDGDr8cz1XTTF/8CaA4Rz+s93iWsA9oG8FZWJOtA=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KAkIAQWX/7W2c04yAQ2x1/XZM15Qb696GgcWRmey9p0p3CA/rcTf6cYBRNEFDigwi amlr/vc3xiJltEwn2ru3YLWhS5ZZyzVZRwE8dle12kV1DiGRRUHKWx4SeZmHrrP4Jp SbfgWCutfrVQ1Ae1u/5Gm9Il9Y0NW6jAx7FfETKI= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:49:35 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Leslie > Sent: Monday, April 23, 2012 3:08 AM > To: Barry Leiba > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > If, OTOH, you get Ted Hardie's approval to either of those statments, > it'd be OK with me. I asked, and he's not interested in getting involved due to workloads, and = probably some PTSD. -MSK From msk@cloudmark.com Tue Apr 24 11:53: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 74A4A21E8042 for ; Tue, 24 Apr 2012 11:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBUn7C6UgxbW for ; Tue, 24 Apr 2012 11:53:16 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 611EE21E8015 for ; Tue, 24 Apr 2012 11:53:16 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1t151j0010ZaKgw01t15SS; Tue, 24 Apr 2012 10:01:05 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=TFlDA43ftUwA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=UorN8W0AsddBR7n4ihcA:9 a=Lr7FgknFOVOTcAUkUO8A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 10:00:44 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt Thread-Index: AQHNIjt/8wp/QpgekkCkeiki0ytcsZaqMrWQ Date: Tue, 24 Apr 2012 17:00:43 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928100CA5@exch-mbx901.corp.cloudmark.com> References: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> In-Reply-To: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335286865; bh=Z9zxtwMzg6HW46N6Ni6cGn3r5/Lo3s4iPKF2RIiSN5c=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=k+m8CB3dN5X4oh8vl1/y3e+Gb6CgJ2xTFjUwHqqJ0ESKWsh127/2Q66Sly2uDZ9TZ VMWOiZ0AD4WnYMwx6dLA+jjFIWMtKO7vAFgib3lqEZNkWjhxgonW3s9euB3GhiTafn 3vO+nKJ3ugcEmY+Cv/sLsxQzToaPYgodGw704r48= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:53:17 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Tuesday, April 24, 2012 9:59 AM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt >=20 > 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. >=20 > Title : Resolution of The SPF and Sender ID Experiments > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-06.txt > Pages : 11 > Date : 2012-04-24 > [...] Changes in this version: - all of Barry's suggestions included - clarify that only syntactically valid replies were included in the DNS nu= mbers -MSK From msk@cloudmark.com Tue Apr 24 11:54: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 E8EF021E8089 for ; Tue, 24 Apr 2012 11:54:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGgn7MSsLvwI for ; Tue, 24 Apr 2012 11:54:13 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7611221E8015 for ; Tue, 24 Apr 2012 11:54:13 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1uZe1j0030ZaKgw01uZfYx; Tue, 24 Apr 2012 11:33:39 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=MJriabll c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=HcTNm8uZ3MNFMvLOPv8A:9 a=a4AAwfrnJ2NHvHV5QYoA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=FD-SqP4oV34zd7MS:21 a=xJnbK4UJHl906_sf:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 11:33:39 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5an1bqAgAJ4wJA= Date: Tue, 24 Apr 2012 18:33:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928101238@exch-mbx901.corp.cloudmark.com> References: <4F947B8D.2000008@gmail.com> In-Reply-To: <4F947B8D.2000008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335292419; bh=sApLp4CLGv8pFzvosgacneg0xLrnA61gmUEj9elyuVk=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LRNBeS8HBuLrPM5olr/L8QGFqhAxagTIuAG0iBpr9pMBWnz+dsBuxoDVO4t8AUZ6u +EzKNBqr3Zg1Bje8xgUBhWl+4wgCJoEOkD2ur5zS/0+C3M3yL2Kc/QBl/cXqHPLtFZ gZgjKcd506hV2VVRmGZMJeyFpdadlzdfvPiAJ7lQ= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:54:14 -0000 I'm also having sending problems this morning, so apologies for the apparen= t delay and the burst that will occur when the backlog clears. And these t= weaks didn't make it into -06 since they were just released from moderation= . > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave Crocker > Sent: Sunday, April 22, 2012 2:44 PM > To: Barry Leiba > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > > OLD > > 3. Although the two mechanisms often used different email addresse= s > > as the subject being evaluated, no data collected showed any > > substantial operational benefit (e.g., cheaper processing, > > improved accuracy) to using Sender-ID over SPF. > > > > I suggest "to using either mechanism over the other." >=20 > Hmmm. Different issue: Often the email addresses are the same. It's > the /fields/ that are /always/ different. I suggest changing the > wording to say "email address fields". Done. > > OLD > > 3. The absence of significant adoption of the [SUBMITTER] extensio= n, > > [SENDER-ID], and [PRA], indicates that there is not a strong > > community prepared to develop those mechanisms beyond > > experimental status. > > > > I would MUCH rather see this reported factually, without further > > opinion. Something like this: > > > > NEW > > 3. The absence of significant adoption of the [SUBMITTER] extensio= n, > > [SENDER-ID], and [PRA], indicates that there is not a strong > > community deploying and using these protocols. >=20 > Here, I think I disagree. Part of the analysis can reasonably note that > the analysis period has gone a long time and that a failure to archive > much traction after this long is not likely to produce better traction > in the future. I think those are practically synonymous. > You think that SPF or Sender ID could function without the DNS > specification??? That is, what is it you think might be arguable about > classing it as a normative reference? OK, [DNS] is now Normative. -MSK From msk@cloudmark.com Tue Apr 24 11:58: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 45A1E21E809D for ; Tue, 24 Apr 2012 11:58:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfkbR+I-QeW3 for ; Tue, 24 Apr 2012 11:58:18 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7B19A21E8088 for ; Tue, 24 Apr 2012 11:58:18 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 1uTA1j0030as01C01uTAXT; Tue, 24 Apr 2012 11:27:10 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=MJriabll c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=R3_z1xM1jp4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=TEVLWca6Fhgld1J6gxMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=XMuYiAcpIVqyWfm-:21 a=lFT1cnbbUzJKwN0x:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 11:27:10 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] How about using SurveyMonkey to ask mail admins how they use SPF? Thread-Index: AQHNIjoptVxOwsJ5TEy1GiFcp11H/JaqrQ4AgAAPDwD//48IIA== Date: Tue, 24 Apr 2012 18:27:10 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928101213@exch-mbx901.corp.cloudmark.com> References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F96E016.1030905@tana.it> <20120424181059.GM55967@mail.yitter.info> In-Reply-To: <20120424181059.GM55967@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335292030; bh=WYcn984bGezuxSiurjBO/BCG0DEZFg0bS/Q2U2IOkSQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=S03kw/kAhVjBGwu0ukymr+2YY3aHsEOG0a47DaZBAa2nLyMpBOBE50ARkTJvPpoCd upjzz5M0bcQSCpa5HcDWkx8WOVkS88cTSimh36Vnf9y6CfFbkBy7Nh3mQ1HS1ler9+ bM2Y5kUNeBnTU4XNoOxz96wPtPO5eBcPBxLdjhA8= Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 24 Apr 2012 18:58:19 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Tuesday, April 24, 2012 11:11 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how= they use SPF? >=20 > The evidence we have does not ask anyone to provide their opinion about > what they think they do. Instead, it takes actual evidence from > deployed systems. I grant you that the cross-section of deployed > systems is narrow. It would be considerably better if we had a way of > soliciting logs from a wider array of mail providers, or if we had a > tool that people could run across their mail logs to answer certain > questions. In the absence of someone stepping up to do all that work > (and to convince people to share their logs with us), I don't think a > survey of admins is the right answer. I'd prefer to stick with > narrowly empirical data and draw conclusions from that, with the caveat > that we are assuming these mail systems are representative of all mail > systems. A note to the effect of your last sentence seems appropriate to add to the = document. -MSK From internet-drafts@ietf.org Tue Apr 24 12:04: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 60A9721F8787; Tue, 24 Apr 2012 12:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cGdk86cxFIA; Tue, 24 Apr 2012 12:04:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC0321F8781; Tue, 24 Apr 2012 12:04:42 -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.01p1 Message-ID: <20120424190442.3697.25094.idtracker@ietfa.amsl.com> Date: Tue, 24 Apr 2012 12:04:42 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Tue, 24 Apr 2012 19:04:43 -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 : Resolution of The SPF and Sender ID Experiments Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-07.txt Pages : 11 Date : 2012-04-24 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Because of possible interoperability issues, particularly but not only those created by simultaneous use of the two protocols by a receiver, the IESG was unable to determine technical consensus and decided it was best to publish all of RFC4405, RFC4406, RFC4407 and RFC4408 as Experimental documents. The IESG invited the community to observe their deployments for a period of time, and expressed hope for later convergence of opinion. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ From msk@cloudmark.com Tue Apr 24 12:07: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 9C20321E80BE for ; Tue, 24 Apr 2012 12:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y-QIeCyQOqg for ; Tue, 24 Apr 2012 12:07:16 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id E66CD21E80BD for ; Tue, 24 Apr 2012 12:07:16 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1v7d1j0010ZaKgw01v7dEQ; Tue, 24 Apr 2012 12:07:37 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=F2Is80RiDhcA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=5kdXndSPKeKxFkndk6MA:9 a=daMNDKKn_6pBJZaFF40A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 12:07:16 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] I-D Action: draft-ietf-spfbis-experiment-07.txt Thread-Index: AQHNIk0dgLmo6FBHCUmG5fZCEUHYzpaqVauQ Date: Tue, 24 Apr 2012 19:07:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928101338@exch-mbx901.corp.cloudmark.com> References: <20120424190442.3697.25094.idtracker@ietfa.amsl.com> In-Reply-To: <20120424190442.3697.25094.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335294457; bh=hMefotW8RyhzxViW7rW9Pi0UGjDW5wA7rx0M7t2yJbY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=DV2Oq5wCYbC94qWg/ov9Fd7rRuYKbskag0c6O+udxsv2r01QV5of+6LICLBlL733L pGW2N9BgUsMuX+w8flM5CjUGtyiN2OWtz2ZZiQ3d4QqQkB0HJlbpldJ+96KDF+p6fO fG7BFyVgjNuRkau10jcClr9ykXIszMjTZTF0vq0k= Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Tue, 24 Apr 2012 19:07:17 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Tuesday, April 24, 2012 12:05 PM > To: i-d-announce@ietf.org > Cc: spfbis@ietf.org > Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-07.txt >=20 > 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. >=20 > Title : Resolution of The SPF and Sender ID Experiments > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-07.txt > Pages : 11 > Date : 2012-04-24 > [...] - include Dave's suggestions, now that he's out of email jail - add reference to RFC5507 in the appendix - add a note that our data are admittedly a cross-section of a complete Int= ernet survey Co-chairs, I believe this is ready for Working Group Last Call. -MSK From msk@cloudmark.com Tue Apr 24 12:16: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 68C2421E80A4 for ; Tue, 24 Apr 2012 12:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FylOCU0Wjt49 for ; Tue, 24 Apr 2012 12:16:13 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9F50C21E8097 for ; Tue, 24 Apr 2012 12:16:12 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1vGZ1j0020ZaKgw01vGZHT; Tue, 24 Apr 2012 12:16:33 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=XplqSab69mvFeSkpBs0A:9 a=5HqY9-NOj3gnySuCbLYA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=l3v_lM9MB44WcsQu:21 a=DgUcOdrRW9gkQR-3:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 12:16:11 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anwbsggAETc4D//6ThEIAAgQKAgAFgppA= Date: Tue, 24 Apr 2012 19:16:11 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928101397@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335294993; bh=HpIkHTNu7t0uHW4NFkMpVvbRmCbcMrftCcXXuEW+G7Y=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=HcTxP46CFbx+Cht+7+4RKx6JWu0gAPUyxlTYCAlkmcS0zwRl/JG0SvmWY6J6oUqC4 9zM2E4HvwWv34IeZaNYD9Lk8oqvwJzFRZNz2TW/o3SrhTw1Rb4OdqU0vcz4PU4FIVg 6R7RD4Uk1kMxWDGBftreLwpfnllfATsKUyBHXtlQ= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:16:14 -0000 [resending; original appears to have gone missing] > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On=20 > Behalf Of Dotzero > Sent: Monday, April 23, 2012 8:14 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > You stated that their accuracies are comparable. Given the known=20 > weakness of PRA (based on emperical data/testing), that is an=20 > incorrect statement. Suppose PRA was a random number generator rather than a heuristic. If the = data show that SPF and Sender ID thus concur 95% of the time, then I'd say = SPF is as accurate as a random number generator. The result is not an analysis of the compared mechanisms, and we specifical= ly say that already. It only observes that they concur at a specific rate.= And given that, it doesn't make sense to claim one is substantially more = accurate than the other, because it plainly isn't. > The whole point of SPF (and presumably SIDF) is to mitigate abuse. You=20 > have not provided complete details about the dataset you are referring=20 > to so it is hard to draw detailed conlusions regarding key > points: >=20 > 1) What percentage of the dataset does not have a Sender field? > 2) For data points where there is a Sender field, what percentage of=20 > those data points have a Sender field that is aligned with the Mail=20 > From (and conceivably From)? > 3) What percentage of the messages were "abusive"? Would the mail=20 > stream selected be a likely target for the particular type of abuse I=20 > am pointing out? If not, why would you expect to see this particular=20 > type of abuse? I don't agree that any of these are material to answering the question. Suppose you're comparing two commercial spam filters. You don't get to kno= w the guts of them because that's proprietary, but you can observe the blac= k box output, which is to say they each tag x% of mail as spam or not spam.= Now suppose that after your evaluations, the report says both of them tag= messages the same way 95% of the time. I claim that, processing speeds no= t withstanding, they're basically the same in terms of accuracy. I'm not s= aying they are 95% accurate, but I am saying that 95% of the time their acc= uracy (whatever it is) is the same. Now, assuming you don't actually care = about the difference between 95% and 95.1%, are you going to claim this is = an invalid test, merely because you don't know the internal mechanics of th= e two filters? > 4) To what extent is the dataset representative of the mail streams=20 > that various types and sizes of receivers might receive? That is, is=20 > the dataset truly representative or are there potential issues with=20 > self selection, etc? If self-selection of the data renders a data set invalid, then the entire d= ocument is invalid. The data we have come from a handful volunteers who di= d the work to construct and execute the surveys and report findings. We ha= ve the fortune that at least two of them are sizable participants (Hotmail = and Cisco). If you would like to run such a survey yourself and ensure your view of the= world is also represented, or procure such surveys from whatever set of so= urces you think would make the results more even, then by all means please = do so. -MSK From spf2@kitterman.com Tue Apr 24 12:27: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 B167021E80BE for ; Tue, 24 Apr 2012 12:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r2xWXHV-wse for ; Tue, 24 Apr 2012 12:27:54 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9485821E80B9 for ; Tue, 24 Apr 2012 12:27:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6BF8420E40E9; Tue, 24 Apr 2012 15:27:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335295674; bh=jyNXJoCFGi3UlnxI+c1EWk15TRpfmqZeVUu/s5BhOuc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=R0Nj9jj9EbbTYrVNP+ObCL0xu290xOjQkXDgp2MVpH9yEnh0+Ttgl7jij6v4mnM67 jyEEJbExTelQg5iZW9WBP3XAHBKkALkiLigkrRXSwQLCiBQ0sx13h32xMhT0t+9/gk qHsj4ZhsaTrFpZTwDm5ydssnZrU/0D9/Snh+8oF8= Received: from scott-latitude-e6320.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 ESMTPSA id 4D65620E4089; Tue, 24 Apr 2012 15:27:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 24 Apr 2012 15:27:46 -0400 Message-ID: <4254996.5MjnMl37EW@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120424190442.3697.25094.idtracker@ietfa.amsl.com> References: <20120424190442.3697.25094.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Tue, 24 Apr 2012 19:27:55 -0000 "The two protocols made use of this same policy statement and some specific (but different) logic to evaluate whether the email client sending or relaying a message was authorized to do so." still really bothers me because I think it is factually incorrect. SPF designated a policy statement record and used it. Sender ID designated a policy statement record and used both it and the SPF record. Papering this over is wrong. I don't expect it to change, but, FWIW, I really disapprove. Other than that, I agree it's ready for last call. Scott K From johnl@iecc.com Tue Apr 24 12:35: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 52A5921E80CE for ; Tue, 24 Apr 2012 12:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.039 X-Spam-Level: X-Spam-Status: No, score=-111.039 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHNFCk0Jth0D for ; Tue, 24 Apr 2012 12:35:25 -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 5CBB121E80D5 for ; Tue, 24 Apr 2012 12:35:25 -0700 (PDT) Received: (qmail 12779 invoked from network); 24 Apr 2012 19:35:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Apr 2012 19:35: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=4f97007c.xn--yuvv84g.k1204; i=johnl@user.iecc.com; bh=YGzMN6zcK4m5gkm031G3jIgqD/6iojyPkb9dImAWjr8=; b=pTpO1j/L/aE6YwPmH3fjeF48PY7dK2ZmHC7oJsbLKZvZ4kmmw8eaMeeW4B/wglyOaBeZOd1XUP/0DPDw0M75usNXVLJISZ/RTzRkjLB2cackYkgbeSgWzsPm1c6LA37dzpfuxhtkdfBVRhDht60zsI0i/CWiT60gYAIUvJBDmqo= 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=4f97007c.xn--yuvv84g.k1204; olt=johnl@user.iecc.com; bh=YGzMN6zcK4m5gkm031G3jIgqD/6iojyPkb9dImAWjr8=; b=E26ykkmsj9l3q6xxUJE5NESLFEtLzD0cjGpIKTe+bLu7F2N3jgPguzlWAalXqKriHW6fIE74Yy7uVwMj4mjM2pXfBC47yJSLloeaRnRYIoHyJiouqvSSw7RiukV5XVh4bhxyx+UzkrvAPTEEARbJ2izrF+q8AfISVUzdeHsT0ig= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Apr 2012 19:35:02 -0000 Message-ID: <20120424193502.65566.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120424181059.GM55967@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ajs@anvilwalrusden.com Subject: Re: [spfbis] no surveys, please, was How about using SurveyMonkey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:35:26 -0000 >The evidence we have does not ask anyone to provide their opinion >about what they think they do. Instead, it takes actual evidence from >deployed systems. I grant you that the cross-section of deployed >systems is narrow. It would be considerably better if we had a way of >soliciting logs from a wider array of mail providers, or if we had a >tool that people could run across their mail logs to answer certain >questions. I suppose, but the reality of the mail ecosystem is that a small group of providers handles a large fraction of the mail, with an extremely long tail of medium and small systems that handle ever smaller mail streams. We happen to have data from a couple of the largest systems, and we have empirical evidence that gives us a pretty good idea of what other large mail sysetms do with SPF. So it may be narrow, but it's not small. I find it hard to imagine that we would find anything interestingly different if we could survey 10,000 other mail systems. Does anyone really believe that there is significant use of type 99 records anywhere? Does anyone but Ale think that there are significant numbers of mail recipients doing reject on SPF fail? (Or even if there were, that there is any possibility of amending RFC 5321?) There is nothing we could plausibly learn from a survey that would change what we're going to do in the next few months: we'll clean up the nits in 4408, deprecate type 99 records, perhaps figure out some politically acceptable way to say that nobody uses Sender-ID, and that's it. R's, John From dhc@dcrocker.net Tue Apr 24 12:36: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 8EEF321F8787 for ; Tue, 24 Apr 2012 12:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.713 X-Spam-Level: X-Spam-Status: No, score=-5.713 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SYheOfh9UQS for ; Tue, 24 Apr 2012 12:36:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D67D21F8786 for ; Tue, 24 Apr 2012 12:36:08 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3OJa7N5017735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Apr 2012 12:36:07 -0700 Message-ID: <4F97009C.9020805@dcrocker.net> Date: Tue, 24 Apr 2012 12:35:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120424190442.3697.25094.idtracker@ietfa.amsl.com> <4254996.5MjnMl37EW@scott-latitude-e6320> In-Reply-To: <4254996.5MjnMl37EW@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]); Tue, 24 Apr 2012 12:36:07 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-07.txt 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, 24 Apr 2012 19:36:08 -0000 On 4/24/2012 12:27 PM, Scott Kitterman wrote: > "The two protocols made use of this same policy statement and some specific > (but different) logic to evaluate whether the email client sending or relaying > a message was authorized to do so." still really bothers me because I think it > is factually incorrect. > > SPF designated a policy statement record and used it. Sender ID designated a > policy statement record and used both it and the SPF record. Papering this > over is wrong. It does not paper it over. It ignores the question of precedence and, instead noting the fact of dual use. It's not that precedence isn't an isn't an interesting question. It's that it is irrelevant to the current topic. Don't fight battles that distract from the current work. One could imagine a separate Informational discussion paper that reviews the history of this topic, possibly suggesting things that could have been avoided and ways that things could have been handled better. Such a paper might be a useful lesson for public discussion of protocol evolution. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Tue Apr 24 12:36: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 30C2F21F87C4 for ; Tue, 24 Apr 2012 12:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juF3Wk4MwPfq for ; Tue, 24 Apr 2012 12:36:54 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5F57B21F87C1 for ; Tue, 24 Apr 2012 12:36:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 1smv1j0010as01C01smvMG; Tue, 24 Apr 2012 09:46:55 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=M8uMe8edo4wfEhMP_iMA:9 a=rNYZplzNxfAO12uFMEkA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=3D1JrRmhIsUskFcU:21 a=pz5Iruyhz6rRWP87:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 09:46:34 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anwbsggAETc4D//6ThEIAAgQKAgAEzQQA= Date: Tue, 24 Apr 2012 16:46:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928100BF7@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335286015; bh=Zjx3WGtkTM9KoDnjPH0YkjabEdTHhTbbDuHhjq+YVvU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=DT3WQSsIJFpuN6su8l9ur9EYhi8wWLVTekIe+eI0RlN+r3FzNXe+oHF3k56GOxZDt xbLudVdTGWu3jQJ2Ev96h4TH/gbTIC6mmrxVzEU7LhraeaA8yOWco4hB49PV3cGhBg YuDWrvhXJ0yL9fNEs8vHePQhGOfxm118sRD8M3MY= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:36:55 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dotzero > Sent: Monday, April 23, 2012 8:14 AM > To: Murray S. Kucherawy > Cc: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > You stated that their accuracies are comparable. Given the known > weakness of PRA (based on emperical data/testing), that is an incorrect > statement. Suppose PRA was a random number generator rather than a heuristic. If the = data show that SPF and Sender ID thus concur 95% of the time, then I'd say = SPF is as accurate as a random number generator. The result is not an analysis of the compared mechanisms, and we specifical= ly say that already. It only observes that they concur at a specific rate.= And given that, it doesn't make sense to claim one is substantially more = accurate than the other, because it plainly isn't. > The whole point of SPF (and presumably SIDF) is to mitigate > abuse. You have not provided complete details about the dataset you are > referring to so it is hard to draw detailed conlusions regarding key > points: >=20 > 1) What percentage of the dataset does not have a Sender field? > 2) For data points where there is a Sender field, what percentage of > those data points have a Sender field that is aligned with the Mail > From (and conceivably From)? > 3) What percentage of the messages were "abusive"? Would the mail > stream selected be a likely target for the particular type of abuse I > am pointing out? If not, why would you expect to see this particular > type of abuse? I don't agree that any of these are material to answering the question. Suppose you're comparing two commercial spam filters. You don't get to kno= w the guts of them because that's proprietary, but you can observe the blac= k box output, which is to say they each tag x% of mail as spam or not spam.= Now suppose that after your evaluations, the report says both of them tag= messages the same way 95% of the time. I claim that, processing speeds no= t withstanding, they're basically the same in terms of accuracy. I'm not s= aying they are 95% accurate, but I am saying that 95% of the time their acc= uracy (whatever it is) is the same. Now, assuming you don't actually care = about the difference between 95% and 95.1%, are you going to claim this is = an invalid test, merely because you don't know the internal mechanics of th= e two filters? > 4) To what extent is the dataset representative of the mail streams > that various types and sizes of receivers might receive? That is, is > the dataset truly representative or are there potential issues with > self selection, etc? If self-selection of the data renders a data set invalid, then the entire d= ocument is invalid. The data we have come from a handful volunteers who di= d the work to construct and execute the surveys and report findings. We ha= ve the fortune that at least two of them are sizable participants (Hotmail = and Cisco). If you would like to run such a survey yourself and ensure your view of the= world is also represented, or procure such surveys from whatever set of so= urces you think would make the results more even, then by all means please = do so. -MSK From msk@cloudmark.com Tue Apr 24 12:42: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 04D0321F87F9 for ; Tue, 24 Apr 2012 12:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W18hMU4oAkAb for ; Tue, 24 Apr 2012 12:42:00 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6C01121F87F8 for ; Tue, 24 Apr 2012 12:42:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 1ssR1j0010as01C01ssRPG; Tue, 24 Apr 2012 09:52:25 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=fZKcf9osSv6LYp3yFSIA:9 a=6DF3SCX4pQ9Y-s-a5U4A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 09:52:04 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anwbsggAETc4D//6ThEIAAgQKAgAEzQQCAAATXIA== Date: Tue, 24 Apr 2012 16:52:03 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928100C3D@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280FED0D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FF5C4@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335286345; bh=CzCi/trX1TfU2aohxHuhqn8y90zKlN+lwHvmkTVVW+o=; h=From:To:Subject:Date:Message-ID:References:Content-Type: Content-Transfer-Encoding:MIME-Version; b=r627wikSh165B6UosIZ6D3G8fyTxmXKl+YScwYOUGntgXl6I1yTDkZw/vwiIZ2YxV xUvWWz3g5woL8kK9adfhCrBRTjFWqkj1AvoMdLIIqiPQtr3guPFumglpvLCXu/S/AF qVR2muP1LVU/TsEQ/v+DeHAvaUSQMx+vpqUiWdDc= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:42:01 -0000 > -----Original Message----- > From: Murray S. Kucherawy > Sent: Tuesday, April 24, 2012 9:47 AM > To: spfbis@ietf.org > Subject: RE: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > If self-selection of the data renders a data set invalid, then the > entire document is invalid. The data we have come from a handful > volunteers who did the work to construct and execute the surveys and > report findings. We have the fortune that at least two of them are > sizable participants (Hotmail and Cisco). >=20 > If you would like to run such a survey yourself and ensure your view of > the world is also represented, or procure such surveys from whatever > set of sources you think would make the results more even, then by all > means please do so. Moreover, one will always be able to argue that some corner of the email ec= osystem was excluded from our report unless we get universal participation.= That means this task is impossible. I'd like to publish this before I ex= pire. -MSK From msk@cloudmark.com Tue Apr 24 12:43: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 E8D0321F880F for ; Tue, 24 Apr 2012 12:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urNBckJ-U55M for ; Tue, 24 Apr 2012 12:43:58 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8FB21F87FA for ; Tue, 24 Apr 2012 12:43:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1std1j0030ZaKgw01stdPh; Tue, 24 Apr 2012 09:53:37 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=w0_tcEhzsP4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=Fwq7WybbK03v2WDsciMA:9 a=8lNyc3fhs-n7A55m7ZcA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 09:53:16 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Review of draft-ietf-spfbis-experiment-05 Thread-Index: AQHNIMqwFmLLWp0VJEuOTXJcBTjdz5anzRGA//+OihCAAHiZAP//5QzwgAB83oD//46t8AAPXI6AABXK2AAAAN7GgAAAR9OAAAAJrwAAAoysAAAEE4eAACC0csA= Date: Tue, 24 Apr 2012 16:53:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928100C5F@exch-mbx901.corp.cloudmark.com> References: <3365685.ptXhF5PY8S@scott-latitude-e6320> <20120423145947.GH55520@mail.yitter.info> <63583111.FeGGmhBaS4@scott-latitude-e6320> <4F959B1F.6020007@Commerco.Net> In-Reply-To: <4F959B1F.6020007@Commerco.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335286417; bh=nEJJdNwHJ7JPWIedaIlCOXnCGexPHDh4JXluqF/1AmU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=gGwr/wecAQzeKVoiRNS2I0RO8hFz5xvDuGCI1ws2emlxW0Gble4QuqEGiDAut7SM/ 9WRwWjGm69O8gMUj8UpF13Q5+zF2nKUCjw5mQsIMEBnZD7cm6GPiOnIwDcrt4Sy4Z3 3al7fczzOHI0HVO838asG4kbHMx+QE00VI8GY0hg= Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:43:59 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Commerco WebMaster > Sent: Monday, April 23, 2012 11:11 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05 >=20 > New looks cleaner. Would it be possible (and does it make sense) to > add something like - >=20 > "Measurement data gathered for both the Sender-ID and SPF experiments > indicate SPF adoption levels in the community as the preferred > protocol, thus offering the reasonable path forward." Works for me. Others? -MSK From sm@elandsys.com Tue Apr 24 13:40: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 D1DB711E808A for ; Tue, 24 Apr 2012 13:40:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tml2sSXD-B+w for ; Tue, 24 Apr 2012 13:40:30 -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 2541111E808D for ; Tue, 24 Apr 2012 13:40:30 -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 q3OKeFmB027982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 13:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335300028; i=@elandsys.com; bh=UKTs6dsZ9X3OKJdS/LU6GgaFz4jEx+Uyl6HPZVWq3bE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W6f+K/Rlav38mkWbSTr7lfNrAE4OV1LmgeN4K06P7M1ZE4IHze+OeEAxQ1NI3sg/D wu5vstW5fGMFgyTvDKPGRV7q6n/oofRTfbLIQpuvsYsnnsN2HlAHDY9axy+/XAWVMs kpqgLpMi5wAlG43q4gFI5aVkNPTuFiGVHVMAswzY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335300028; i=@elandsys.com; bh=UKTs6dsZ9X3OKJdS/LU6GgaFz4jEx+Uyl6HPZVWq3bE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=spADhBNVh8cSV+dFykE3hxs3Lupjdlqr11NBlAnLxI45ffC1xyPJQb/d1JkPN7czG mXobB8AnY7fe6NgTaSg9B95uvXP1arw/DqSLgI718ksnrl+B75tw3bQ7FLAJsd4tNs iLTEgWSyj6wmV5RWdYeNmPx6C1nIzWmvP/eJDu6w= Message-Id: <6.2.5.6.2.20120424125542.099efdf0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Apr 2012 13:37:40 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4F96E994.4050104@tana.it> References: <20120424165837.3747.64469.idtracker@ietfa.amsl.com> <4F96E994.4050104@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-06.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 20:40:30 -0000 Hi Alessandro, At 10:57 24-04-2012, Alessandro Vesely wrote: >May I ask how delivering this I-D affects the WG schedule? The I-D is >scheduled for Aug 2012. I like its findings and its conclusions, but Producing a deliverable before its milestone is not a problem. The Chairs have already commented that there is no reason the working group cannot be finished with its deliverables by the Fall. >it still misses some data that may be relevant. So, /if/ there's no >specific reason to ship it now, we could keep it dormant for a few >months and proceed as if it were shipped. That way, that missing data >could have a chance, however remote. A remote chance is like Internet dating. I can safely say that Internet dating is out of scope. :-) There should be at least a month before the IESG Evaluation. Anyone who would like to find any missing data should keep that in mind. Regards, S. Moonesamy From ajs@anvilwalrusden.com Tue Apr 24 13:44: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 40C0521F8647 for ; Tue, 24 Apr 2012 13:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkrYo0+AZX-U for ; Tue, 24 Apr 2012 13:44:57 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BFCFD21F8646 for ; Tue, 24 Apr 2012 13:44:57 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id C0C2D1ECB41C for ; Tue, 24 Apr 2012 20:44:56 +0000 (UTC) Date: Tue, 24 Apr 2012 16:44:54 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120424204450.GR55967@mail.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] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 20:44:58 -0000 Dear colleagues, This message begins a 2 week Working Group Last Call on the document draft-ietf-spfbis-experiment-07. Please perform a complete review of the document and send your remarks to the mailing list. Your chairs would like to be sure that the document really represents WG consensus in the event we forward the document to the IESG for publication. As a result, we would like to see as many reviewers as possible who state that they have read the document and approve its publication, and in no case fewer than five. In the case of those who have read and reviewed previous versions of the document, we would like evidence that you are amenable to changes that have been made in response to your comments; we will count those among the five. ("Five" is an arbitrary number intended to be a minimal threshold of review; if we can't find five people who say something is a good idea to publish, it's hard to argue that there's any interest at all.) SM will be the document shepherd for this document. This last call closes on 2012-05-09 at 00:00 UTC. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Tue Apr 24 13:49: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 3242911E8088 for ; Tue, 24 Apr 2012 13:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.046 X-Spam-Level: X-Spam-Status: No, score=-111.046 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg5RAp7Mb7M6 for ; Tue, 24 Apr 2012 13:49:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 56FF711E8074 for ; Tue, 24 Apr 2012 13:49:23 -0700 (PDT) Received: (qmail 25512 invoked from network); 24 Apr 2012 20:49:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Apr 2012 20:49:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f9711d2.xn--i8sz2z.k1204; i=johnl@user.iecc.com; bh=/T69bQ7E9vizjMDxMyx0EKTZOZwsUh+S/c7NKBhdQnA=; b=c4i6uXINe0Mib0tUy7d83GmqIBePMnmfPCg2/+zCGEiOLgJQ+e6dBTk1WONayTPMt5bGyE2J6HwJUDQzS8YVw5YC57ejYmo4nOeWlrPJB21WULyJ8gCM6bsmeMBPJUy/Ohlg9lPyDIVnjw3TnPtMrlT2pFC3yjiTqxJQIHaGaEE= 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=4f9711d2.xn--i8sz2z.k1204; olt=johnl@user.iecc.com; bh=/T69bQ7E9vizjMDxMyx0EKTZOZwsUh+S/c7NKBhdQnA=; b=bukrOQDh8wOunEONM39luXIX1GyIgmeYsmY7lpFvfAssQApBNUuKdKgqnAUPW3CLpNu6CQgqETz0OrfcYSykwsliAgiaYmFLVBOwXswTxToExpCqmJs6IkFlVx4Xu1mM9xt5XGLmu72NWrWNlM3cFPRvEVr8X25wUfb2ozRStR4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Apr 2012 20:49:00 -0000 Message-ID: <20120424204900.85846.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4F97009C.9020805@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Tue, 24 Apr 2012 20:49:24 -0000 >It does not paper it over. It ignores the question of precedence and, >instead noting the fact of dual use. > >It's not that precedence isn't an isn't an interesting question. It's >that it is irrelevant to the current topic. It does still present a technical issue. If you want to implement Sender-ID, you publish some spf/2.0 records and you're done. You don't need to know anything about SPF. If you want to implement SPF, you publish v=spf1 records, and now you have to decide what to do about Sender-ID. Here are the options I see we could recommend: 1) Learn enough about Sender-ID to publish an spf/2.0 ?all record (or something similar) so that any Sender-ID users will functionally ignore what you're doing. 2) Decide that nobody uses Sender-ID, so don't worry about it. 3) Decide that the IESG's concerns about record reuse were unwarranted, Sender-ID usually produces the same result as SPF, so don't worry about it. 4) Decide that the IESG's concerns about record reuse were warranted, so if we're going to advance SPF, we should deprecate Sender-ID. What am I missing here? R's, John From spf2@kitterman.com Tue Apr 24 16:03: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 1507D11E8089 for ; Tue, 24 Apr 2012 16:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMUbKvWPYnGv for ; Tue, 24 Apr 2012 16:03:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2346C11E8085 for ; Tue, 24 Apr 2012 16:03:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6FDD920E40E9; Tue, 24 Apr 2012 19:03:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335308590; bh=7xffL3GxgUYuaLDJLTWmtasqlrHfGJDxtyszVA9RrDw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=oAMRbq7XVvpPv+ezEW8qWXUxGYWyIe/QthZsbVkqYD/sJ9ChhqtSLtZD1F72KshQz kLwglgnumiwJV/543hXABZQWq5uGn8SGlfoRPiIDEGOE9LkgIucxefBaxx4jYLPSt4 W53oPm3rEy9m59Igq+k/oiO1/A6wVuGKWRWDRmTQ= Received: from scott-latitude-e6320.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 ESMTPSA id 5286920E4089; Tue, 24 Apr 2012 19:03:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 24 Apr 2012 19:03:07 -0400 Message-ID: <15005929.zbVvZltzQu@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120424204900.85846.qmail@joyce.lan> References: <20120424204900.85846.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] I-D Action: draft-ietf-spfbis-experiment-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: Tue, 24 Apr 2012 23:03:12 -0000 On Tuesday, April 24, 2012 08:49:00 PM John Levine wrote: ... > 1) Learn enough about Sender-ID to publish an spf/2.0 ?all record (or > something similar) so that any Sender-ID users will functionally > ignore what you're doing. ... That has been the assumption, but we don't actually know that. Receivers are supposed to treat Neutral the same as None, but they don't. As a practical matter there's no way to publish an SPF record and safely opt-out of Sender ID. Scott K From ajs@anvilwalrusden.com Tue Apr 24 16:26: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 DB2D321F85D7 for ; Tue, 24 Apr 2012 16:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPonl2t66rKt for ; Tue, 24 Apr 2012 16:26:55 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DD2EE21F85D6 for ; Tue, 24 Apr 2012 16:26:54 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id D29291ECB41C for ; Tue, 24 Apr 2012 23:26:53 +0000 (UTC) Date: Tue, 24 Apr 2012 19:26:52 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120424232642.GA55967@mail.yitter.info> References: <20120424204900.85846.qmail@joyce.lan> <15005929.zbVvZltzQu@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15005929.zbVvZltzQu@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Tue, 24 Apr 2012 23:26:56 -0000 No hat. On Tue, Apr 24, 2012 at 07:03:07PM -0400, Scott Kitterman wrote: > That has been the assumption, but we don't actually know that. Receivers are > supposed to treat Neutral the same as None, but they don't. Do I read that correctly as "nobody actually implements the protocol as specified"? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Apr 24 16:31: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 0C6C121E801F for ; Tue, 24 Apr 2012 16:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WMmYA11IGZS for ; Tue, 24 Apr 2012 16:31:23 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB5621E801B for ; Tue, 24 Apr 2012 16:31:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B232020E40E9; Tue, 24 Apr 2012 19:31:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335310282; bh=1d+t4PDCx2hGCQ4avEBrb/x/uuAWtrBTMC6hi86lasM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=mamwkLclUKHJ23VADLTnRid4Z5LZXc4vEjAG/shi5sd9OU04FYQIoW72FkZ64nMEm HLWXityuy1tjTY97zEZOQq6gtoIcu6pMbOOO/3JumoFo+65nqB+Cqb7MwUIBLJcvTy zdhRzAKn8qpUyO9ZcKdgTMY76WQj0yws3+Xm1PJc= Received: from scott-latitude-e6320.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 ESMTPSA id 988B520E4089; Tue, 24 Apr 2012 19:31:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 24 Apr 2012 19:31:21 -0400 Message-ID: <6780686.tK7zLqyZJd@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120424232642.GA55967@mail.yitter.info> References: <20120424204900.85846.qmail@joyce.lan> <15005929.zbVvZltzQu@scott-latitude-e6320> <20120424232642.GA55967@mail.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] I-D Action: draft-ietf-spfbis-experiment-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: Tue, 24 Apr 2012 23:31:24 -0000 On Tuesday, April 24, 2012 07:26:52 PM Andrew Sullivan wrote: > No hat. > > On Tue, Apr 24, 2012 at 07:03:07PM -0400, Scott Kitterman wrote: > > That has been the assumption, but we don't actually know that. Receivers > > are supposed to treat Neutral the same as None, but they don't. > > Do I read that correctly as "nobody actually implements the protocol > as specified"? No it's intended as, "The protocol specification says some things about what receivers must do. They don't always do that." We've had repeated debates about the lack of utility in specifying receiver policy. Receivers will do what they think best deals with the mail stream they are facing even if that's not what's in the RFC. Scott K From vesely@tana.it Wed Apr 25 03:17: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 3715921F8707 for ; Wed, 25 Apr 2012 03:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.63 X-Spam-Level: X-Spam-Status: No, score=-4.63 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3OAk+mWRHJJ for ; Wed, 25 Apr 2012 03:17:56 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5724C21F86F9 for ; Wed, 25 Apr 2012 03:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335349075; bh=gVYIC5UGDqzMk36Q93FB/vfLAtIFmg7aB1x24Hh8wdI=; l=1828; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WeYEPeaWyHqeHoSJZfFyu82mLH3LBrJEl/Yrdzll30MuDEZeLDvaCdYtC24x+rZWZ 7wo+LQKdW19saBgQrqnel5NtCI+saEHhOBjK+DxqJ5BvmLmVHtpVvAy3kSAiTFRx7T +DuegvjsRaV6xt6WYCqa9TMiCTKcYHEoXl652nDI= 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, 25 Apr 2012 12:17:55 +0200 id 00000000005DC033.000000004F97CF53.00005692 Message-ID: <4F97CF53.9080100@tana.it> Date: Wed, 25 Apr 2012 12:17:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120424193502.65566.qmail@joyce.lan> In-Reply-To: <20120424193502.65566.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] no surveys, please, was How about using SurveyMonkey X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 10:17:57 -0000 On Wed 25/Apr/2012 11:17:26 +0200 John Levine wrote: > > I suppose, but the reality of the mail ecosystem is that a small group > of providers handles a large fraction of the mail, with an extremely > long tail of medium and small systems that handle ever smaller mail > streams. Given that reality, I think it's not fair nor desirable to treat a few large providers as representative of many small ones. > We happen to have data from a couple of the largest systems, and we > have empirical evidence that gives us a pretty good idea of what other > large mail systems do with SPF. So it may be narrow, but it's not > small. I find it hard to imagine that we would find anything > interestingly different if we could survey 10,000 other mail systems. In theory, 10,000 providers with 10,000 messages per day move as much traffic as a provider with a hundred million messages. That's not unworthy, but difficult to reach. > Does anyone but Ale think that there are significant numbers of > mail recipients doing reject on SPF fail? I don't think that: I just don't know it. That's why I'm thinking to take a survey. The other possibility is to run the test I mentioned in http://www.ietf.org/mail-archive/web/spfbis/current/msg01224.html I have to hurry up... > There is nothing we could plausibly learn from a survey that would > change what we're going to do in the next few months: we'll clean > up the nits in 4408, deprecate type 99 records, perhaps figure out > some politically acceptable way to say that nobody uses Sender-ID, > and that's it. I agree on the schedule (albeit with a mental reservation). However, some of our readers may be developers of SPF tools, and I think they would be interested to know how many people will take the burden to answer a survey on SPF. From vesely@tana.it Wed Apr 25 04: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 1A53421F8744 for ; Wed, 25 Apr 2012 04:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qPhgHpVBQdn for ; Wed, 25 Apr 2012 04:09:50 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6949B21F8742 for ; Wed, 25 Apr 2012 04:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335352188; bh=e8++LELbXe3bNJlzgmpGIN05vOHNrLRi1svwoKKqoTw=; l=3168; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ZTdgyMPAGd7EZ7u19o58ZV73ZMUy3DJZWLklUYi3t2vt4Ia7x1YO6ljI9FuhE0rHO lzDcW75M7sQLS4SFLf7S151FNEzJqjnHn/xvon0iLJwv+cTNc+4afXra8M10HkSZ9s DfYdi8zXciKKoxHg15dHwiShusVAYmaDhrHC6jMA= 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, 25 Apr 2012 13:09:48 +0200 id 00000000005DC03F.000000004F97DB7C.000061C1 Message-ID: <4F97DB7B.2070905@tana.it> Date: Wed, 25 Apr 2012 13:09:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F96E016.1030905@tana.it> <20120424181059.GM55967@mail.yitter.info> In-Reply-To: <20120424181059.GM55967@mail.yitter.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 25 Apr 2012 11:09:57 -0000 On Wed 25/Apr/2012 12:23:38 +0200 Andrew Sullivan wrote: > On Tue, Apr 24, 2012 at 07:17:10PM +0200, Alessandro Vesely wrote: >> >>> Whom do we ask? How do we select that sample? >> >> Posting to the mailing lists we know of. > > This is approximately the worst kind of sample there is, I'm afraid. > It's actually no better than those "surveys" you see on the sidebar of > webpages. The number that comes out of it is a number, all right, but > it doesn't measure anything. An other way to find mail admins would be to write to the postmaster@ address of a number of domains, which is obviously not practicable. Given the way that domain names, network connections, and much MTA software are distributed, I see no other way to address the category. >> Well, I think we'll be able to see if answers make some sense. > > How? What that really says is, "I already know the answer; I just > want to be able to point at something to back it up." That's only true for the DNS question. > I actually think such surveys have negative value, because they > tend to be designed to give the presupposed outcome. I'll try and avoid that tendency the best I can. > Surveys are excellent ways to find out what people believe about > themselves. They're a lousy way to find out whether those beliefs are > true. Right. So you'd say the survey should focus on evaluation and expectations about SPF in general? Doesn't a value such as "I believe our domain deploys some form of SRS rewriting" measure some predisposition toward adapting to SPF requirements? > The evidence we have does not ask anyone to provide their opinion > about what they think they do. Instead, it takes actual evidence > from deployed systems. Yes, and that is probably ways more objective. I'm not proposing to /replace/ any data we already have, but to try and corroborate and augment it. > I grant you that the cross-section of deployed systems is narrow. > It would be considerably better if we had a way of soliciting logs > from a wider array of mail providers, or if we had a tool that > people could run across their mail logs to answer certain > questions. I'd agree, if it were feasible in a month. > In the absence of someone stepping up to do all that work (and to > convince people to share their logs with us), I don't think a > survey of admins is the right answer. I'd prefer to stick with > narrowly empirical data and draw conclusions from that, with the > caveat that we are assuming these mail systems are representative > of all mail systems. OTOH, those of us (possibly an extended "us") who'd step up to do that work would have to build a mail-admins channel first. Wouldn't it be neat to take a survey before investing in such an effort? I can well understand that the WG considers the data collected thus far sufficient for our needs. What I fail to grasp is why one would refuse to consider additional data. However skewed, data cannot have a negative value. Negative information --or entropy-- is when the data is forgotten or otherwise hidden. Do we think a survey could sort out such an effect?? From hsantos@isdg.net Wed Apr 25 06:50: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 257A521F85F9 for ; Wed, 25 Apr 2012 06:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.073 X-Spam-Level: X-Spam-Status: No, score=-0.073 tagged_above=-999 required=5 tests=[AWL=-1.855, BAYES_20=-0.74, GB_AFFORDABLE=1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NkDDLx2QGFc for ; Wed, 25 Apr 2012 06:50:49 -0700 (PDT) Received: from ftp.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4B26E21F856F for ; Wed, 25 Apr 2012 06:50:49 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3376; t=1335361846; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MO1zsb0yQcZCVnxelkHj5zaIKZw=; b=uQd4LZOu3+nJPqYQzaOe NXSIexraEw57so6TCOW/9WLn3n0/MFHuVPXPdSjVdgS8R0RWLKnphnDNr6phSauK GLWg/cStZxkIiDgfaa4eUEphpJEJKukmtST2dvTsiGpH4iLFBvWCwgYvX5HalUPt zZzaZFcgtDriTmm1gEx9veI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 25 Apr 2012 09:50: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4268661633.37266.2528; Wed, 25 Apr 2012 09:50:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3376; t=1335361505; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vRDG4Zf w182Ykg6SfA3Wgf3hwWNFcAPFyE11RXQCNjo=; b=uMPn4mEA+D13CQVNEIAEKW7 TGPC5ASw2t8xM/HX4AfMpAZPhxdWn6IU/Tdhbol208FYPs7zNhp1lOkmNJI1rthM rKzoYEY0nsrY/7X3m18ZCBwJhb1jVLF16Rz/2FGmzDoSG53Kh+uarlluTR8Y4yl8 52Nj/3ttJvx6o9EiiEmk= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 25 Apr 2012 09:45:05 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 572592894.3421.4052; Wed, 25 Apr 2012 09:45:04 -0400 Message-ID: <4F980119.7000700@isdg.net> Date: Wed, 25 Apr 2012 09:50:17 -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: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F96E016.1030905@tana.it> <20120424181059.GM55967@mail.yitter.info> <4F97DB7B.2070905@tana.it> In-Reply-To: <4F97DB7B.2070905@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 25 Apr 2012 13:50:52 -0000 Alessandro Vesely wrote: > I can well understand that the WG considers the data collected thus > far sufficient for our needs. What I fail to grasp is why one would > refuse to consider additional data. However skewed, data cannot have > a negative value. Negative information --or entropy-- is when the > data is forgotten or otherwise hidden. Do we think a survey could > sort out such an effect?? I don't. Never mind that you won't get the sampling needed, surveys can be skewed in any direction you want. Plus, without a doubt, based on my engineering training and nearly 25+ years of real mail system design of proprietary and open standards, I would have a completely different set of R&D questions. I don't need to concur with Mr. Sullivan, but I doubt we would even be able to get agreement on what should be the survey questions. To me, this is not rocket science. Just considering one FEATURE-BY-DESIGN part with SPF - POLICIES. In principle, what policies are affordable depends on type of service, scale and mode of operation. For example, who can afford to use a strong policy like -ALL? - LARGE PUBLIC SITES SITES, ESP, ISP, HOSTING sites could LESS afford to offer/use -ALL - SMALL TO MID PRIVATE/PUBLIC SITES could begin to look at -ALL - HOBBY, MOM&POP TO SMALL PRIVATE/PUBLIC SITES, could afford more to use -ALL and that also relates to the affordability of local deployment options for Marking vs Rejection. Thats not a hard core rule, its generally considered that the smaller you are the more nimble you are with advanced technology. Many larger companies simply do not have the luxury to "change" as fast as one wants, just drop this or that and switch to something else. Sure, they can talk about, go to meetings, trade shows, hear presentations and even present them, etc. That doesn't always mean they actually can afford the change. Big ISP can announce they will begin doing this or that, perhaps the Quality Circle meetings had help desk people say they can same money, and they do it, but find out quickly it wasn't actually cost effective with other things come out of the word works. BIG ESP can announce they will enforce XYZ in 2005, only to see in 2012, they don't. Perhaps they tried and saw it wasn't working well for them. I will suggest there are two central difference with many in the mail market: - Those who prefer to push delivery decisions to users vs those who also have system level backend focuses. The latter has been where the big changes are because traditionally it was really never the transport system business to get involved in these decisions, at least not automatically without making it an local site option. - Those who prefer to focus on GOOD MAIL filtering vs BAD MAIL filtering. Almost everything we do and basically "fight" about and also vendors "compete" when it comes to mail, has its genesis with either one or both. What they offer, how they do it, what works or doesn't work for one, is not always the same across the board, etc. There is no right or wrong, but unfortunately, it breaks down when compromise is lost in seeking the commonality - the protocol mechanics or basically "physics" of the mail system we all work with. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From ajs@anvilwalrusden.com Wed Apr 25 07:17: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 2911821F86C5 for ; Wed, 25 Apr 2012 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIJZjWt5vOPT for ; Wed, 25 Apr 2012 07:17:02 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE1921F86C1 for ; Wed, 25 Apr 2012 07:16:59 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 43EAA1ECB41C for ; Wed, 25 Apr 2012 14:16:59 +0000 (UTC) Date: Wed, 25 Apr 2012 10:16:48 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120425141644.GB60024@mail.yitter.info> References: <20120424204900.85846.qmail@joyce.lan> <15005929.zbVvZltzQu@scott-latitude-e6320> <20120424232642.GA55967@mail.yitter.info> <6780686.tK7zLqyZJd@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6780686.tK7zLqyZJd@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Wed, 25 Apr 2012 14:17:03 -0000 On Tue, Apr 24, 2012 at 07:31:21PM -0400, Scott Kitterman wrote: > On Tuesday, April 24, 2012 07:26:52 PM Andrew Sullivan wrote: > > No hat. > > > > On Tue, Apr 24, 2012 at 07:03:07PM -0400, Scott Kitterman wrote: > > > That has been the assumption, but we don't actually know that. Receivers > > > are supposed to treat Neutral the same as None, but they don't. > > > > Do I read that correctly as "nobody actually implements the protocol > > as specified"? > > No it's intended as, "The protocol specification says some things about what > receivers must do. They don't always do that." Ok, so it means _some_ people don't implement the protocol correctly. Got it. So the worry is that SPF users can't opt out of Sender ID "safely" because some purported Sender ID users actually aren't Sender ID users (i.e. they're not doing what the protocol document says to do) and don't do the right thing with the mail. Correct? (I'm not trying to be a pain; I'm trying to get clear on what the problem is supposed to be.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Wed Apr 25 07:26: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 539ED21F86D3 for ; Wed, 25 Apr 2012 07:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyxqQ7tVJDku for ; Wed, 25 Apr 2012 07:26:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 38CBA21F86C2 for ; Wed, 25 Apr 2012 07:26:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B13F720E40E9; Wed, 25 Apr 2012 10:26:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335363992; bh=eGg6tpPCPyFXnIR3BPAaTMocg/Hl3wDQ2Mj+fzQ2xwg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=B8VFrP/oYr4BNs/t64sJd9mQtsl2sn0A+ahGXyWuH2azCWEdAqaNhP8E4DCKXmaXH PujODshJb3Ve41hBmE1GjYDQCSO+UmuXx2jKv78kDIMk/bh77qfmhBevE45NzusNMN VeV7fFz4idbaVGgP9NxS0bokKru04f/yw8DsihXM= Received: from scott-latitude-e6320.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 ESMTPSA id 9626A20E4099; Wed, 25 Apr 2012 10:26:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Apr 2012 10:26:31 -0400 Message-ID: <13912503.Z2y5EZPqFD@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120425141644.GB60024@mail.yitter.info> References: <20120424204900.85846.qmail@joyce.lan> <6780686.tK7zLqyZJd@scott-latitude-e6320> <20120425141644.GB60024@mail.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] I-D Action: draft-ietf-spfbis-experiment-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: Wed, 25 Apr 2012 14:26:39 -0000 On Wednesday, April 25, 2012 10:16:48 AM Andrew Sullivan wrote: > On Tue, Apr 24, 2012 at 07:31:21PM -0400, Scott Kitterman wrote: > > On Tuesday, April 24, 2012 07:26:52 PM Andrew Sullivan wrote: > > > No hat. > > > > > > On Tue, Apr 24, 2012 at 07:03:07PM -0400, Scott Kitterman wrote: > > > > That has been the assumption, but we don't actually know that. > > > > Receivers > > > > are supposed to treat Neutral the same as None, but they don't. > > > > > > Do I read that correctly as "nobody actually implements the protocol > > > as specified"? > > > > No it's intended as, "The protocol specification says some things about > > what receivers must do. They don't always do that." > > Ok, so it means _some_ people don't implement the protocol correctly. > Got it. > > So the worry is that SPF users can't opt out of Sender ID "safely" > because some purported Sender ID users actually aren't Sender ID users > (i.e. they're not doing what the protocol document says to do) and > don't do the right thing with the mail. Correct? (I'm not trying to > be a pain; I'm trying to get clear on what the problem is supposed to > be.) >From a strict standards perspective, I think that's correct. The real world isn't so black and white. I do think that at some point if SPF is a standards track protocol and Sender ID isn't, someone needs to say that the Sender ID experiment is over (where over means "don't do that anymore." I'm not sure when, who, or how, but I think "Using a standards track protocol entangles you in an experiment you can't escape" is not a sustainable position. Scott K From hsantos@isdg.net Wed Apr 25 08:14: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 2E58821F875A for ; Wed, 25 Apr 2012 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYtGN1+3TMXa for ; Wed, 25 Apr 2012 08:14:18 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B505221F8736 for ; Wed, 25 Apr 2012 08:14:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1589; t=1335366846; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=L10jwJ7Y9iDMRFQ1kSR9SLJQD0U=; b=tYXhaZO1IpVTxtfQ/MDF YGnF92MewV/T8ppJfthVR5vZK1A+n3UgIeMNxGs3L4RIdKaX4K1Dah3DJuNfBEo2 tAuZIuAy3VqyDUqwm85GNZ8hYGE/KWOBCzAs455R8DZII0nHloii6xOiyXCjSabl 6GxcOK8Q+QQ9C2ITPOBg5pU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 25 Apr 2012 11:14: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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4273661777.37266.4332; Wed, 25 Apr 2012 11:14:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1589; t=1335366502; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=A3KOgxO nxQvwqjU55xhLyac/l91hBnTVfp1tjpQBUg4=; b=tvh3oGNuJSV4WnXOPKGl+XH Wk8nQBCD6BzDswB7WUu2Dlwu0kvrydgtVSuyaldUkbC07o/+ZoEqI8t4C4YLTeKc ikGR5IXP7AIB5ebUaKQWNBkMSnPx1tCosH6lPauI+vBReK67MOsBQHcsib5cBIUq qtcZPHqNUjqI/kH3D/fE= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 25 Apr 2012 11:08:22 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 577590847.3428.7720; Wed, 25 Apr 2012 11:08:22 -0400 Message-ID: <4F98149F.1070700@isdg.net> Date: Wed, 25 Apr 2012 11:13:35 -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: <20120424204900.85846.qmail@joyce.lan> <15005929.zbVvZltzQu@scott-latitude-e6320> <20120424232642.GA55967@mail.yitter.info> <6780686.tK7zLqyZJd@scott-latitude-e6320> <20120425141644.GB60024@mail.yitter.info> In-Reply-To: <20120425141644.GB60024@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Wed, 25 Apr 2012 15:14:19 -0000 Andrew Sullivan wrote: >> No it's intended as, "The protocol specification says some things about what >> receivers must do. They don't always do that." > > Ok, so it means _some_ people don't implement the protocol correctly. > Got it. > > So the worry is that SPF users can't opt out of Sender ID "safely" > because some purported Sender ID users actually aren't Sender ID users > (i.e. they're not doing what the protocol document says to do) and > don't do the right thing with the mail. Correct? (I'm not trying to > be a pain; I'm trying to get clear on what the problem is supposed to > be.) I always believed this was a "Maximum Coverage" issue more than incorrect publishing possibilities. Legend: SMTP-SPF1 MSA/MDA with 4408 support only SMTP-SPF2 MSA/MDA with 4405-4408 support DNS-SPF1 Domain/MTA publishing for 4408 support DNS-SPF2 Domain/MTA publishing for 4405-4408 support +====================================+ | SPF1 vs SPF2 | | Receiver vs Publishing Support | | | | +-------------------------| | | SMTP-SPF1 | SMTP-SPF2 | |----------+------------+------------| |DNS-SPF1 | OK | OK | |----------+------------+------------| |DNS-SPF2 | conflict | OK | +------------------------------------+ For the market base focusing on SIDF, it may come with the presumption that all receivers will cover SPF1 and SPF2. Not possible with a pure 4408 deployment site unless dual SPF1 records were added as well by the SIDF. Anyway, you get the idea. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From ajs@anvilwalrusden.com Wed Apr 25 08:23: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 2B29921F8797 for ; Wed, 25 Apr 2012 08:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5DN0Bn7MXrR for ; Wed, 25 Apr 2012 08:23:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F221F86D7 for ; Wed, 25 Apr 2012 08:23:35 -0700 (PDT) Received: from mail.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 mail.yitter.info (Postfix) with ESMTPSA id 946921ECB41C for ; Wed, 25 Apr 2012 15:23:34 +0000 (UTC) Date: Wed, 25 Apr 2012 11:23:32 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120425152326.GE60024@mail.yitter.info> References: <20120424204900.85846.qmail@joyce.lan> <6780686.tK7zLqyZJd@scott-latitude-e6320> <20120425141644.GB60024@mail.yitter.info> <13912503.Z2y5EZPqFD@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13912503.Z2y5EZPqFD@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Wed, 25 Apr 2012 15:23:36 -0000 No hat. On Wed, Apr 25, 2012 at 10:26:31AM -0400, Scott Kitterman wrote: > > From a strict standards perspective, I think that's correct. The real world > isn't so black and white. Got it, thanks. Unfortunately, we're writing protocols, and not a guide to the real world, so we have to interpret things protocol-y, i.e. in a way I wouldn't actually run my life. > ID isn't, someone needs to say that the Sender ID experiment is over (where > over means "don't do that anymore." I'm not sure when, who, or how, but I > think "Using a standards track protocol entangles you in an experiment you > can't escape" is not a sustainable position. "Don't use the Internet?" The fact is that once something is deployed, it is _impossible_ to get it back, and the IETF doesn't have an enforcement arm. It seems likely to me that the real mechanism for making Sender ID wither is the gradual disappearance of support for it, as something else shows up on the standards track. (The DNS is littered with this stuff, for instance. A6 records and queries haven't disappeared yet. EDNS0 support isn't universal more than 10 years after its specification. We _still_ see people convinced that DNS only uses UDP. And so on.) But there will no doubt be future occasions somewhere, sometime, for someone to write "Sender ID Considered Harmful". That is not today and not in this WG, I think (again, no hat). A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Wed Apr 25 09: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 3299C21F8615 for ; Wed, 25 Apr 2012 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.07 X-Spam-Level: X-Spam-Status: No, score=-111.07 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd2raODr9r9G for ; Wed, 25 Apr 2012 09:16:37 -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 B8EB421F85DF for ; Wed, 25 Apr 2012 09:16:36 -0700 (PDT) Received: (qmail 44592 invoked from network); 25 Apr 2012 16:16:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Apr 2012 16:16:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f982362.xn--9vv.k1204; i=johnl@user.iecc.com; bh=iY9J4IvDtpMy2D2N0faai95jOzx1grY4vgkxSnwz9Xc=; b=CEKEMV32OmtZkDgPkKFmBnqwdkOLYYGtRIRw+HRHCNBKpd8TECD3+OJNMTt2MbmuibH2MTj98LXpmirIlpXumOs5C3Wr0k/SipkUUIG5iCw27vSN+kx5UngstNA0jV7q9RVsDwOpsnGImU83Ft5YYcNxQGhzbECEMKJ36bqe+68= 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=4f982362.xn--9vv.k1204; olt=johnl@user.iecc.com; bh=iY9J4IvDtpMy2D2N0faai95jOzx1grY4vgkxSnwz9Xc=; b=jfp0fDzdMTPFB5OJrdN+SoODIEccbgZgJAEMkewcLnjBdrkiy6Fa5vyp14xyNTSlcJqbQBdd+B0soHG9SGjpZaB5BR4JFUp5O6WmGREdaG60E4unxVb6lfU+j7/D6IcCaGSLCilN0z8F96wUyBNk2bENPK8qJFd1adAXHe3Ghk8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Apr 2012 16:16:12 -0000 Message-ID: <20120425161612.81340.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120425141644.GB60024@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ajs@anvilwalrusden.com Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-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: Wed, 25 Apr 2012 16:16:39 -0000 >So the worry is that SPF users can't opt out of Sender ID "safely" >because some purported Sender ID users actually aren't Sender ID users >(i.e. they're not doing what the protocol document says to do) and >don't do the right thing with the mail. Correct? More or less. The protocol documents are clear enough about how to compute an answer of yes, no, or a few flavors of maybe. But it only offers vague hints about what to do with that answer, partly because there are so many ways to do spam filtering, partly becuase we don't know what they are, since there are so many ways that spam filters make their special secret sauce. DKIM happens to say quite specifically that a broken signature is equivalent to no signature, but you won't find anything like that in S-ID or SPF saying that some result is equivalent to no result. R's, John From barryleiba.mailing.lists@gmail.com Wed Apr 25 11:56: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 238DC21F8900 for ; Wed, 25 Apr 2012 11:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6X0m09XkGTQ for ; Wed, 25 Apr 2012 11:56:39 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 114E421F8902 for ; Wed, 25 Apr 2012 11:56:37 -0700 (PDT) Received: by ghbg16 with SMTP id g16so470093ghb.31 for ; Wed, 25 Apr 2012 11:56:36 -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=cnwg39II4s/C3NRF6EdHGHePFDvzrepr5ps6ZRw0fxc=; b=RyxzuRnjN7lpRkPgzUGWttAurxT1bd9pWhfCTXPWoaPshDN3xRZKEyY3S5+dT8MALo Cp7NDPf0sntqkmpC9uy9uuj1i/Im3Z7GTHlTqDKgBJ9qdo9qRyjvKytiU+oY8/fg3lX3 cToXvAtTePPfDox8PtM7g0ASA/SCrJGoAOmX9BA8faGcnYsr4izRgcBMVOpfe+P5cY1X D9GAB0qSDM7rnhcyEBywZMkIHsPK7Yp10bQHdmDI2gqmimdsdEO7SD1xJWqWEstOftDc ESqRYclapfZAaBzkc9a0fNqX+Z8Y+iqYz90/KiisLcLqzhDSWV3HnI+ZvAfp+k4YZEvP gmAw== MIME-Version: 1.0 Received: by 10.236.76.41 with SMTP id a29mr3478586yhe.117.1335380196721; Wed, 25 Apr 2012 11:56:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.152.14 with HTTP; Wed, 25 Apr 2012 11:56:36 -0700 (PDT) In-Reply-To: <20120424204450.GR55967@mail.yitter.info> References: <20120424204450.GR55967@mail.yitter.info> Date: Wed, 25 Apr 2012 14:56:36 -0400 X-Google-Sender-Auth: a_aQZRSiUlkZwDzCoVZozTvvujo Message-ID: From: Barry Leiba To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:56:44 -0000 > This message begins a 2 week Working Group Last Call on the document > draft-ietf-spfbis-experiment-07. I just gave -07 the once-over, and I'm happy. It's ready. Barry, participatorily From spf2@kitterman.com Wed Apr 25 12:21: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 4FF3921F887A for ; Wed, 25 Apr 2012 12:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmhCP8KHrFLj for ; Wed, 25 Apr 2012 12:21:12 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7A87B21F8861 for ; Wed, 25 Apr 2012 12:21:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DC2FA20E40E9; Wed, 25 Apr 2012 15:21:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335381671; bh=Aq9TtuqJVO8UQPPcWwNhZUkabzo2lRYOIzHQzI/wAVM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SRCbBcyi2Ghvm1v0Wfa3elqL1/lJHJBM9ZKRYfZ9qIlk/FClzlCYT/Xmx7gudHYJi gkqat7QTXOxCONQBZ4OaEoypY1IDIABPe9YNfigaKgEaJPNPPjJbcOoEKTm10HBiOu JDCCw8KED3t3IyXAvRQr+I7y3x6XkQgw1v56zG3M= Received: from scott-latitude-e6320.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 ESMTPSA id C1B2E20E4099; Wed, 25 Apr 2012 15:21:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Apr 2012 15:21:11 -0400 Message-ID: <3884385.iEYvhWo1DI@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120424204450.GR55967@mail.yitter.info> References: <20120424204450.GR55967@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:21:13 -0000 On Tuesday, April 24, 2012 04:44:54 PM Andrew Sullivan wrote: > Dear colleagues, > > This message begins a 2 week Working Group Last Call on the document > draft-ietf-spfbis-experiment-07. > > Please perform a complete review of the document and send your remarks > to the mailing list. I've got one point I really don't like in this draft, but I understand I'm on the rough end of the consensus, so +1 from me for publication as is unless there's some unexpected groundswell of support for my view on how record reuse is described. Scott K From spf2@kitterman.com Wed Apr 25 12:34: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 1A3E021F8955 for ; Wed, 25 Apr 2012 12:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmGNp2iDjnmY for ; Wed, 25 Apr 2012 12:33:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7E221F8945 for ; Wed, 25 Apr 2012 12:33:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F080C20E422C; Wed, 25 Apr 2012 15:33:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335382435; bh=Aq9TtuqJVO8UQPPcWwNhZUkabzo2lRYOIzHQzI/wAVM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=B5rk02lk43M2avhyBebJnw1dKhQ1VcqrPwYZd66VYz6jP5LdUfJhGuXZlwswVyPSi AoEsegzPFVQ5uVPrVcfaLgsGSiRlbtK1EQoMFB2K2Y2L2LVRw0eTGULEp9NRTiSjW7 CGODdK5I8PNZ1og9A9Fvi3+Ih+T82YeHi+ze+JgI= Received: from scott-latitude-e6320.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 ESMTPSA id DC0E620E41CD; Wed, 25 Apr 2012 15:33:54 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Apr 2012 15:21:11 -0400 Message-ID: <3884385.iEYvhWo1DI@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <20120424204450.GR55967@mail.yitter.info> References: <20120424204450.GR55967@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:34:00 -0000 On Tuesday, April 24, 2012 04:44:54 PM Andrew Sullivan wrote: > Dear colleagues, > > This message begins a 2 week Working Group Last Call on the document > draft-ietf-spfbis-experiment-07. > > Please perform a complete review of the document and send your remarks > to the mailing list. I've got one point I really don't like in this draft, but I understand I'm on the rough end of the consensus, so +1 from me for publication as is unless there's some unexpected groundswell of support for my view on how record reuse is described. Scott K From dotis@mail-abuse.org Wed Apr 25 12:40: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 7502621F892C for ; Wed, 25 Apr 2012 12:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PviAjuZ2jadQ for ; Wed, 25 Apr 2012 12:40:16 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5D121F8925 for ; Wed, 25 Apr 2012 12:40:16 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 459D717401E1 for ; Wed, 25 Apr 2012 19:39:55 +0000 (UTC) Message-ID: <4F98530B.5090502@mail-abuse.org> Date: Wed, 25 Apr 2012 12:39:55 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120425161612.81340.qmail@joyce.lan> In-Reply-To: <20120425161612.81340.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Points raised in DMARC training. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:40:17 -0000 Dear spfbis wg, A DMARC training class raised a few issues that warrant some review. Recommended use of "~all" (softfail) for SPF records referenced by Mail parameters ensures DKIM has an opportunity to deal with false positives caused by forwarded email. That advice seems okay, but what was missed is that "-all" should still be used for any SPF record referenced by the EHLO/HELO parameter. DMARC also recommends walking up one domain level when searching for SPF records, which is perhaps the cause of the confusion. This is not as bad as the exposure created by use of SPF PTR mechanisms matching any sub-domain. The SPF records for EHLO/EHLO should be published at the EHLO/HELO host domains, and not depend upon one-step domain walking or use of PTR records. The PTR mechanism should not be recommended as this also represents a poor domain wide security practice and where resolving the mechanism also invites DNS DDoS issues. When there is an opportunity to obtain EHLO/HELO parameter "Authentication" rather than just a Mail parameter "Authorization", checking EHLO/HELO is a better practice that is able to retain SPF hardfails with the benefit of safe early rejection. Regards, Douglas Otis From dotzero@gmail.com Wed Apr 25 13:09: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 E3D5221F88FF for ; Wed, 25 Apr 2012 13:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sopYM+p3cjzn for ; Wed, 25 Apr 2012 13:09:25 -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 4DFFC21F88FA for ; Wed, 25 Apr 2012 13:09:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so410979vbb.31 for ; Wed, 25 Apr 2012 13:09:24 -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=HJ2BfxmionHqV/YwO1Lup+jPE52xYnAYtUyxlNONhZ0=; b=M88CsB5bXexIV7ps8fsgOejgrBLgxCIRLAtxJRI5iVguvxx2Q+dwbaozn5UK2Ykk/Z yhowC1p7RcN7FSE3/gamCAXEGyeiws1hX2js8obSqWqdnRmgD4JYjMGWtWR27uw3wDOa pxY+FyNnQ6kErLkfUOTRaSznQdcVtL1beEpMWq7I+gX3szzGSoM1pbhKzj+c9jwpYw5O E9uJxh79ARYCwqy4w/qqv8qf8ikb9Qtw0jqOmYyYcAhrfSKT4o4MJ7uhyUOPsnSb53YM lQNEIecHtn3LTzfkl4iI910TDaVps+HzWb6HRcQAKa3POoFJR3xMasr25vokLLkbUney Cbaw== MIME-Version: 1.0 Received: by 10.220.59.3 with SMTP id j3mr3967885vch.58.1335384564376; Wed, 25 Apr 2012 13:09:24 -0700 (PDT) Received: by 10.220.178.198 with HTTP; Wed, 25 Apr 2012 13:09:24 -0700 (PDT) In-Reply-To: <3884385.iEYvhWo1DI@scott-latitude-e6320> References: <20120424204450.GR55967@mail.yitter.info> <3884385.iEYvhWo1DI@scott-latitude-e6320> Date: Wed, 25 Apr 2012 16:09:24 -0400 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:09:26 -0000 On Wed, Apr 25, 2012 at 3:21 PM, Scott Kitterman wrote: > On Tuesday, April 24, 2012 04:44:54 PM Andrew Sullivan wrote: >> Dear colleagues, >> >> This message begins a 2 week Working Group Last Call on the document >> draft-ietf-spfbis-experiment-07. >> >> Please perform a complete review of the document and send your remarks >> to the mailing list. > > I've got one point I really don't like in this draft, but I understand I'm on > the rough end of the consensus, so +1 from me for publication as is unless > there's some unexpected groundswell of support for my view on how record reuse > is described. > > Scott K > I agree with Scott on the record re-use issue. Leaving this unaddressed is problematic. I was originally neutral about SIDF and figured leave well enough alone. Now I believe we need to address this. Other than this issue I am +1 for publication. Mike From dotis@mail-abuse.org Wed Apr 25 13:09: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 4B59421F88FF for ; Wed, 25 Apr 2012 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUwlB22I1awO for ; Wed, 25 Apr 2012 13:09:58 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id D9EEC21F88FC for ; Wed, 25 Apr 2012 13:09:58 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id C7E0D174028F for ; Wed, 25 Apr 2012 20:09:58 +0000 (UTC) Message-ID: <4F985A16.7040804@mail-abuse.org> Date: Wed, 25 Apr 2012 13:09:58 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120424204450.GR55967@mail.yitter.info> <3884385.iEYvhWo1DI@scott-latitude-e6320> In-Reply-To: <3884385.iEYvhWo1DI@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:09:59 -0000 On 4/25/12 12:21 PM, Scott Kitterman wrote: > On Tuesday, April 24, 2012 04:44:54 PM Andrew Sullivan wrote: >> Dear colleagues, >> >> This message begins a 2 week Working Group Last Call on the document >> draft-ietf-spfbis-experiment-07. >> >> Please perform a complete review of the document and send your remarks >> to the mailing list. > I've got one point I really don't like in this draft, but I understand I'm on > the rough end of the consensus, so +1 from me for publication as is unless > there's some unexpected groundswell of support for my view on how record reuse > is described. Dear Scott, I agree with your concern. There is no clean way to avoid Sender-ID results other than publishing a replicate SPF record with "spf2.0/mfrom (spfv=1 content)" headers. This header should prevent any Sender-ID results from being reported and not just "neutral" results from the recommended alternative. It remains unknown what is the best strategy to avoid Sender-ID delivery issues, but it seems Hotmail has found DKIM + SPF provides results as good or better than those using the PRA algorithm. Waiting for adoption of outbound DKIM and removal of PRA may still be a long time into the future, but it might also be sooner than you might expect. Regards, Douglas Otis From spf2@kitterman.com Wed Apr 25 13:35: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 C0BF321F8879 for ; Wed, 25 Apr 2012 13:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W103fhgJKI9 for ; Wed, 25 Apr 2012 13:35:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8F72821F8836 for ; Wed, 25 Apr 2012 13:35:35 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C3C6B20E40E9; Wed, 25 Apr 2012 16:35:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335386130; bh=VNuaRRnL57iIr+Rkyhdce97kF2sNroVYYhBJEVYOKEo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=f6jKxUC9jXCecEdaItev9d0XMRFJVeMBCOFyvODwp0WiiJQLEnbl+cVj8elRU15gU K2Y4U/OOoyw+GYGapQWsxspelJ7Y0zHbHCDK99TFPR8/Z8QMJ0dA9iSxdH0sHHtcs9 qxB30H+y2fJZGM+dBaE8jEztz42aP3XXZpaLHe+M= Received: from scott-latitude-e6320.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 ESMTPSA id AAC6F20E4099; Wed, 25 Apr 2012 16:35:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Apr 2012 16:35:30 -0400 Message-ID: <2831667.lSv4LSHuh3@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <4F98530B.5090502@mail-abuse.org> References: <20120425161612.81340.qmail@joyce.lan> <4F98530B.5090502@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Points raised in DMARC training. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:35:36 -0000 On Wednesday, April 25, 2012 12:39:55 PM Douglas Otis wrote: ... > DMARC also recommends walking up one domain level when searching for SPF > records, which is perhaps the cause of the confusion. ... There were pre-RFC 4408 drafts that also suggested things like this. It turned out to be a bad idea. I strongly doubt it's improved with age. DMARC should not suggest such things. Scott K From johnl@iecc.com Wed Apr 25 13: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 4FBC221F8777 for ; Wed, 25 Apr 2012 13:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.079 X-Spam-Level: X-Spam-Status: No, score=-111.079 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHwZyUFrb6SI for ; Wed, 25 Apr 2012 13:36: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 842C821F8879 for ; Wed, 25 Apr 2012 13:36:47 -0700 (PDT) Received: (qmail 99186 invoked from network); 25 Apr 2012 20:36:41 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Apr 2012 20:36:41 -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=4f986059.xn--i8sz2z.k1204; i=johnl@user.iecc.com; bh=eI9r7xUxs2o36QJ0c7QfBa4GPyjeDS8Nc+klYy4xf98=; b=M3rCQTpzI1/pOZWbKeOF2cqlsKjh/x5MVkM0J0FpmeQJc/OuFWoFTgy93CovyckzgS76q+GMgno/RBkGmY3ynFZaYPQqv7D4Hsve2tO1I1ptIvZ+hdtXYuiEv1Vmo616zYrmN2Xr/KlxFrk9y4PQ++uU7isSbh0DsnIUFcCoY34= 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=4f986059.xn--i8sz2z.k1204; olt=johnl@user.iecc.com; bh=eI9r7xUxs2o36QJ0c7QfBa4GPyjeDS8Nc+klYy4xf98=; b=ePoZJ0yOTFcxZ44JzPZrd6pY3UF6zY9no2wNpa7BlUBFnVrUcDzJ+/KQPfK/sVHbGcKVc4bxq9IHP6Kv4ROsK45AM1s68NH9hbzoja0QMfvyqrlHG4QTCYpCsCtlXsqNALqycHTJ03ubEdSy5RiLRt3F/8+rr0UhPqw73fBegME= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Apr 2012 20:36:19 -0000 Message-ID: <20120425203619.75808.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <3884385.iEYvhWo1DI@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] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:36:48 -0000 >I've got one point I really don't like in this draft, but I understand I'm on >the rough end of the consensus, so +1 from me for publication as is unless >there's some unexpected groundswell of support for my view on how record reuse >is described. I agree with Scott. It's OK as it is, but we really should say somewhere (not necessarily this document) that if we're planning to advance SPF, we should deprecate Sender-ID due to the TXT record collision issue. R's, John From msk@cloudmark.com Wed Apr 25 13: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 9685B21F8895 for ; Wed, 25 Apr 2012 13:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6qd+ntHF9VP for ; Wed, 25 Apr 2012 13:43:54 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3EC21F8894 for ; Wed, 25 Apr 2012 13:43:53 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 2LkE1j0030ZaKgw01LkEAv; Wed, 25 Apr 2012 13:44:14 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=K4ag7lqI c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=yKP8Nv2cYNMA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=MY9gt07EUMIXn2KaM3YA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 25 Apr 2012 13:43:53 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] Points raised in DMARC training. Thread-Index: AQHNIxs/Puwyukkb30OhuvuIHzbd/pasdQsA//+M05A= Date: Wed, 25 Apr 2012 20:43:51 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928102A35@exch-mbx901.corp.cloudmark.com> References: <20120425161612.81340.qmail@joyce.lan> <4F98530B.5090502@mail-abuse.org> <2831667.lSv4LSHuh3@scott-latitude-e6320> In-Reply-To: <2831667.lSv4LSHuh3@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335386654; bh=evhPOurfCZM6stvS1yo6dXf6Z+RTQvauXBUl7RcYVWE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=E08wcy50lkvVrOC1ZcgWq+2OBz0nGLfgfbC38mNKH+d+FVXj3AjFF2tHf3nPeYc+Y 8bt8D5gfWEscYSPBiAsMhYXHh2v4Gry/hpI59aV54FZPR6SoaeVK41n78qo7gDOPvK WZ6YoAl9rSyOPs1Z5+HA6A2brK3rPKkndtq68bAU= Subject: Re: [spfbis] Points raised in DMARC training. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:43:54 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, April 25, 2012 1:36 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Points raised in DMARC training. >=20 > On Wednesday, April 25, 2012 12:39:55 PM Douglas Otis wrote: > ... > > DMARC also recommends walking up one domain level when searching for > > SPF records, which is perhaps the cause of the confusion. > ... >=20 > There were pre-RFC 4408 drafts that also suggested things like this. > It turned out to be a bad idea. I strongly doubt it's improved with > age. DMARC should not suggest such things. DMARC doesn't. And I daresay this is off-topic for spfbis. -MSK From msk@cloudmark.com Wed Apr 25 15:35: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 1E07D21F87F9 for ; Wed, 25 Apr 2012 15:35:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n6xmyp5fjPV for ; Wed, 25 Apr 2012 15:35:37 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 81E7621F87F7 for ; Wed, 25 Apr 2012 15:35:37 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 2NbS1j0030as01C01NbSeZ; Wed, 25 Apr 2012 15:35:26 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=VPNfbqzX c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=g9u41mt8S1M444McznAA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=t5DdPFwS3MxWjL-I:21 a=k4jHRaED9wHfya0C:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 25 Apr 2012 15:35:26 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNIlseXt7nF5KnvEq9U7F2f34qNJasYceAgAANeQD//7KXoA== Date: Wed, 25 Apr 2012 22:35:26 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928102C75@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <3884385.iEYvhWo1DI@scott-latitude-e6320> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335393326; bh=zGqDLBHkzZDuTHjU64i3sPw2qgJ0T4uExiC5K1mHpHE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=C7Vo/BfZXwds5vM7TlRfvudtmW+xTvYJncXzz+tYVZWmPCOp1SCas8dGOhT+YqHx3 7n25YTG0X0wskxJyr8XsCdJl4XhMRhYiKzvQPXPNJ1cbEX2RvKoCO9GfYiKOp7sahK HcLRcyg/juwIbb19ugUE7ZdI03Xu4hkA2i9ouUi0= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 22:35:38 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dotzero > Sent: Wednesday, April 25, 2012 1:09 PM > To: Scott Kitterman > Cc: spfbis@ietf.org > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > I agree with Scott on the record re-use issue. Leaving this unaddressed > is problematic. I was originally neutral about SIDF and figured leave > well enough alone. Now I believe we need to address this. Other than > this issue I am +1 for publication. Based on the wording you chose here, I'm not certain you and Scott are sayi= ng the same thing. Scott is saying that we're being inaccurate by not being clear that Sender = ID made use of the SPF-defined record. How are you suggesting the experime= nt document address this, if not simply that clarification? And I'll pose = the same question to you I did to him: What does that change bring to the p= resentation of adoption data that's missing otherwise? -MSK From spf2@kitterman.com Wed Apr 25 16:14: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 0BC9721F87BC for ; Wed, 25 Apr 2012 16:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNU1pLAj5c8f for ; Wed, 25 Apr 2012 16:13:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5625A21F87B4 for ; Wed, 25 Apr 2012 16:13:59 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C0E4720E40E9; Wed, 25 Apr 2012 19:13:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335395638; bh=k0a0jtiBXEYZQc11hlm2QyNLnj98Fy5DQ5O7VzEsD4I=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=agvEcd/tn8N8x8Q2t/pdMvDFSM3hyqqV9qPUBOr97E3Qle8PNk7nS29N2d/f7+uLQ D0jmvWKEyEeUn9Z2HCbiVAXD+BXmpbM/pu7tkuucJFxRiMB0sCCqtva1F+BEVOUK83 Q0TcCNi4cJrYegpJaV+9TcyJgcLrFTq72pxykfkE= Received: from scott-latitude-e6320.localnet (34.sub-97-58-208.myvzw.com [97.58.208.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 856FB20E4099; Wed, 25 Apr 2012 19:13:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Apr 2012 19:13:29 -0400 Message-ID: <1907446.INNoivgAbl@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E003928102C75@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <9452079D1A51524AA5749AD23E003928102C75@exch-mbx901.corp.cloudmark.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] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:14:00 -0000 On Wednesday, April 25, 2012 10:35:26 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Dotzero Sent: Wednesday, April 25, 2012 1:09 PM > > To: Scott Kitterman > > Cc: spfbis@ietf.org > > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment > > > > I agree with Scott on the record re-use issue. Leaving this unaddressed > > is problematic. I was originally neutral about SIDF and figured leave > > well enough alone. Now I believe we need to address this. Other than > > this issue I am +1 for publication. > > Based on the wording you chose here, I'm not certain you and Scott are > saying the same thing. > > Scott is saying that we're being inaccurate by not being clear that Sender > ID made use of the SPF-defined record. How are you suggesting the > experiment document address this, if not simply that clarification? And > I'll pose the same question to you I did to him: What does that change > bring to the presentation of adoption data that's missing otherwise? I am OK with removing the reuse discussion from the draft because it's not needed or going back to the more correct description of it (I thought we'd agreed to do the former). I find the current biased description objectionable. If it's not needed, remove it. If it's needed, make it correct. You'll get no argument from me with either of those. Scott K From johnl@iecc.com Wed Apr 25 16:18: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 54B1F21E8051 for ; Wed, 25 Apr 2012 16:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.083 X-Spam-Level: X-Spam-Status: No, score=-111.083 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hunKMms6mC9n for ; Wed, 25 Apr 2012 16:18:28 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF4511E8076 for ; Wed, 25 Apr 2012 16:18:21 -0700 (PDT) Received: (qmail 28570 invoked from network); 25 Apr 2012 23:18:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Apr 2012 23:18: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=4f98863b.xn--30v786c.k1204; i=johnl@user.iecc.com; bh=RX9zewh91BtbjCCay7bBKmeyRh+NrElaYDtE8iIdOmE=; b=NIR5UXdUPMF0OEMlmlE/JWU2a2p/GktfUx+Gd8d+gUDp5ZaZeMwWtkSJULbLujVv3GGx5HbhSbPiOZdYEWjeReBZoTVmasQT1t0Qclx4PW3KonlExZsVDE3E6+Yfm6l8V3Js0+cfEeUiVnd4xZ+vAyU4PPEtnfdgudD21hupx8o= 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=4f98863b.xn--30v786c.k1204; olt=johnl@user.iecc.com; bh=RX9zewh91BtbjCCay7bBKmeyRh+NrElaYDtE8iIdOmE=; b=aXG449Y7VLT33zlhZ7mUKAJ50W4bN7yRAO9Qa1eSmgC0lT24aailvl1jaAbMVDgtbOXrkMPzGPjyXln59SxAUZK1dtzqTI6zsA3tS9FXizLom6ldUWkpgN7tXzt2X+CPme1JJSU4EBKSJ0+GvbMU+ajUHJcLpuRCzZi+VPwjZXw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Apr 2012 23:17:57 -0000 Message-ID: <20120425231757.76840.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E003928102C75@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:18:29 -0000 >> I agree with Scott on the record re-use issue. Leaving this unaddressed >> is problematic. I was originally neutral about SIDF and figured leave >> well enough alone. Now I believe we need to address this. Other than >> this issue I am +1 for publication. > >Based on the wording you chose here, I'm not certain you and Scott are saying the same thing. > >Scott is saying that we're being inaccurate by not being clear that Sender ID made >use of the SPF-defined record. How are you suggesting the experiment document >address this, if not simply that clarification? And I'll pose the same question to >you I did to him: What does that change bring to the presentation of adoption data >that's missing otherwise? In the context of this document, I would want to say that although the data suggest that reused records had only a minor effect in practice, we did not resolve the issue, and so long as people continue to use both SPF and Sender-ID, there remains some risk that systems that intend to publish SPF will inavertently have their mail filtered by Sender-ID. R's, John From hsantos@isdg.net Wed Apr 25 16: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 395B511E8096 for ; Wed, 25 Apr 2012 16:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf2QhCKQnJTk for ; Wed, 25 Apr 2012 16:53:36 -0700 (PDT) Received: from ftp.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1CACD11E8076 for ; Wed, 25 Apr 2012 16:53:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2237; t=1335398011; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ENepycjgdU+YRfFj1TybI+toisk=; b=QhHLOfXwB28LJi67x306 PkvCCPqu6I5gsVx6oxdAjBYj0P/xhN+qIpof206ZIeB9wWN7nILNkbA/mksfWI7d +iyWMYdwfuGeEUweRpQYarEkNGqojXGPvQDuvzwso50rs4tVnbgw9I6uMBKc/Pll pcicr1/bf6jo5SeDbwRpb0k= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 25 Apr 2012 19:53: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 v6.4.454.1) with ESMTP id 9859987.37266.4008; Wed, 25 Apr 2012 19:53:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2237; t=1335397667; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pNdA73k 2WGOtlUwZXoLuz5NsMkK3PT2KiW7D1W4QF9U=; b=klUaE0Lb/i5zvHOzpkms2bo q+YDch82wGToRqrzrdjqwyz9/XEs1f1AxU8RmyFahzQ30wSuVGPuaRHAuvhrmKnc g+slgWjw+dI0qX4raMs3vuunLS/LAsAhatRK5JWwCh09lXwKmkRycK5NHbatZJiR iBz/q0+Lx+35gaf+25f4= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 25 Apr 2012 19:47:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 608755581.3474.4200; Wed, 25 Apr 2012 19:47:46 -0400 Message-ID: <4F988E74.3020905@isdg.net> Date: Wed, 25 Apr 2012 19:53:24 -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: <20120424204450.GR55967@mail.yitter.info> <3884385.iEYvhWo1DI@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928102C75@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928102C75@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:53:37 -0000 I don't think I have seen actual cases where there is a conflict. We know of the long time claims, but did the 6+ years of experimentation actually show a history of such problems, and further, if record pairs were found to be incorrect, is it something that could not be resolved by the SIDF implementation? Is there DATA, even if isolated to a few, that showed where the conflict claim materialized? It just sounds to me that the SPF1 44408 only focus overall is implying - don't use our records for any other protocol meaning. I don't think SIDF is doing that, but the burden is on SIDF to make sure its protocols do not hurt any SPF1 4408-only deployment. IMO, the 4408 only focus with SPFBIS should not be concern about this in the same way other non-standard 4408 usages have materialize, such as the Best Guess thing, which I just read the other day with one MUAs plug-in have used and actually documented it as a NON-4408 standard method. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Dotzero >> Sent: Wednesday, April 25, 2012 1:09 PM >> To: Scott Kitterman >> Cc: spfbis@ietf.org >> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >> >> I agree with Scott on the record re-use issue. Leaving this unaddressed >> is problematic. I was originally neutral about SIDF and figured leave >> well enough alone. Now I believe we need to address this. Other than >> this issue I am +1 for publication. > > Based on the wording you chose here, I'm not certain you and Scott are saying the same thing. > > Scott is saying that we're being inaccurate by not being clear that Sender ID made use of the SPF-defined record. How are you suggesting the experiment document address this, if not simply that clarification? And I'll pose the same question to you I did to him: What does that change bring to the presentation of adoption data that's missing otherwise? > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From dotis@mail-abuse.org Wed Apr 25 18:31: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 11A5E11E80AE for ; Wed, 25 Apr 2012 18:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQvH-kj+eBZg for ; Wed, 25 Apr 2012 18:31:37 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE9F11E8085 for ; Wed, 25 Apr 2012 18:31:37 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 270291740098 for ; Thu, 26 Apr 2012 01:31:37 +0000 (UTC) Message-ID: <4F98A578.6020902@mail-abuse.org> Date: Wed, 25 Apr 2012 18:31:36 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: SPFbis discussion list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] In support of retaining Received-SPF Header Field X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 01:31:38 -0000 Dear SPFbis WG, In the minutes, reasons for retaining existing SPF results format were promised. This had been discussed in the past with Murray regarding a need for standard formats to retain last-hop IP addresses used to associate messages with domains when matches are found within SPF records. The primary contention is only receivers and not recipients should need or use this information. It is often not easy to determine last hop IP addresses when messages transverse several MTAs within an ADMD. The preferred result would have been to include the IP address seen at the ADMD border used in SPF validation be retained in a defined header field format, but this has not occurred with Authentication-Results header fields. I think highly of Murray, but feel strongly about misrepresenting security assurances. The Received-SPF Header Field format has been established for a longer period than the Authentication-Results header fields, so arguments about defining yet another header field is illogical. SPF helps ADMDs manage message handling exceptions. Often a user obtains messages through several ADMDs. When users suspect there may be a problem, many third-party tools are available to help users understand email's fairly opaque header field structures. For example, last-hop addresses might be checked against listings of recently compromised servers that may not have been apparent during the initial influx of malicious messages. These types of checks are thwarted or made much less reliable when last-hop information is omitted. It is rather ironic that often the only authenticated identity available happens to be the last-hop IP address. This address is weakly authenticated by modern TCP exchanges. Whenever negative reputation is assigned to the identity of a message source, this identity must be authenticated or incorrect assignments might unfairly disrupt services. Those who manage email have become overly reliant on statistics used to determine typical behavior. Often, these statistics are based upon origination of a message assumed to correspond with authorization and may even ignore authenticated information that might otherwise quickly isolate compromised servers. When dealing with security, it is important to not squint at the differences between authentication and authorization. Many feel there is no reason to make such fine distinctions because it is ONLY email. Unfortunately, this attitude about email overlooks its critical role in conducting business. For example, it is common for consumers to receive email notifications about pending changes, often in conjunction with a provided link. Telling users how to recognize spoofed messages has not worked well. A third-party solution is often the fastest way to broadly improve message protections across a vast array of services. Often those attempting to offer improved security represent different and at times competing interests. It would never be in a users interest to adopt result formats aimed at disabling third-party competitors by omitting essential information. Regards, Douglas Otis From barryleiba.mailing.lists@gmail.com Wed Apr 25 19:25: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 6343411E80BE for ; Wed, 25 Apr 2012 19:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.001, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6+Tnwk6I-WH for ; Wed, 25 Apr 2012 19:25:01 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF0A811E80BB for ; Wed, 25 Apr 2012 19:25:00 -0700 (PDT) Received: by yenm5 with SMTP id m5so718647yen.31 for ; Wed, 25 Apr 2012 19:25:00 -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=MtKmcxGgGzeuMit8s//BUyoJLft6ILigeZmt7KBhgCg=; b=gW1Eo7kEWgZgNDU7maL+ibve4yd64pl1GQE+aplOeoIHPoRmgca4huFnQ8z/bu4aVv eER/upDyKM+LtAsQXM+uIezOPdauIOVrtdAXqZY2oHHa0vPRA447zADaMPf54893BAY/ NhrkZipgMNbCCWER0FnwvyHYKnFM27nB1iKpnPY8puh86nhUDewpmSevdQiAWZHa1d+M LkjM20cU7UYLWY09lhAn3FlY2EKL8yb5xvtU7TXu2zFhi1jjku7Zp/AzMebvp0qwkmQi XmOI7RRjkVy3mgs3VqkNFOtAROPUZQFsl90AuO3sLg+fSut4Bph3cYudxtn8aPaW7lfs AmWw== MIME-Version: 1.0 Received: by 10.100.245.4 with SMTP id s4mr1424516anh.8.1335407100532; Wed, 25 Apr 2012 19:25:00 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.152.14 with HTTP; Wed, 25 Apr 2012 19:25:00 -0700 (PDT) In-Reply-To: <20120425231757.76840.qmail@joyce.lan> References: <9452079D1A51524AA5749AD23E003928102C75@exch-mbx901.corp.cloudmark.com> <20120425231757.76840.qmail@joyce.lan> Date: Wed, 25 Apr 2012 22:25:00 -0400 X-Google-Sender-Auth: BOZD9BEPOq2KbPzuiCGOE49fqp8 Message-ID: From: Barry Leiba To: John Levine Content-Type: multipart/alternative; boundary=0016e6d26dc9db96df04be8bb16d Cc: "spfbis@ietf.org" , "msk@cloudmark.com" Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 02:25:01 -0000 --0016e6d26dc9db96df04be8bb16d Content-Type: text/plain; charset=ISO-8859-1 > In the context of this document, I would want to say that although the > data suggest that reused records had only a minor effect in practice, > we did not resolve the issue, and so long as people continue to use > both SPF and Sender-ID, there remains some risk that systems that > intend to publish SPF will inavertently have their mail filtered by > Sender-ID. I believe this doc is meant to present actual results observed in operation. Are there results that show that mail has been rejected under the conditions you describe? If so, let's absolutely present them. If not, I continue to think that speculating on things that aren't seen in practice is out of place in this document. Barry --0016e6d26dc9db96df04be8bb16d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > In the context of this document= , I would want to say that although the
> data suggest that reused re= cords had only a minor effect in practice,
> we did not resolve the i= ssue, and so long as people continue to use
> both SPF and Sender-ID, there remains some risk that systems that
&= gt; intend to publish SPF will inavertently have their mail filtered by
= > Sender-ID.

I believe this doc is meant to = present actual results observed in operation. =A0Are there results that sho= w that mail has been rejected under the conditions you describe? =A0If so, = let's absolutely present them. =A0If not, I continue to think that spec= ulating on things that aren't seen in practice is out of place in this = document.

Barry
--0016e6d26dc9db96df04be8bb16d-- From spf2@kitterman.com Wed Apr 25 19:35: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 0B80711E80BB for ; Wed, 25 Apr 2012 19:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJis4lHcEG6l for ; Wed, 25 Apr 2012 19:35:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 46E5C11E80BA for ; Wed, 25 Apr 2012 19:35:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CD83420E40E9; Wed, 25 Apr 2012 22:35:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335407708; bh=rBfSiYb/NNAt/7/AY+HPh7BNCQ9DQU7rsXKMA+SN+us=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=GWw0iCvH6Jn/z02UVbj1vXIfvTpIGN8Q0FfmaRVOjAuf8ptOQ6osQYVwPwRhu81UM Gx+fl0R3fQMlQ47D5kMY9VbxI6yYlvuNa81bHaOIkV6aJk7ph9zDHQO1jG7K2tYRoK OreXX+cmMviHE6MykZB1vnPntdtwnNAJ4HiQ6Gjg= Received: from scott-latitude-e6320.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 ESMTPSA id B3DB320E4099; Wed, 25 Apr 2012 22:35:08 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Apr 2012 22:35:08 -0400 Message-ID: <1468330.MtyaxOCLPB@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-23-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: References: <9452079D1A51524AA5749AD23E003928102C75@exch-mbx901.corp.cloudmark.com> <20120425231757.76840.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 02:35:10 -0000 On Wednesday, April 25, 2012 10:25:00 PM Barry Leiba wrote: > > In the context of this document, I would want to say that although the > > data suggest that reused records had only a minor effect in practice, > > we did not resolve the issue, and so long as people continue to use > > both SPF and Sender-ID, there remains some risk that systems that > > intend to publish SPF will inavertently have their mail filtered by > > Sender-ID. > > I believe this doc is meant to present actual results observed in > operation. Are there results that show that mail has been rejected under > the conditions you describe? If so, let's absolutely present them. If > not, I continue to think that speculating on things that aren't seen in > practice is out of place in this document. All I can offer is the anecdotal experience of helping a customer troubleshoot a problem where it turned out that there was a case where one domain published both v=spf1 and SPF2.0/pra records, but used an include: statement in both that included a domain that only had a v=spf1 record. Either they didn't look or assumed that the fallback applied to includes as well. Mail got rejected due to an implementation that quite reasonably (in my opinon) did not use v=spf1 records in include: mechanisms of spf2.0 records. Scott K From johnl@taugh.com Wed Apr 25 20:03: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 6532421E809D for ; Wed, 25 Apr 2012 20:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnHr8x7fgtRW for ; Wed, 25 Apr 2012 20:03:21 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 885C411E80B8 for ; Wed, 25 Apr 2012 20:03:21 -0700 (PDT) Received: (qmail 68856 invoked from network); 26 Apr 2012 03:03:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=10cf7.4f98baf8.k1204; bh=xh4pKvWuRCMlGgszxQ7JuwyqDO1BsF4iXBilSGa1mLk=; b=LJtnVbI1Y9CguvQAKT0RL7FJcwp1gj1KWYXLjD4S/Jgx2QVEhvlWyH6PXFD+GPz/Sk8RligajTIujK+ZMt63tHbu5d+DhnZ16s/W8g3kQp8i1IHkjXQd8v8jCcHRW5qgLolsVS6BgWds0wEdPC16xAEBt4kc0KsBvOYqObNc8Xg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=10cf7.4f98baf8.k1204; bh=xh4pKvWuRCMlGgszxQ7JuwyqDO1BsF4iXBilSGa1mLk=; b=Om3vtPWxy6DEsjeEsuQ4m7REbMcqPBpJSda50haoqqHsCTN+1lqzHCIlheS4C719QfqPUZ5TajYdhwva4HNQSB1ZkJMcZC0NuGNVGWXzMiQgxkda5E+jvqqr9A1p5ywi1nf6hQAyepTkWhEd/dnOpql/GFvvlXHVORcsSVx7yjI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 26 Apr 2012 03:02:58 -0000 Date: 25 Apr 2012 23:03:20 -0400 Message-ID: From: "John R Levine" To: spfbis@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 03:03:22 -0000 > I believe this doc is meant to present actual results observed in > operation. Are there results that show that mail has been rejected under > the conditions you describe? Rejected? Almost nobody rejects on SPF or S-ID failure, so that seems relatively unlikely. But has mail been misfiled due to scoring systems that use S-ID? Who knows? The IESG insisted in putting a big skull and crossbones on each of 4405 through 4408 about how bad things might happen due to the DNS reuse, so it seems a bit odd to say nothing at all about it. Our numbers say that somewhere between 5% and 20% of mail gets different results with S-ID and SPF checks. Since we saw almost no S-ID records published, the reasonable assumption is that most of those different answers are due to S-ID reusing SPF records. I don't know how many of those different results led to mishandling the mail, but it seems rash to assume that none of them did, and it does pretty clearly indicate that in practice, S-ID will get the wrong answer (in the sense of not what the domain's owner intended) a significant fraction of the time. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From hsantos@isdg.net Wed Apr 25 21:05: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 C2C3C21E8026 for ; Wed, 25 Apr 2012 21:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1dvXIG3mamR for ; Wed, 25 Apr 2012 21:05:58 -0700 (PDT) Received: from secure.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B155021F8690 for ; Wed, 25 Apr 2012 21:05:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=514; t=1335413152; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=E5qoANyX8UkgyJH59iqqp7mHrTM=; b=hmi4bPZcvkEgpatkj2Gl RXdFK68WN3I6YeXJm9peCo+9z6d+7CKiwbz0KOc/npCh2EO27LPZuq1PUV7srFL0 17B81aSaUD9E5Ct/LwJvPoj21465uHIB2iCG+qKIvXuhpsYLciNwAjPYyjJJ53ju QeaVFnZcmKcRm4BJBLyqEvM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 26 Apr 2012 00:05: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 v6.4.454.1) with ESMTP id 25000086.38454.5488; Thu, 26 Apr 2012 00:05:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=514; t=1335412808; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WiWvY1y MUqUqBSa8ol+A/HLJkvoTTu8OG5uiAoQkdbY=; b=ZPAUCoMAiJrRTyhWsWevtSF js08cfVoAY29wWolIOeUoFhnaOpSghQm8cv8ej6jLhSzGZldNbAe0RsCpVexJrXR bzfDRiFZ04Q2esfUYwW/3U90DH0TlYpzlKcxzZbZd8x4BQ/vO58F2dW1xlzmD8ZP SnNjSZ15kD9Rf95dYdhY= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 26 Apr 2012 00:00:08 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 623896456.3494.1592; Thu, 26 Apr 2012 00:00:07 -0400 Message-ID: <4F98C97C.2050008@isdg.net> Date: Thu, 26 Apr 2012 00:05:16 -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 Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 04:05:58 -0000 >> I believe this doc is meant to present actual results observed in >> operation. Are there results that show that mail has been rejected >> under the conditions you describe? > > Rejected? Almost nobody rejects on SPF or S-ID failure, so that seems > relatively unlikely. -1. Our operator's local site policy default setup is to REJECT-ON-FAIL. Almost nobody also means somebody so it is relatively likely to happen. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From msk@cloudmark.com Wed Apr 25 22:03: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 95EF621F88EA for ; Wed, 25 Apr 2012 22:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.63 X-Spam-Level: X-Spam-Status: No, score=-102.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktMLi9eye32A for ; Wed, 25 Apr 2012 22:02:58 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 22C7421F8777 for ; Wed, 25 Apr 2012 22:02:52 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 2V2s1j0010as01C01V2sQ5; Wed, 25 Apr 2012 22:02:52 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=K4ag7lqI c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=IKq0b-0HotjmHe1Hch8A:9 a=Hm6Ccl5WCAqrFGdWNCYA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 25 Apr 2012 22:02:30 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNI1kiXt7nF5KnvEq9U7F2f34qNJasiwfw Date: Thu, 26 Apr 2012 05:02:29 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335416572; bh=zDYWqR255rk/Vd72LPC7jWRdEw39htl/iE6Q5HnzBK4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nOaGjBA7XJDn1kF4i15rXIaznF2qpXozeDkMSH+l0yJ6OVTSygnq3DmSX8LXaENAJ 5TUaEqoGgJdZENcVLr5k1hHvRrS84Th4A1cJ1Wpckll5aQO7tOjF5yN8xSlUSF3O2Y GxaePcWAtvwsGrBgQWXzxUoI0oIcVqRjwBDtpGoQ= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 05:03:00 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John R Levine > Sent: Wednesday, April 25, 2012 8:03 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > Our numbers say that somewhere between 5% and 20% of mail gets > different results with S-ID and SPF checks. Since we saw almost no S- > ID records published, the reasonable assumption is that most of those > different answers are due to S-ID reusing SPF records. I don't agree that that's the only reasonable assumption. It seems more li= kely to me that different answers might also come from the fact that the PR= A produced a different domain than the MAIL FROM domain in those cases, res= ulting in a different policy being evaluated altogether, independent of the= DNS reuse question. I don't think the SIDF re-use of SPF records is an important thing to call = out in the experiment document because its contribution to the stats is hyp= othetical. On the other hand, this could very well be something to mention= in Security Considerations of RFC4408bis itself. -MSK From hsantos@isdg.net Wed Apr 25 22:41: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 B95A621F8995 for ; Wed, 25 Apr 2012 22:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JogHShapENWm for ; Wed, 25 Apr 2012 22:41:27 -0700 (PDT) Received: from listserv.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 34D9221F8993 for ; Wed, 25 Apr 2012 22:41:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1266; t=1335418878; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=W/sjOAthyn6BdJy8+nX9rJkRASE=; b=ufBbheughpvz4ocLG5kO WiBGWemvTkYQg0zEiaL7WIlANx/m7bD9H2ljFA5VGD3RWF5Dqfp2IYcz1bn0TIUO 9UDmX1FzLVksQJatyhE3rf/28jV7lnODjnAK2Cm+PfoJqFCnh7D7TrHHLMqHsQ1G YZnaSAai7UbZOWzb08eI/fs= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 26 Apr 2012 01:41:18 -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 v6.4.454.1) with ESMTP id 30725292.38454.3880; Thu, 26 Apr 2012 01:41:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1266; t=1335418536; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=idasKe3 pKuF2pKI3k6mbDTBV2Bb6d/L7OpZ9jVAaPZ4=; b=a5WRcA1bFdOOyXfMQ5i5DyW 4ZhLkA3ZuUYKgwVOziVHGV2yCZ/xt5qojEuNFQldukZhwtIPpKk4AkUVml9l0mku R2212acP1RbCzNanCELDH/PKkO5A46Z+Okv3OigjnZLYqEtjFeQTsxXejrZX/dW2 1Csba7uhKxW8YOMlZOaM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 26 Apr 2012 01:35:36 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 629624378.3504.1456; Thu, 26 Apr 2012 01:35:35 -0400 Message-ID: <4F98DFDC.6080703@isdg.net> Date: Thu, 26 Apr 2012 01:40:44 -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: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.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] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 05:41:28 -0000 +1 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of John R Levine >> Sent: Wednesday, April 25, 2012 8:03 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >> >> Our numbers say that somewhere between 5% and 20% of mail gets >> different results with S-ID and SPF checks. Since we saw almost no S- >> ID records published, the reasonable assumption is that most of those >> different answers are due to S-ID reusing SPF records. > > I don't agree that that's the only reasonable assumption. It seems more likely to me that different answers might also come from the fact that the PRA produced a different domain than the MAIL FROM domain in those cases, resulting in a different policy being evaluated altogether, independent of the DNS reuse question. > > I don't think the SIDF re-use of SPF records is an important thing to call out in the experiment document because its contribution to the stats is hypothetical. On the other hand, this could very well be something to mention in Security Considerations of RFC4408bis itself. > -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From johnl@iecc.com Thu Apr 26 05:20: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 0744321F87C3 for ; Thu, 26 Apr 2012 05:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.087 X-Spam-Level: X-Spam-Status: No, score=-111.087 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QfoiIutrRc5 for ; Thu, 26 Apr 2012 05:20:22 -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 39BB321F87BA for ; Thu, 26 Apr 2012 05:20:21 -0700 (PDT) Received: (qmail 85082 invoked from network); 26 Apr 2012 12:20:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Apr 2012 12:20:20 -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=4f993d84.xn--yuvv84g.k1204; i=johnl@user.iecc.com; bh=wGeszUgtV2APhfbf1RBFk/MlGYVLMDffGa5KoiaDHbc=; b=gvFx1dAXW1AT2YkQL/HswurnMVAbJJnCwmey9BpaAkpYvMfeaFLdZsk+OqLteawp2XzBgpcjg1LJ+3FeKw7Rei9Nj+1x5Sm0o3WlQnBSLsl3sPmKC+xVrOzl0c7kyX6/feBm87fzDgMjYnzGKOFVnwiaf48tiW+5tUMvbC1qSGM= 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=4f993d84.xn--yuvv84g.k1204; olt=johnl@user.iecc.com; bh=wGeszUgtV2APhfbf1RBFk/MlGYVLMDffGa5KoiaDHbc=; b=mgl3/f3NyHE0Tzv/IOL5t0ig4RMtkMsO1ok+kMiqrw1TKRlqsjeZ7Gd4vTvdLDahffL8D3dWbieMAUn5SlJGx79AmqM7IdWVtsnPp9scLUmMSleRR88ms1TdSpqamWlet05PWAmIzdz4LLW2t5BeskisQlQxE0NHj/4MApxk3cU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 26 Apr 2012 12:19:57 -0000 Message-ID: <20120426121957.6129.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:20:23 -0000 >> ID records published, the reasonable assumption is that most of those >> different answers are due to S-ID reusing SPF records. > >I don't agree that that's the only reasonable assumption. It seems more likely to me >that different answers might also come from the fact that the PRA produced a >different domain than the MAIL FROM domain in those cases, resulting in a different >policy being evaluated altogether, independent of the DNS reuse question. Except that there isn't anything like 5% of the senders publishing S-ID records. Those checks probably did use a different domain, but if they checked it against an SPF record intended for envelope domains, that's a bug. Imagine a hypothetical survey, in which we ask mail system managers who publish SPF records whether they also intend those records to be used for Sender-ID. I would expect the overwhelming response to be "What's Sender-ID?" >I don't think the SIDF re-use of SPF records is an important thing to call out in the >experiment document because its contribution to the stats is hypothetical. I suppose if we're all OK with the implicit messge that the skull and crossbones was silly, we could drop it. But I'm kind of surprised nobody on the IESG has mentioned it. Short memories, perhaps. R's, John From msk@cloudmark.com Thu Apr 26 06:57: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 6713621E802D for ; Thu, 26 Apr 2012 06:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVm0OepN+wE3 for ; Thu, 26 Apr 2012 06:57:17 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB2421E8043 for ; Thu, 26 Apr 2012 06:57:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 2dxE1j0010as01C01dxEy6; Thu, 26 Apr 2012 06:57:14 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=VPNfbqzX c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=QLhupLqRAAAA:8 a=48vgC7mUAAAA:8 a=B0a5bEZTgLdQjKLsA50A:9 a=odADz8LnaQ_62v8zb4oA:7 a=QEXdDO2ut3YA:10 a=EzGVmGvcixYA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 06:57:14 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNI1kiXt7nF5KnvEq9U7F2f34qNJasiwfwgADxaID//51ZYA== Date: Thu, 26 Apr 2012 13:57:14 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039281039A5@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> <20120426121957.6129.qmail@joyce.lan> In-Reply-To: <20120426121957.6129.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335448634; bh=+9PAiahFhHtKiWw2x1QumNAGVGmapzZ6AnBUU2bg0NI=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=UM2xxITP9SwdzDQ9Gzzq2V7uoQI22yid8spAmvKkqehl7boOQM93U9jHBCZB2WGIb ahAtSJL636E/HSKBELldD5YojzjjAF1Pt27PetVtk72ac7hN8oPKLlo+i7AX2NVJ5M i0CkcmHUG/QLSOZ5BkZ5tsGnyua4+EA9h0OJrt4A= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:57:18 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDI2LCAyMDEyIDU6MjAg QU0NCj4gVG86IHNwZmJpc0BpZXRmLm9yZw0KPiBDYzogTXVycmF5IFMuIEt1Y2hlcmF3eQ0KPiBT dWJqZWN0OiBSZTogW3NwZmJpc10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1zcGZiaXMtZXhwZXJpbWVu dA0KPiANCj4gPkkgZG9uJ3QgYWdyZWUgdGhhdCB0aGF0J3MgdGhlIG9ubHkgcmVhc29uYWJsZSBh c3N1bXB0aW9uLiAgSXQgc2VlbXMNCj4gPm1vcmUgbGlrZWx5IHRvIG1lIHRoYXQgZGlmZmVyZW50 IGFuc3dlcnMgbWlnaHQgYWxzbyBjb21lIGZyb20gdGhlIGZhY3QNCj4gPnRoYXQgdGhlIFBSQSBw cm9kdWNlZCBhIGRpZmZlcmVudCBkb21haW4gdGhhbiB0aGUgTUFJTCBGUk9NIGRvbWFpbiBpbg0K PiA+dGhvc2UgY2FzZXMsIHJlc3VsdGluZyBpbiBhIGRpZmZlcmVudCBwb2xpY3kgYmVpbmcgZXZh bHVhdGVkDQo+IGFsdG9nZXRoZXIsIGluZGVwZW5kZW50IG9mIHRoZSBETlMgcmV1c2UgcXVlc3Rp b24uDQo+IA0KPiBFeGNlcHQgdGhhdCB0aGVyZSBpc24ndCBhbnl0aGluZyBsaWtlIDUlIG9mIHRo ZSBzZW5kZXJzIHB1Ymxpc2hpbmcgUy1JRA0KPiByZWNvcmRzLiAgVGhvc2UgY2hlY2tzIHByb2Jh Ymx5IGRpZCB1c2UgYSBkaWZmZXJlbnQgZG9tYWluLCBidXQgaWYgdGhleQ0KPiBjaGVja2VkIGl0 IGFnYWluc3QgYW4gU1BGIHJlY29yZCBpbnRlbmRlZCBmb3IgZW52ZWxvcGUgZG9tYWlucywgdGhh dCdzDQo+IGEgYnVnLg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIHJpZ2h0IGRvY3VtZW50 IGZvciB0aGF0IGtpbmQgb2YgYW5hbHlzaXMuICBJbiBteSBvcGluaW9uLCB3ZSBzaG91bGQga2Vl cCBpdCBmb2N1c2VkIG9uIHRoZSBxdWVzdGlvbiBvZiB3aGF0IGdvdCBhZG9wdGVkLCBhcyB0aGF0 J3MgZW5vdWdoIHRvIGFuc3dlciB0aGUgImNvbnNlbnN1cyIgcXVlc3Rpb24gZnJvbSB0aGUgSUVT RyBub3RlIGFuZCBhZHZhbmNlIFNQRiB0byB0aGUgU3RhbmRhcmRzIFRyYWNrLg0KDQpBbmQgd2Un dmUgc2VlbiBob3cgZXZlbiBjb2xsZWN0aW5nIGFuZCBhbmFseXppbmcgZGF0YSBhYm91dCB3aGF0 J3MgaW4gdXNlLCBzZXBhcmF0ZSBmcm9tIGVmZmljYWN5LCBjYW4gcmF0aG9sZSBvbiBhIGJ1bmNo IG9mIGh5cG90aGV0aWNhbCBhbmQgb3J0aG9nb25hbCBxdWVzdGlvbnMgZXZlbiB0aG91Z2ggdGhh dCBhbmFseXNpcyBpc24ndCBzdWJqZWN0aXZlLiAgSXQncyBzY2FyeSB0byB0aGluayBhYm91dCBo b3cgbG9uZyBhbiBpbi1kZXB0aCBhbmFseXNpcyBhYm91dCB0aG9zZSBvdGhlciBxdWVzdGlvbnMg d291bGQgdGFrZSB0byByZWFjaCBjb25zZW5zdXMuDQoNCi1NU0sNCg== From johnl@iecc.com Thu Apr 26 08:40: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 A919F21F857D for ; Thu, 26 Apr 2012 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.091 X-Spam-Level: X-Spam-Status: No, score=-111.091 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeiU2+kzeaDi for ; Thu, 26 Apr 2012 08:40: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 DF82821F86B1 for ; Thu, 26 Apr 2012 08:40:53 -0700 (PDT) Received: (qmail 41073 invoked from network); 26 Apr 2012 15:40:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Apr 2012 15:40: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:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f996c84.xn--9vv.k1204; i=johnl@user.iecc.com; bh=98EYG5JiptoTn96O30Qo1VHFdbRse25Vt7A+Frj+bH4=; b=PZnn5Lwxpl6w1awJuTexf4xnCpjwF9L8Zv51EIb5VzyvMaWhaLago+Hve9GSp318I61Q2gBnCAHt36pZ1UkpaIxFcCprEO1YXAw7cJfUwnS6bq9rDz+GdkN89aJCfJpKcu+wKvh1rt73Mh86liEBkdqGYS3Th+l+sPqEhot0/o4= 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=4f996c84.xn--9vv.k1204; olt=johnl@user.iecc.com; bh=98EYG5JiptoTn96O30Qo1VHFdbRse25Vt7A+Frj+bH4=; b=I0w+Fk/EkDWw2Uf6VHd2s8QO06KWc/GpZGfLXS3/dDlyftlq2dVLq1d+2ed1V28gF1baLLGSsbHrqyWXWSSry1zLCO4lc7aQL/TEmkPnPmAx2zenAJLQtI/AuswJXbxf6my+XqWOdSzLqhqIV1cNhgvm2vHPGC4A6ISFZFfuIco= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 26 Apr 2012 15:40:29 -0000 Message-ID: <20120426154029.4081.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E0039281039A5@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: msk@cloudmark.com Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:40:54 -0000 >adopted, as that's enough to answer the "consensus" question from the >IESG note and advance SPF to the Standards Track. OK. I take it that the consensus of the group is that the warning about DNS record reuse was too or trivial to be worth addressing. We don't have an enormous amount of data, but we do have some. R's, John From dhc@dcrocker.net Thu Apr 26 08:57: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 BAD6621E80F4 for ; Thu, 26 Apr 2012 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.762 X-Spam-Level: X-Spam-Status: No, score=-5.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCw0oiUsGjg6 for ; Thu, 26 Apr 2012 08:57:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 32A7D21E80DF for ; Thu, 26 Apr 2012 08:57:22 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3QFvLsC000727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Apr 2012 08:57:21 -0700 Message-ID: <4F997055.1000108@dcrocker.net> Date: Thu, 26 Apr 2012 08:57:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> <20120426121957.6129.qmail@joyce.lan> <9452079D1A51524AA5749AD23E0039281039A5@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039281039A5@exch-mbx901.corp.cloudmark.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, 26 Apr 2012 08:57:22 -0700 (PDT) Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment 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, 26 Apr 2012 15:57:22 -0000 On 4/26/2012 6:57 AM, Murray S. Kucherawy wrote: > I don't think this is the right document for that kind of analysis. > In my opinion, we should keep it focused on the question of what got > adopted, as that's enough to answer the "consensus" question from the > IESG note and advance SPF to the Standards Track. +1 This document does not need to venture into conjecture. Such analysis might be fun and even productive, but it's not needed for this document and it's clear this document should do only the minimum it needs to, to satisfy its reason for being written. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Thu Apr 26 09:01: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 6B3D521E80F4 for ; Thu, 26 Apr 2012 09:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.806 X-Spam-Level: X-Spam-Status: No, score=-5.806 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sv78xV43g6v for ; Thu, 26 Apr 2012 09:01:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2DC221E80DF for ; Thu, 26 Apr 2012 09:01:49 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3QG1nFO000815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Apr 2012 09:01:49 -0700 Message-ID: <4F997161.8010902@dcrocker.net> Date: Thu, 26 Apr 2012 09:01:37 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120425231757.76840.qmail@joyce.lan> In-Reply-To: <20120425231757.76840.qmail@joyce.lan> 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, 26 Apr 2012 09:01:49 -0700 (PDT) Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment 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, 26 Apr 2012 16:01:58 -0000 On 4/25/2012 4:17 PM, John Levine wrote: > In the context of this document, I would want to say that although the > data suggest that reused records had only a minor effect in practice, > we did not resolve the issue, and so long as people continue to use > both SPF and Sender-ID, there remains some risk that systems that > intend to publish SPF will inavertently have their mail filtered by > Sender-ID. I believe we have do not have the type of data needed to deal with this concern. Were there greater SID use and more indications of problems due to colliding use of the DNS record, it would be worth pursuing. Given the very low usage leves of SID, I think that worrying about problems from the conflict aren't worth the effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Thu Apr 26 09:53: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 1D33711E80A3 for ; Thu, 26 Apr 2012 09:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1rBnI0hSTeo for ; Thu, 26 Apr 2012 09:53:32 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8525B11E80A0 for ; Thu, 26 Apr 2012 09:53:32 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 2gt91j0010as01C01gt94S; Thu, 26 Apr 2012 09:53:09 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=VPNfbqzX c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=bdkMaEdFIym-zm0ZzGAA:9 a=QhacjNmVTYnji9iogtYA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 09:53:09 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNI1kiXt7nF5KnvEq9U7F2f34qNJasiwfwgADxaID//51ZYIAAmq6A//+e1fA= Date: Thu, 26 Apr 2012 16:53:09 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928103CA7@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039281039A5@exch-mbx901.corp.cloudmark.com> <20120426154029.4081.qmail@joyce.lan> In-Reply-To: <20120426154029.4081.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335459190; bh=Ww2o9irJJq3N5XcsJlie8pppwOkUwSzemv6l5pXhuaE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=JxVPsxuZRqYIzspVPOSTSzoQuYJmVDA4Zgh1R/WS8ISklfGDjY1o0Ccne8+kx3NGE 3itLZXT6zRUB5u0a/5i75v1/Frqtv5Yg/JHqA0Wnb4B2w9PTgPR0Tkr/lNK7VzAo3J Ndt2R/yjpm4tBR2awoN8MxrgOSL0m3TBG6ESpxuQ= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:53:33 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of John Levine > Sent: Thursday, April 26, 2012 8:40 AM > To: spfbis@ietf.org > Cc: Murray S. Kucherawy > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > >adopted, as that's enough to answer the "consensus" question from the > >IESG note and advance SPF to the Standards Track. >=20 > OK. I take it that the consensus of the group is that the warning > about DNS record reuse was too or trivial to be worth addressing. ...in this document. (To be clear about my position, at any rate.) From dotis@mail-abuse.org Thu Apr 26 10:48: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 A4F9C21E8028 for ; Thu, 26 Apr 2012 10:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yppKgfxCWcKc for ; Thu, 26 Apr 2012 10:48:44 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 459DA21E80A1 for ; Thu, 26 Apr 2012 10:48:44 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 219E917400BC for ; Thu, 26 Apr 2012 17:48:42 +0000 (UTC) Message-ID: <4F998A79.9030708@mail-abuse.org> Date: Thu, 26 Apr 2012 10:48:41 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:48:44 -0000 On 4/25/12 10:02 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of John R Levine >> Sent: Wednesday, April 25, 2012 8:03 PM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >> >> Our numbers say that somewhere between 5% and 20% of mail gets >> different results with S-ID and SPF checks. Since we saw almost no S- >> ID records published, the reasonable assumption is that most of those >> different answers are due to S-ID reusing SPF records. > I don't agree that that's the only reasonable assumption. It seems more likely to me that different answers might also come from the fact that the PRA produced a different domain than the MAIL FROM domain in those cases, resulting in a different policy being evaluated altogether, independent of the DNS reuse question. > > I don't think the SIDF re-use of SPF records is an important thing to call out in the experiment document because its contribution to the stats is hypothetical. On the other hand, this could very well be something to mention in Security Considerations of RFC4408bis itself. Dear Murray, Agreed. The RFC4408bis document is a good location for this type of warning. As an aside, the DMARC group said large organizations have been implementing their combined SPF+DKIM strategy since 2007. Would they be willing to make last minute contributions? This seems appropriate since this appears where SPF is headed based upon the level of corporate buy in. BTW, prior statements had been based on information presented by Sam Masiello IIRC. I had not yet discovered the latest document. Many of the links were stale. Not that this parallel effort seems anything like shades of the past, but is there a reason why your DMARC draft is not published as an IETF document? Regards, Douglas Otis From msk@cloudmark.com Thu Apr 26 10: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 29F2921E801E for ; Thu, 26 Apr 2012 10:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.259 X-Spam-Level: X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GblIEelHxm2 for ; Thu, 26 Apr 2012 10:56:24 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8921F8646 for ; Thu, 26 Apr 2012 10:56:24 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 2hwP1j0020as01C01hwPRD; Thu, 26 Apr 2012 10:56:23 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=VPNfbqzX c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=RHbAcNU0lgcXeEVP97IA:9 a=S1xh5yFggosHDf4azfUA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 10:56:23 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNI1kiXt7nF5KnvEq9U7F2f34qNJasiwfwgAFNQYD//4t/4A== Date: Thu, 26 Apr 2012 17:56:23 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928103E2E@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> <4F998A79.9030708@mail-abuse.org> In-Reply-To: <4F998A79.9030708@mail-abuse.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335462983; bh=tkdITef7nYqBp5pcMxC5SzZx3Qv6cfHcOjp5Jpjub4g=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=WbW8BTViRXre7PBZ+0Qttt6ZSe6Cbd/sxGiL9RH5KZeeQGYaV32DqtDXE6rYBs7Yw JlS6Zj8jBtqeWMeGENZmBDOIQxMMjtuvLvBr0/Ei8SEBDoSzDo24eSpdca2zkE4Ehy qVNaX1R43oE/hTrpAodHeuG5pnfNHUvlirCmxpc0= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:56:25 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Douglas Otis > Sent: Thursday, April 26, 2012 10:49 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > As an aside, the DMARC group said large organizations have been > implementing their combined SPF+DKIM strategy since 2007. Would they > be willing to make last minute contributions? This seems appropriate > since this appears where SPF is headed based upon the level of > corporate buy in. What sort of contributions? > BTW, prior statements had been based on information presented by Sam > Masiello IIRC. I had not yet discovered the latest document. Many of > the links were stale. Not that this parallel effort seems anything > like shades of the past, but is there a reason why your DMARC draft is > not published as an IETF document? Mostly change control reasons, in the same way that the ESTG kept control o= f DKIM until they were prepared to hand it off to the IETF. But IETF proce= ssing of DMARC is indeed the end goal. But again, I think this is off-topic for spfbis. -MSK, juggling hats quite a bit here From dotis@mail-abuse.org Thu Apr 26 12:11: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 6822521E810F for ; Thu, 26 Apr 2012 12:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrCTg0Rzjewf for ; Thu, 26 Apr 2012 12:11:29 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id EE8E021E80F2 for ; Thu, 26 Apr 2012 12:11:28 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 724B7174016D for ; Thu, 26 Apr 2012 19:11:28 +0000 (UTC) Message-ID: <4F999DE0.3060808@mail-abuse.org> Date: Thu, 26 Apr 2012 12:11:28 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> <4F998A79.9030708@mail-abuse.org> <9452079D1A51524AA5749AD23E003928103E2E@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928103E2E@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:11:29 -0000 On 4/26/12 10:56 AM, Murray S. Kucherawy wrote: >> As an aside, the DMARC group said large organizations have been >> implementing their combined SPF+DKIM strategy since 2007. Would they >> be willing to make last minute contributions? This seems appropriate >> since this appears where SPF is headed based upon the level of >> corporate buy in. > What sort of contributions? Dear Murray, In essence, points made by Hotmail et al was in regard to quality of results compared against that of Sender-ID. It sounded like these results were seen as sufficient even for those who were stalwart Sender-ID advocates. The highlights of this information suggested that it strongly supported claims made by John Levine, for example. While this might seem like a reach, perhaps it would also help satisfy those less familiar with SPF+DKIM in conjunction with "Organizational Domain" policy assertions. It seems "Organizational Domain" is new to the IETF. But since this is where traction is growing in establishing greater levels of policy enforcement, it seems this information could offer rather convincing support of the notion for dropping Sender-ID when the policy function is better handled by SPF in conjunction with DKIM and Organizational Domain policies. Regards, Douglas Otis From sm@elandsys.com Thu Apr 26 14:22: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 51E6821E8020 for ; Thu, 26 Apr 2012 14:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv7Vwm1yaRzk for ; Thu, 26 Apr 2012 14:22:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8D411E8074 for ; Thu, 26 Apr 2012 14:22:18 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.158]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3QLM5Sx001553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2012 14:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335475337; i=@elandsys.com; bh=bbq/94W78ZhqEgZnb6j1A4XO7aNBnBpAuX6dnkPK+6E=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=JL0BK4yR0GsfOHmcZ3e7rSPzIjNsGXPXEuJZVPYlDKUTZVwmnxkJYPxa2KujSmxkt caZmWRE8fRbmqXFRniwmUsip3eSdHq4hXcXqvR5dW7eHm5qII9NVyvG//lfzZXhuFJ FetoekZ44neWJ3mIDUqyqtdXrsgxoy3koKPDDCkI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335475337; i=@elandsys.com; bh=bbq/94W78ZhqEgZnb6j1A4XO7aNBnBpAuX6dnkPK+6E=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=L1/g51bIHJ/0VdS0da/50DjZhv82JH2VV7erAbjtW+8TZzkDHoAzY2GyMIvtm9+RW RtI42JV3ThuiJP8dB4DmQj+y5KZRRfuQjpBQZvWfi7ZeV+Bjl+Jj/hwjOyslqacEgY 5iwKSzyVJi8CZdJPeYLh1jslTlRr9FazDyNGqu3k= Message-Id: <6.2.5.6.2.20120426140200.09acb338@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 26 Apr 2012 14:15:16 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120423171049.0a053708@elandnews.com> References: <6.2.5.6.2.20120423171049.0a053708@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] IETF83 SPFBIS minutes - Version 0.2 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 21:22:20 -0000 Hello, I'll consider Version 0.2 of the IETF83 SPFBIS minutes as final as there hasn't been any further comments about it. I'll be submitting for the proceedings tomorrow. Thanks to Douglas Otis for following up on a request made during the last meeting ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html ). If anyone would like to send the best arguments for deprecating, please post them to this mailing list. There isn't any rush as the working group is currently working on draft-ietf-spfbis-experiment. Regards, S. Moonesamy SPFBIS WG co-chair From pmidge@messagebus.com Thu Apr 26 22:43: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 9A1E121F875A for ; Thu, 26 Apr 2012 22:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnCF05MkHWc9 for ; Thu, 26 Apr 2012 22:43:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B67021F8759 for ; Thu, 26 Apr 2012 22:43:40 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so559781pbb.31 for ; Thu, 26 Apr 2012 22:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=messagebus.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=kxSz5r+49N9/pjT+HgVE3fNt/6tDEIMXnD+lGKwbowA=; b=fx0CESujXaZ+/J75uqrBtMER/1fBMtQptyvnEubfUArvbfzOygo16WUpmKX4JGzJw3 S3MltF6gekyrJVpLOgIHDtfFiZ3tLsv2sULUMtXo9BBEzN06O62IeI0YYGH0UlMNpF0u NNu9J6i+MnKz3pRy3pke/EV+G/eGQ2BmG+y2Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=kxSz5r+49N9/pjT+HgVE3fNt/6tDEIMXnD+lGKwbowA=; b=mYsZOus0iDaqFAXM4/NOl5t5FHNRgdeDISzVezpnUWX8WEp/8PJBysN6ff52GrRDvh rJF/UaVyfb2Sbfw5o4iz5okhrFCRmtnJjJumT/S0bx9u7uum3L3IA/mH6dWCjESVgU+C 2n2mgm+0qypoIOzgdYjZXaPcb4+Dp776ifcnuQ3F3DYKlOCUxhwDvJsL4aP2uM6zBFfn 6Hr6wHo80+pXDkaTaaRutDc33jFq41CLqhSJFlejfihky5km08NumRzfWOrsEhux+PoE I1Ba55urRX8nYtZLgDyqbibil3qcZF9YFeZQWNSixVvQT+HThhUcgYUlOtvOsRuo29+A B3Rw== Received: by 10.68.225.198 with SMTP id rm6mr6150030pbc.89.1335505419649; Thu, 26 Apr 2012 22:43:39 -0700 (PDT) Received: from percival.local (c-98-234-236-249.hsd1.ca.comcast.net. [98.234.236.249]) by mx.google.com with ESMTPS id d6sm5444725pbi.23.2012.04.26.22.43.38 (version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 22:43:39 -0700 (PDT) Message-ID: <4F9A31FB.70401@messagebus.com> Date: Thu, 26 Apr 2012 22:43:23 -0700 From: Paul Midgen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> <4F998A79.9030708@mail-abuse.org> <9452079D1A51524AA5749AD23E003928103E2E@exch-mbx901.corp.cloudmark.com> <4F999DE0.3060808@mail-abuse.org> In-Reply-To: <4F999DE0.3060808@mail-abuse.org> Content-Type: multipart/alternative; boundary="------------070900080409090906090102" X-Gm-Message-State: ALoCoQmVF4anvPHDa5Tm6DLJezu32kAP2R/5bZH8skUYxrzf/2RH3s5tnlGs12jCl0xlIDMKU9y9 Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Apr 2012 05:43:41 -0000 This is a multi-part message in MIME format. --------------070900080409090906090102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hotmail hat on. Teeing up Hotmail and/or Microsoft as SenderID advocates == not the droids we're looking for. The reality is that the folks for whom this was a political (or other) crusade are long gone, and it's just a business (for the enterprise groups like Exchange) or technical (for Hotmail) issue to be evaluated on the merits of the benefit it provides. For Hotmail it was simple: the end result in terms of user experience are pretty much the same either way, most folks use SPF, SPFbis is now an IETF working group, ergo we will get behind SPF because speeding it along to Standards Track means other interesting work can happen. So I don't see the point in trying to record some kind of historical note about the intentions of folks publishing SPF1 records with respect to how SenderID verifiers would use those records. Outside of hypothetical discussions, it has proven immaterial in practice. It is safe to say that in terms of received mail volume and source domain diversity, Hotmail was the largest SenderID validator who used authentication results in making delivery decisions. We never ran into an issue where SenderID caused a problem that SPF wouldn't have. We never experienced any kind of security issue (e.g. elevation of privilege, policy avoidance) due to use of SenderID with SPF1 records that was of sufficient magnitude to be reported by a sender or recipient, or be noticed by our own security teams. I am NOT saying such things aren't possible, others have proven they are. Just that we have no proof a real live bad guy exploited that potential at Hotmail in its history using SenderID, and since Hotmail is moving to SPF a future example is unlikely to obtain. The move away from SenderID actually had some drawbacks requiring workarounds, but these things weren't deterrent enough to stop the move to SPF. So, the purpose of the "experiment conclusion" document is to be a historical record of the SPF/SenderID experiment and identify SPF(bis) as the way forward, and I believe the current draft does that well enough. No offense intended to anyone on this list, but operational consensus was unambiguously clear before SPFbis was formed. All subsequent debate/discussion hasn't really changed that fact, or will ultimately alter the outcome. We're here to do the work of documenting history and reductionary refinement of SPF. On 26-Apr/12 12:11 PM, Douglas Otis wrote: > On 4/26/12 10:56 AM, Murray S. Kucherawy wrote: >>> As an aside, the DMARC group said large organizations have been >>> implementing their combined SPF+DKIM strategy since 2007. Would they >>> be willing to make last minute contributions? This seems appropriate >>> since this appears where SPF is headed based upon the level of >>> corporate buy in. >> What sort of contributions? > Dear Murray, > > In essence, points made by Hotmail et al was in regard to quality of > results compared against that of Sender-ID. It sounded like these > results were seen as sufficient even for those who were stalwart > Sender-ID advocates. The highlights of this information suggested > that it strongly supported claims made by John Levine, for example. > While this might seem like a reach, perhaps it would also help satisfy > those less familiar with SPF+DKIM in conjunction with "Organizational > Domain" policy assertions. It seems "Organizational Domain" is new to > the IETF. But since this is where traction is growing in establishing > greater levels of policy enforcement, it seems this information could > offer rather convincing support of the notion for dropping Sender-ID > when the policy function is better handled by SPF in conjunction with > DKIM and Organizational Domain policies. > > Regards, > Douglas Otis > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis --------------070900080409090906090102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hotmail hat on.

Teeing up Hotmail and/or Microsoft as SenderID advocates == not the droids we're looking for.

The reality is that the folks for whom this was a political (or other) crusade are long gone, and it's just a business (for the enterprise groups like Exchange) or technical (for Hotmail) issue to be evaluated on the merits of the benefit it provides. For Hotmail it was simple: the end result in terms of user experience are pretty much the same either way, most folks use SPF, SPFbis is now an IETF working group, ergo we will get behind SPF because speeding it along to Standards Track means other interesting work can happen.

So I don't see the point in trying to record some kind of historical note about the intentions of folks publishing SPF1 records with respect to how SenderID verifiers would use those records. Outside of hypothetical discussions, it has proven immaterial in practice.

It is safe to say that in terms of received mail volume and source domain diversity, Hotmail was the largest SenderID validator who used authentication results in making delivery decisions. We never ran into an issue where SenderID caused a problem that SPF wouldn't have. We never experienced any kind of security issue (e.g. elevation of privilege, policy avoidance) due to use of SenderID with SPF1 records that was of sufficient magnitude to be reported by a sender or recipient, or be noticed by our own security teams.

I am NOT saying such things aren't possible, others have proven they are. Just that we have no proof a real live bad guy exploited that potential at Hotmail in its history using SenderID, and since Hotmail is moving to SPF a future example is unlikely to obtain. The move away from SenderID actually had some drawbacks requiring workarounds, but these things weren't deterrent enough to stop the move to SPF.

So, the purpose of the "experiment conclusion" document is to be a historical record of the SPF/SenderID experiment and identify SPF(bis) as the way forward, and I believe the current draft does that well enough.

No offense intended to anyone on this list, but operational consensus was unambiguously clear before SPFbis was formed. All subsequent debate/discussion hasn't really changed that fact, or will ultimately alter the outcome. We're here to do the work of documenting history and reductionary refinement of SPF.


On 26-Apr/12 12:11 PM, Douglas Otis wrote:
On 4/26/12 10:56 AM, Murray S. Kucherawy wrote:
As an aside, the DMARC group said large organizations have been
implementing their combined SPF+DKIM strategy since 2007.  Would they
be willing to make last minute contributions?  This seems appropriate
since this appears where SPF is headed based upon the level of
corporate buy in.
What sort of contributions?
Dear Murray,

In essence, points made by Hotmail et al  was in regard to quality of results compared against that of Sender-ID.  It sounded like these results were seen as sufficient even for those who were stalwart Sender-ID advocates.  The highlights of this information suggested that it strongly supported claims made by John Levine, for example.  While this might seem like a reach, perhaps it would also help satisfy those less familiar with SPF+DKIM in conjunction with "Organizational Domain" policy assertions.  It seems "Organizational Domain" is new to the IETF.  But since this is where traction is growing in establishing greater levels of policy enforcement, it seems this information could offer rather convincing support of the notion for dropping Sender-ID when the policy function is better handled by SPF in conjunction with DKIM and Organizational Domain policies.

Regards,
Douglas Otis

_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis
--------------070900080409090906090102-- From vesely@tana.it Thu Apr 26 23:00: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 E332F21F86D4 for ; Thu, 26 Apr 2012 23:00:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROC4yx-FDgyZ for ; Thu, 26 Apr 2012 23:00:16 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6C321F86C4 for ; Thu, 26 Apr 2012 23:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335506405; bh=m/J3fY+nsu9UVPI1apRLxn+VonMLR1dycYHNXgABqkg=; l=965; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=JEO0wGrNonwtCJbd1C0KT+tsPO2UQzhd7Sf/EqrG6dvTTee5GOOtlJBMlJW7CkjIH 3S9yAMWigBrKqsQNhzjhZO4JMqO9gfCXAfUKoZLGgNa8QfcKCnuCR0lsx1h7HqJR0G Q7E/RCbTcEjfsVdgTTF5jHG3u9R2fKugaOmmstyM= 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, 27 Apr 2012 08:00:05 +0200 id 00000000005DC039.000000004F9A35E5.000033A3 Message-ID: <4F9A35E4.9000205@tana.it> Date: Fri, 27 Apr 2012 08:00:04 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F96E016.1030905@tana.it> <20120424181059.GM55967@mail.yitter.info> <4F97DB7B.2070905@tana.it> <4F980119.7000700@isdg.net> In-Reply-To: <4F980119.7000700@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 27 Apr 2012 06:00:17 -0000 On Fri 27/Apr/2012 07:53:49 +0200 Hector Santos wrote: > Alessandro Vesely wrote: > >> Do we think a survey could sort out such an effect?? > > I don't. Never mind that you won't get the sampling needed, surveys > can be skewed in any direction you want. Plus, without a doubt, based > on my engineering training and nearly 25+ years of real mail system > design of proprietary and open standards, I would have a completely > different set of R&D questions. I don't need to concur with Mr. > Sullivan, but I doubt we would even be able to get agreement on what > should be the survey questions. Here's what I've been able to come up with: https://www.surveymonkey.com/s/SPF-deployment-survey Please complete it. It will only take three minutes (ten questions on a single page). Please help reaching all mail admins by posting that link to specialized mailing lists and mail admins you are in touch with, worldwide. Thank you in advance! From hsantos@isdg.net Fri Apr 27 05:37: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 93A8D21F87D5 for ; Fri, 27 Apr 2012 05:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8ovGTWCVdHq for ; Fri, 27 Apr 2012 05:37:42 -0700 (PDT) Received: from dkim.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E52A721F87D0 for ; Fri, 27 Apr 2012 05:37:41 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3040; t=1335530250; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=RnescEt7Jt9RrzNrC04x7L526+4=; b=aw2isJxzRdCnw9NeyL03 Ypg+WLskHuAYLbmK4kSfZApyzXQyyxEg0qU8KPbx0q1FitYfkVpJ/psW9A8UQb4s UM+b7EmXyty65q1DgGFtjhPyTLpbxmcmRmtZ6vOs1E2oXvNQ2j8ttBJkLE+YhwZ1 oEhooXXJP+1qdq2Dy8fEbXU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 27 Apr 2012 08:37: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 v6.4.454.1) with ESMTP id 142096715.39322.5504; Fri, 27 Apr 2012 08:37:29 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3040; t=1335529906; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Cit7/9x uL1hV4PN2m0E/dxDEm75lPjEkXaYv/XFES0w=; b=D+grJQGaPYgJv1FF76Co8Hp CLcuX1D7qlOYQeFPZiuFrot/rNnCvFlZJp6WP48+6lK9RJBDKvCWNpQamZiYM1qj VbwgIdQPuNceXLiDglm26uwTJmKveRZ+J7dmsiw4v0gRoFSvMl/yuAsVDnprfKNU a6DvA4WIdEPkkW/syg6Q= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 27 Apr 2012 08:31:46 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 740993691.3651.3460; Fri, 27 Apr 2012 08:31:44 -0400 Message-ID: <4F9A92FD.2000205@isdg.net> Date: Fri, 27 Apr 2012 08:37:17 -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: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F96E016.1030905@tana.it> <20120424181059.GM55967@mail.yitter.info> <4F97DB7B.2070905@tana.it> <4F980119.7000700@isdg.net> <4F9A35E4.9000205@tana.it> In-Reply-To: <4F9A35E4.9000205@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 27 Apr 2012 12:37:43 -0000 Alessandro Vesely wrote: > > Here's what I've been able to come up with: > > https://www.surveymonkey.com/s/SPF-deployment-survey > > Please complete it. It will only take three minutes (ten questions on > a single page). Out of curiosity, I completely the survey. > Please help reaching all mail admins by posting that link to > specialized mailing lists and mail admins you are in touch with, > worldwide. Thank you in advance! I would like to support your effort, but I don't believe this survey caters to all market base profiles, for example, as a vendor, I had to check all the options for all the questions since all of them applied. Overall, IMO this survey should not have any bearing on 4408BIS decision making. The functional (What we want) and technical (how it is done) specification should be agnostic to the level of scale and usage of any one or more particular protocol feature. There of many examples to show but just using the question with the option: [_] An SPF result of FAIL causes the message to be rejected immediately is moot because it is already part of the RFC4405-4408 functional and technical specification that is part of the protocol as an deployment option. The skewed result showing 33% is meaningless unless the surveys intent is to change the specification to eliminate this existing RFC4408 deployment option for 4408BIS. What would had of been interesting is to extract the type of operation the survey user has for a concentrated motivation in his specific mode of SPF deployment. For example, Please describe your role as a SPF implementator or deployment: [_] Vendor (for resell, others to use) [_] Operators of vendor software (commercial, free, open source, etc) [_] ISV or 3rd party developers (write plug-ins for vendor software) [_] In-house, custom, provisional developers (not for others to use) [_] Other role This allows you to see the level of protocol support, what features are used, what can they do or not do, etc. For example, a vendor generally needs to make available all options and protocol features available for operators to choose, where other types will just be privy to a need specific world of smaller needs and what features are turned on or off, etc. Very different motivations, and IMV a robust protocol is designed for all roles despite what one group, dominant or otherwise, may suggest is better for all. IMV, its interesting, but this survey can not change the functional and technical specification of 4408BIS. A proper survey should attempt to see where there are protocol conflicts and use this to make the corrections, i.e. like the above question related to REJECT-ON-FAIL currently allowed by the RFC4408 specification. The suggestion and implication of a "Almost Nobody" does this is moot unless again the intent is to propose the removal of rejection semantics from the 4408 specification -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From hsantos@isdg.net Fri Apr 27 07:41: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 39DBD21F86B3 for ; Fri, 27 Apr 2012 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTTKajSjU6NC for ; Fri, 27 Apr 2012 07:41:53 -0700 (PDT) Received: from winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A843121F86AD for ; Fri, 27 Apr 2012 07:41:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2575; t=1335537705; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=NaW2KeJIPMo9kOf9DEXzb1EGQ3A=; b=KXFkiG3j9Rn7Sz33dHxL YvSNWI/viGtC7CatgV0ZzxbjTbXMKnO54jgx88dxluP/TYSAlL0stf7gygp5Z266 P7cDS/onmR3IAgjd7IbZ0O/cSh4BAlyPEYjRH0C17t/REhVHReQDnmTQSI5smyYp QDIVGPYABuODhZlfAcc/bto= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 27 Apr 2012 10:41:45 -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 v6.4.454.1) with ESMTP id 149552096.39322.4456; Fri, 27 Apr 2012 10:41:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2575; t=1335537361; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=p3re5tr 5VPOaewHXfPmfb0vxZKnIqgPOr1a9of9jrss=; b=QUCJDGx+ksozi0XB3oXr+vh gVzqC2tt6ckO55wEwed88mnJNWJ5NIhXFkUZNuAZDpt0t2lzaUcw6H6buP8+rscF qSAybmzcRKXyB5QPfKpW3C3jbKpl5ZtqOhYonLH5rnMRxR79Z7pX2ci4zectPWj+ DVjtKb2QEZGLMHnF4ERI= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 27 Apr 2012 10:36:01 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 748449534.3669.740; Fri, 27 Apr 2012 10:36:00 -0400 Message-ID: <4F9AB01C.2000708@isdg.net> Date: Fri, 27 Apr 2012 10:41:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F96E016.1030905@tana.it> <20120424181059.GM55967@mail.yitter.info> <4F97DB7B.2070905@tana.it> <4F980119.7000700@isdg.net> <4F9A35E4.9000205@tana.it> <4F9A92FD.2000205@isdg.net> In-Reply-To: <4F9A92FD.2000205@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, Alessandro Vesely Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 27 Apr 2012 14:41:55 -0000 A follow up note: Hector Santos wrote: > > There of many examples to show but just using the question with the option: > > [_] An SPF result of FAIL causes the message to be rejected immediately > > is moot because it is already part of the RFC4405-4408 functional and > technical specification that is part of the protocol as an deployment > option. The skewed result showing 33% is meaningless unless the surveys > intent is to change the specification to eliminate this existing RFC4408 > deployment option for 4408BIS. To show there is no bias, lets assume the percentage here showed something that was 80% of more for immediate rejection deployment majority. Does that have any significant meaning the current MARK-ON-FAIL receiver option is no longer significant due to a low method usage and therefore should be removed from the specification so that REJECT-ON-FAIL is the only consistent deployment expectation? No, I submit it does not because its a valid protocol option, dangerous in my personal view, but nonetheless valid as part of the current functional specs already established in 4408. But IMV, the survey might include questions related to the 4408 lack of a technical specification for MARK-ON-FAIL option left undefined or left open-ended by design: Please describe how MARK-ON-FAIL is implemented in your SPF server: [_] Received-SPF: fail is recorded [_] Authentication-Result: spf=fail is recorded [_] SPF fail mail is quarantined into a "junk email" or similar user folder. [_] SPF fail mail is bundled with user's MUA POP3 protocol mail pickup. and related: What kind of MUA portal access if allowed on your server? [_] Online MUA, i.e. Web Mail, Mobile device, i.e THIN DEVICE [_] Offline MUA with POP3 access, [_] Mixed Online/Offline MUA with IMAP access [_] Other For systems that offer a full range of multi-device mail access portals as illustrated in the following diagram, a common protocol that works with all methods at the backend and does not allow for security loopholes is critical important. http://beta.winserver.com/public/wcrpc/wcrpcnet7.png Assuming an IETF protocol-based offline MUA as the primary method and the only method tp consider to access mail is IMV a critical fault for a protocol such as SPF. While the survey does not ask these protocol deployment questions, I am hoping the WG will recognize the consideration come 4408 updating with 4408BIS. -- Hector Santos, CTO http://www.santronics.com http://hector.wildcatblog.com From dhc@dcrocker.net Fri Apr 27 08:29: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 F3F3921F87C0 for ; Fri, 27 Apr 2012 08:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AsQjmAaI6M8 for ; Fri, 27 Apr 2012 08:29:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F224D21F86DB for ; Fri, 27 Apr 2012 08:29:33 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3RFTVo9024218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Apr 2012 08:29:32 -0700 Message-ID: <4F9ABB4E.5080600@dcrocker.net> Date: Fri, 27 Apr 2012 08:29:18 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Andrew Sullivan References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> In-Reply-To: <20120424164901.GK55967@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 27 Apr 2012 08:29:32 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use SPF? 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, 27 Apr 2012 15:29:35 -0000 On 4/24/2012 9:49 AM, Andrew Sullivan wrote: > Whom do we ask? How do we select that sample? > > Moreover, how do we make sure that the sample isn't biased? What > you're asking for is a self-selected sample. They're notoriously > tricky to use. (I don't know very much, but I know really quite a lot > about survey design, and I urge all of you not to give me the > opportunity to bore you.) Just to add another common negative into the mix: Surveys are typically good for recording personal preferences and attitudes and strikingly bad at recording 'behaviors', especially estimates of performance numbers. Hence, a survey like this is probably going to measure respondent's beliefs and attitudes, rather than producing hard numbers. As such, I can't imagine any benefit in the survey. We don't need the information it will produce. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Fri Apr 27 09:35: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 AF05921F859A for ; Fri, 27 Apr 2012 09:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6heOdxxZ8Ssi for ; Fri, 27 Apr 2012 09:35:54 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2E321F8584 for ; Fri, 27 Apr 2012 09:35:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 34bt1j0010as01C014btBx; Fri, 27 Apr 2012 09:35:53 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=VPNfbqzX c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=R3_z1xM1jp4A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=Kl13J9qFS-hmNyA9XfMA:9 a=aubO1U7a9slperAjw0cA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 09:35:53 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] How about using SurveyMonkey to ask mail admins how they use SPF? Thread-Index: AQHNIjoptVxOwsJ5TEy1GiFcp11H/JavRekA//+cE4A= Date: Fri, 27 Apr 2012 16:35:53 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928104E37@exch-mbx901.corp.cloudmark.com> References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F9ABB4E.5080600@dcrocker.net> In-Reply-To: <4F9ABB4E.5080600@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335544553; bh=abVHrbNvQSYg+ic0uitEZulW/TMaEQMhBHBiYlZIhW8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=mp4H0ERC15Bn5cc5lAF78aNiM3KHjLIhQ1LR0bYnUYu4wME53gxSkHayTA6lPu8b1 j/9Du9ZI7lYA0wKKumXiVKm4Mo22ebPUBLxveaV8XB6L2f7fGTvd0ttzEYmZFGSw5B Kej4mXjYVPiVOqg8HQ76DCrIHR7HKftrQy7e/CiE= Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 27 Apr 2012 16:35:54 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave Crocker > Sent: Friday, April 27, 2012 8:29 AM > To: Andrew Sullivan > Cc: spfbis@ietf.org > Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how= they use SPF? >=20 > Hence, a survey like this is probably going to measure respondent's > beliefs and attitudes, rather than producing hard numbers. >=20 > As such, I can't imagine any benefit in the survey. We don't need the > information it will produce. I'm also concerned with anonymity and data pollution. If you were to ask f= or answers about the DNS and MTA surveys, I can tell you which domain said = what when and how fast. If I were to look at one response from a survey of= people, there's subjectivity in the answer. And each DNS server or MTA po= lled gets exactly one Boolean answer, but there's no guarantee of that in a= human survey. Even with the mush around the record re-use question, I think conclusions b= ased on the DNS and MTA surveys will be substantially more defensible. -MSK From vesely@tana.it Fri Apr 27 11:07: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 198BD21F8646 for ; Fri, 27 Apr 2012 11:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.638 X-Spam-Level: X-Spam-Status: No, score=-4.638 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIWXk9ixmeJ2 for ; Fri, 27 Apr 2012 11:07:54 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A3BA421F8633 for ; Fri, 27 Apr 2012 11:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335550069; bh=LUobrarBakyIv0TQVkyTnVMlLJq+2Hq7tn4YsjZSpww=; l=785; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OV4DrWQXuj7P5dkViUspE/k6nreGmOLSD72KOJDQC9kJ+dIkyXG5n7Mgis4I8VrJr ZhcFa//AkADu7liPNU3fG0z9yHJOKWaM7DKEXgCHUKGxp18DGaHMYq7dDo67+5Vmd2 Uv9vCusKO0po3nSULXnGeyiUmeIFyUkW0vq70iNw= 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, 27 Apr 2012 20:07:49 +0200 id 00000000005DC03F.000000004F9AE075.0000687D Message-ID: <4F9AE075.3020202@tana.it> Date: Fri, 27 Apr 2012 20:07:49 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F96CE10.8060703@tana.it> <20120424164901.GK55967@mail.yitter.info> <4F9ABB4E.5080600@dcrocker.net> In-Reply-To: <4F9ABB4E.5080600@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] How about using SurveyMonkey to ask mail admins how they use 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, 27 Apr 2012 18:07:59 -0000 On Fri 27/Apr/2012 19:39:35 +0200 Dave Crocker wrote: > > Just to add another common negative into the mix: > > Surveys are typically good for recording personal preferences and > attitudes and strikingly bad at recording 'behaviors', especially > estimates of performance numbers. Yup. I don't get why this is deemed negative. > Hence, a survey like this is probably going to measure respondent's > beliefs and attitudes, rather than producing hard numbers. We already have some hard numbers. > As such, I can't imagine any benefit in the survey. We don't need the > information it will produce. However we'll craft the SPF spec, that is going to redound upon mail admins' beliefs and attitudes. If we are better informed, we can possibly be more effective. From sm@elandsys.com Fri Apr 27 17:09: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 D0F7521F8594 for ; Fri, 27 Apr 2012 17:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9vSi9z9sbvp for ; Fri, 27 Apr 2012 17:08:59 -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 5671421E8027 for ; Fri, 27 Apr 2012 17:08:59 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.46]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3S08hJ0014051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 17:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335571735; i=@elandsys.com; bh=GQxAnefG2zOSgR47rdyE85PrmAzFUPGu/j8ksZtCU1c=; h=Date:To:From:Subject:Cc; b=r1LQyTHn2fH82sQEjFbkHrrnE7b7VMSrRMY9Dqt4rmem0iFbEv3S2Brst4NVs9B5j p0xczSuwb9UuzuexWTsGdfiYmzVP/cCfybOoDjGTMWlEYtfgiRF/bpS+p+nYu7FwqS 9ZC1mH1Au278vnNfeCmkburFcP0dayeVccSKARW4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335571735; i=@elandsys.com; bh=GQxAnefG2zOSgR47rdyE85PrmAzFUPGu/j8ksZtCU1c=; h=Date:To:From:Subject:Cc; b=uR5/ls2Qnm9eBpaztfGKX2E1t2bi0cDY1ZMDWpGdoeFtrQghfde15dyqEPPMgvAzV hQxHVZaceQzJABjxhfJ45nOY5yj/+ayxQ8hnje+wqpVUpBksG0FRltdkrbegW1v8AN 1PL+Vzfq8jVh59sF0yEwoFOgIQQF6MxetZ/zNyLo= Message-Id: <6.2.5.6.2.20120427170554.09b01580@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 27 Apr 2012 17:07:42 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: [spfbis] IETF83 SPFBIS minutes X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Apr 2012 00:09:01 -0000 Hello, The minutes for the IETF83 SPFBIS session is at http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt Regards, S. Moonesamy SPFBIS WG co-chair From pmidge@messagebus.com Sat Apr 28 12:08: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 2B78921F8691 for ; Sat, 28 Apr 2012 12:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VLKsJCIVsEg for ; Sat, 28 Apr 2012 12:08:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A89621F8686 for ; Sat, 28 Apr 2012 12:08:07 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2225362pbb.31 for ; Sat, 28 Apr 2012 12:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=messagebus.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=C9ZXanCgV3J1LbibsKwMSvgleAn7nxT88fPk9pKL60I=; b=YpW0LNl5upReXO1zExxq8dihPbsr/50xBbwozzYAbO1iFMKYGqY0meOUS0DCzFEXfU flOAJ41URtRygJ/zG+aHuL41W+OoOCeAecRJlTmeYkkiU5cJzzJKejZymgKxT7BrazcF U7vqB8+jzKCq9Aw2fqTxxPgiri8SFOvRF6nrQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=C9ZXanCgV3J1LbibsKwMSvgleAn7nxT88fPk9pKL60I=; b=TvDZD6Y8BI7d5o2sbPKgb/KsD4aMMy8n5jGGENXuZPJJwRWM+aXfs3i3OdF9rTpWet 9yHZWiOaAJBQXlzYBoyTnWkt7GnBjjnSB6Uld2pcYY2MZtqVJHMUmICjuD3vmxJLYwKJ JrJEDVM+rPGBHvpvqjxwJ1ggSbOkRywd7yHxA7XUx++kY3sKXNYpI8byjdF6xFiQK9Ua tIxU7Reu4XsPVPc8HRHRHpNnz3PfvtpHVhVA6+cQL9Hs3cXkauAt1+3xRQIjnybYUhtU +PeZ3TnwygakRQqfGkPZYtLvJPyPji53BlVra3fsF84SBLA1k/Ri/zXQpCS8WKw5S22v +JoQ== Received: by 10.68.190.69 with SMTP id go5mr34004155pbc.98.1335640086945; Sat, 28 Apr 2012 12:08:06 -0700 (PDT) Received: from percival.local (c-98-234-236-249.hsd1.ca.comcast.net. [98.234.236.249]) by mx.google.com with ESMTPS id pt8sm10428005pbc.64.2012.04.28.12.08.06 (version=SSLv3 cipher=OTHER); Sat, 28 Apr 2012 12:08:06 -0700 (PDT) Message-ID: <4F9C4017.70200@messagebus.com> Date: Sat, 28 Apr 2012 12:08:07 -0700 From: Paul Midgen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <9452079D1A51524AA5749AD23E0039281031B6@exch-mbx901.corp.cloudmark.com> <20120426121957.6129.qmail@joyce.lan> <9452079D1A51524AA5749AD23E0039281039A5@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039281039A5@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="------------040302040502000909050702" X-Gm-Message-State: ALoCoQlgkFQM3RU1GqReVsSmzbxGdiJMB9e5cCnW1eONWRPc4mmRpm0+m8ohjS3ti+q5qkoj9OY5 Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Apr 2012 19:08:08 -0000 This is a multi-part message in MIME format. --------------040302040502000909050702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG chairs: having read/commented/suggested changes to several revisions of draft-ietf-spfbis-experiment please consider this my official +1 in favor of approving the WG last-call text. On 26-Apr/12 6:57 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: John Levine [mailto:johnl@taugh.com] >> Sent: Thursday, April 26, 2012 5:20 AM >> To: spfbis@ietf.org >> Cc: Murray S. Kucherawy >> Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >> >>> I don't agree that that's the only reasonable assumption. It seems >>> more likely to me that different answers might also come from the fact >>> that the PRA produced a different domain than the MAIL FROM domain in >>> those cases, resulting in a different policy being evaluated >> altogether, independent of the DNS reuse question. >> >> Except that there isn't anything like 5% of the senders publishing S-ID >> records. Those checks probably did use a different domain, but if they >> checked it against an SPF record intended for envelope domains, that's >> a bug. > I don't think this is the right document for that kind of analysis. In my opinion, we should keep it focused on the question of what got adopted, as that's enough to answer the "consensus" question from the IESG note and advance SPF to the Standards Track. > > And we've seen how even collecting and analyzing data about what's in use, separate from efficacy, can rathole on a bunch of hypothetical and orthogonal questions even though that analysis isn't subjective. It's scary to think about how long an in-depth analysis about those other questions would take to reach consensus. > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis --------------040302040502000909050702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit WG chairs: having read/commented/suggested changes to several revisions of draft-ietf-spfbis-experiment please consider this my official +1 in favor of approving the WG last-call text.

On 26-Apr/12 6:57 AM, Murray S. Kucherawy wrote: 
-----Original Message-----
From: John Levine [mailto:johnl@taugh.com]
Sent: Thursday, April 26, 2012 5:20 AM
To: spfbis@ietf.org
Cc: Murray S. Kucherawy
Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment


I don't agree that that's the only reasonable assumption.  It seems
more likely to me that different answers might also come from the fact
that the PRA produced a different domain than the MAIL FROM domain in
those cases, resulting in a different policy being evaluated

altogether, independent of the DNS reuse question.

Except that there isn't anything like 5% of the senders publishing S-ID
records.  Those checks probably did use a different domain, but if they
checked it against an SPF record intended for envelope domains, that's
a bug.

I don't think this is the right document for that kind of analysis.  In my opinion, we should keep it focused on the question of what got adopted, as that's enough to answer the "consensus" question from the IESG note and advance SPF to the Standards Track.

And we've seen how even collecting and analyzing data about what's in use, separate from efficacy, can rathole on a bunch of hypothetical and orthogonal questions even though that analysis isn't subjective.  It's scary to think about how long an in-depth analysis about those other questions would take to reach consensus.

-MSK
_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis
--------------040302040502000909050702-- From dhc@dcrocker.net Sun Apr 29 10:54: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 2523521F84CD for ; Sun, 29 Apr 2012 10:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.078 X-Spam-Level: X-Spam-Status: No, score=-5.078 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRzR5Bar-Hva for ; Sun, 29 Apr 2012 10:54:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 550AB21F8469 for ; Sun, 29 Apr 2012 10:54:16 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3THsFW3022621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 29 Apr 2012 10:54:15 -0700 Message-ID: <4F9D8038.3040601@dcrocker.net> Date: Sun, 29 Apr 2012 10:54:00 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 CC: spfbis@ietf.org References: <20120424204450.GR55967@mail.yitter.info> In-Reply-To: <20120424204450.GR55967@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 29 Apr 2012 10:54:15 -0700 (PDT) Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment 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, 29 Apr 2012 17:54:17 -0000 On 4/24/2012 1:44 PM, Andrew Sullivan wrote: > This message begins a 2 week Working Group Last Call on the document > draft-ietf-spfbis-experiment-07. > > Please perform a complete review of the document and send your remarks > to the mailing list. I have participated in the working group discussions leading to the last call and have done a final review on the document. I believe the document is well-organized and clearly written and is sufficient to its purpose. It is ready for publication. Minor suggestions, none of which I deem critical to the document's utility, but potentially useful for aiding casual readers or those lacking bits of relevant expertise. Where I suggest adding a conclusion, or the like, I don't care whether it's located in the place I suggest or in Section 5, Analysis or Section 6, Conclusion. > 3.1. DNS Resource Record Types ... > these surveys pulled a large number of domain names > from recent activity logs The surveys are, presumably, distinguished by which activity logs they were based on. The introduction should state this and should provide some basic description of the operational activities that provided the sources of logging data. A log from a personal email operation is a rather different sampling environment from an email service provider having hundreds of millions of mailboxes... As I recall, these are activity logs of large receivers. Unless there is a reason to sanitize their names, use them. Otherwise, provide some generic description of their salient characteristics. For example, "extremely large service provider that receives mail" probably fits one or more... (By the way, I suggest avoiding the term "MX server or the like, since A records are still valid for finding an email receiving host, aren't they?) The highly indirect reference to contributors to the analysis, cited in the Acknowledgements is, IMO, too indirect for the concreteness I think useful to the inline text. Also, what is the difference between an "activity log" and a "nameserver log"? The text uses both terms without explanation. (I'm suggesting adding clauses, not sentences, to explain these.) > 3.2. Implementations It might be worth adding an analytic conclusion suggesting that these data point mean that there are reasonably good software choices for using either mechanism, so that the gating factor probably was operational policy, rather than lack of coding sources. The fact that SPF has 80% more implementations might be worth noting, but it's pretty obvious and might or might not be all that significant. > 3.3. The SUBMITTER SMTP Extension I suggest starting with a one sentence summary of the function. It isn't explained elsewhere in the doc. Hmmm, probably worth doing a sentence describing PRA, too. > Fewer than 4.5% of these advertised the > SUBMITTER extension. This is picky, but the earlier, table format for this kind of data, makes it particularly easy to extract core data from the document. I suggest re-using the format for all data, such as the one here. > Over 97% of the responding MTAs advertising the SUBMITTER SMTP > extension were different instances of one MTA. My general fear of common problems in casual reading during reviews worries that this sentence might be mis-read to mean that 97% of active MTAs implement the feature, rather than 97% of the 4.5%. > 4. Evidence of Differences It is probably worth adding a sentence at the end of this section that observes something along the lines of: Anecdotally, the differences in conclusions have not been noted as causing significant operational problems by the email-receiving community. > 5. Analysis ... > 6. Although they may be marginal, there remain obstacles to > deployment of protocols that use DNS RRTYPEs other than the most > common ones, Drop the opening clause. Opinions about the import of the obstacles vary quite a bit, and it is not necessary to resolve it in this document. The fact is that barriers remain and that they are important enough to mention here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Sun Apr 29 23:29: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 5A1FB21F85B5 for ; Sun, 29 Apr 2012 23:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2I04mr1eMkz for ; Sun, 29 Apr 2012 23:29:52 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id B218421F85A7 for ; Sun, 29 Apr 2012 23:29:52 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 46W51j0010as01C016W50v; Sun, 29 Apr 2012 23:30:05 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=K4ag7lqI c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=6gJ3-FW0yAcA:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=o84K0rgcPhXUemd5JfEA:9 a=Xx7JGkh7lOcruzYORKkA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=29IQjJzvghIydoUn:21 a=uIALAxcAtQLXc2z9:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Sun, 29 Apr 2012 23:29:41 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNIlseXt7nF5KnvEq9U7F2f34qNJaykr8AgABbSVA= Date: Mon, 30 Apr 2012 06:29:40 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4F9D8038.3040601@dcrocker.net> In-Reply-To: <4F9D8038.3040601@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335767405; bh=OTRnfmj9bxfgZDgtJ+nzlOu1LOuptHJ66lbMcLUhPB4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=poQlYLjsXQRs1ZfVIjXOo2naBeJU1MawGJr0qFOI0Llan5P+GLVxZtyfxf0uYI9rm vSLHLTYMSK1Gx+/DNez2hDBEbovQXjwgY6+1g/ddTWRyHXmb4JTJUqbSJrd0FroRfJ ds+UqszFgFtwMq4qjwiVQknoLF6gbYSZ5br5kohg= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Apr 2012 06:29:53 -0000 I have made the changes stated below in my working copy, but will hold off = including them in a posted -08 until we're sure there's no objection and WG= LC has ended (or the chairs direct me otherwise). > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Dave Crocker > Sent: Sunday, April 29, 2012 10:54 AM > Cc: spfbis@ietf.org > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > > 3.1. DNS Resource Record Types > ... > > these surveys pulled a large number of domain names > > from recent activity logs >=20 > The surveys are, presumably, distinguished by which activity logs they > were based on. The introduction should state this and should provide > some basic description of the operational activities that provided the > sources of logging data. A log from a personal email operation is a > rather different sampling environment from an email service provider > having hundreds of millions of mailboxes... In all cases they were based on domains found in actual email traffic, so I= 've tweaked that text to say so explicitly. > As I recall, these are activity logs of large receivers. Unless there > is a reason to sanitize their names, use them. I've added the survey numbers in the case of the DNS surveys to the credits= at the end, which allows attribution. I could add them parenthetically to= the "DNS Survey #X" tags as well if you like. > Also, what is the difference between an "activity log" and a > "nameserver > log"? The text uses both terms without explanation. (I'm suggesting > adding clauses, not sentences, to explain these.) Clarified in the text. "activity log" is email traffic data; "nameserver l= og" is a trace of queries received by a nameserver. > > 3.2. Implementations >=20 > It might be worth adding an analytic conclusion suggesting that these > data point mean that there are reasonably good software choices for > using either mechanism, so that the gating factor probably was > operational policy, rather than lack of coding sources. Added. > > 3.3. The SUBMITTER SMTP Extension >=20 > I suggest starting with a one sentence summary of the function. It > isn't explained elsewhere in the doc. >=20 > Hmmm, probably worth doing a sentence describing PRA, too. Added. > > Fewer than 4.5% of these advertised the > > SUBMITTER extension. >=20 > This is picky, but the earlier, table format for this kind of data, > makes it particularly easy to extract core data from the document. I > suggest re-using the format for all data, such as the one here. I'll see what I can come up with. There are so few numbers in this case th= at it seems like overkill to create a table, but perhaps I can add a line t= hat's more illustrative to make it worthwhile. > > Over 97% of the responding MTAs advertising the SUBMITTER SMTP > > extension were different instances of one MTA. >=20 > My general fear of common problems in casual reading during reviews > worries that this sentence might be mis-read to mean that 97% of active > MTAs implement the feature, rather than 97% of the 4.5%. Fixed. > > 4. Evidence of Differences >=20 > It is probably worth adding a sentence at the end of this section that > observes something along the lines of: >=20 > Anecdotally, the differences in conclusions have not been noted > as > causing significant operational problems by the email-receiving > community. Added. > > 5. Analysis > ... > > 6. Although they may be marginal, there remain obstacles to > > deployment of protocols that use DNS RRTYPEs other than the > most > > common ones, >=20 > Drop the opening clause. Opinions about the import of the obstacles > vary quite a bit, and it is not necessary to resolve it in this > document. >=20 > The fact is that barriers remain and that they are important enough to > mention here. Done. -MSK From dhc@dcrocker.net Mon Apr 30 09:31: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 9046B21F86FE for ; Mon, 30 Apr 2012 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.751 X-Spam-Level: X-Spam-Status: No, score=-5.751 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lgM-QLi3nCO for ; Mon, 30 Apr 2012 09:31:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BDCF721F86FA for ; Mon, 30 Apr 2012 09:31:19 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3UGV78M011438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Apr 2012 09:31:08 -0700 Message-ID: <4F9EBE4B.8080100@dcrocker.net> Date: Mon, 30 Apr 2012 09:31:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120424204450.GR55967@mail.yitter.info> <4F9D8038.3040601@dcrocker.net> <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.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]); Mon, 30 Apr 2012 09:31:08 -0700 (PDT) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment 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, 30 Apr 2012 16:31:20 -0000 Sorry for dragging this out another iteration... On 4/29/2012 11:29 PM, Murray S. Kucherawy wrote: >> The surveys are, presumably, distinguished by which activity logs >> they were based on. The introduction should state this and should >> provide some basic description of the operational activities that >> provided the sources of logging data. A log from a personal email >> operation is a rather different sampling environment from an email >> service provider having hundreds of millions of mailboxes... > > In all cases they were based on domains found in actual email > traffic, so I've tweaked that text to say so explicitly. My concern was about 'actual' versus something else, but about which types of activity were being logged. The last sentence, above, was meant as an example of the distinction I think would help some readers. That is, the question is /which/ activity was logged and by whom or by what kind of 'whom'. >> As I recall, these are activity logs of large receivers. Unless >> there is a reason to sanitize their names, use them. > > I've added the survey numbers in the case of the DNS surveys to the > credits at the end, which allows attribution. I could add them > parenthetically to the "DNS Survey #X" tags as well if you like. Again, my intent is to focus on a characterization of the organization doing the logging, so the reader will have a sense of the nature and scale of their operation. That will provide a heuristic about the population of data from which they are logging activity. >>> Fewer than 4.5% of these advertised the SUBMITTER extension. >> >> This is picky, but the earlier, table format for this kind of >> data, makes it particularly easy to extract core data from the >> document. I suggest re-using the format for all data, such as the >> one here. > > I'll see what I can come up with. There are so few numbers in this > case that it seems like overkill to create a table, but perhaps I can > add a line that's more illustrative to make it worthwhile. My suggestion is totally Procrustean. I'm only making it because I believe the numbers are the essence of the report and that a document like this gets casual readers who tend to scan rather than contemplate the data. The tabular format greatly aids the scanning. Again, my focus is on looking for way to bullet-proof against misreading. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pgladstone@cisco.com Mon Apr 30 12:03: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 8D68621F8577 for ; Mon, 30 Apr 2012 12:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.683 X-Spam-Level: X-Spam-Status: No, score=-9.683 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHMxrBNLok1f for ; Mon, 30 Apr 2012 12:03:52 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 375D421F8693 for ; Mon, 30 Apr 2012 12:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=9235; q=dns/txt; s=iport; t=1335812632; x=1337022232; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=Xta3YBvf4pRIAIL6mKtRONG96xOvGwZqFCwXUambhBA=; b=LF1yHAWVaLRmXYYkPcMJacYSyLg+lf04/M98Zw6aoZpQXOAjn1WrVhHZ 84/HJvGcN09x4G5FQJnGSeQHsiSSdd3GJe1wEyzeASTWan3+SX70PwK27 AucF3oywwTkyVz0+obig0thxGcs8CBBdidkf5lXPz4cfvWgLuPNjpRw1f g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAO3gnk+rRDoG/2dsb2JhbABBA4VoqWuDAIEHggkBAQEEEgEFC1UPAgsYCRYLAgIJAwIBAgEJPBMGAgEBHodqAZpEjROSbwSLB4JtghKBGASVfoV2iGOBaYMEgUA X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="scan'208,217";a="42839725" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 30 Apr 2012 19:03:52 +0000 Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3UJ3pPS018484 for ; Mon, 30 Apr 2012 19:03:51 GMT Message-ID: <4F9EE215.2020703@cisco.com> Date: Mon, 30 Apr 2012 15:03:49 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120424204450.GR55967@mail.yitter.info> <4F9D8038.3040601@dcrocker.net> <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> <4F9EBE4B.8080100@dcrocker.net> In-Reply-To: <4F9EBE4B.8080100@dcrocker.net> Content-Type: multipart/alternative; boundary="------------020008000401090208050905" Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Apr 2012 19:03:53 -0000 This is a multi-part message in MIME format. --------------020008000401090208050905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Not inline: The data that I provided was not from email traffic but was from the top = 1 million alexa websites. I did mix in the domains that I found in my=20 personal mailbox and it only added a few new domains ( > 90% of my=20 correspondents domains were already in the top 1 million list [170 out=20 of 1776 were newly added]). [When I say top 1M list, this was actually=20 the union of two top 1m lists from about a month apart. This totalled=20 1.23M entries. The other domains were in the noise, so the grand total=20 was 1.23M (1228850). To generate the sqlite database, each domain was=20 looked up, and if a include or redirect were found, then the target was=20 added to the list of domains to be looked up. I don't know how many of=20 these include/redirects were found.] Philip On 4/30/2012 12:31 PM, Dave Crocker wrote: > Sorry for dragging this out another iteration... > > > On 4/29/2012 11:29 PM, Murray S. Kucherawy wrote: >>> The surveys are, presumably, distinguished by which activity logs >>> they were based on. The introduction should state this and should >>> provide some basic description of the operational activities that >>> provided the sources of logging data. A log from a personal email >>> operation is a rather different sampling environment from an email >>> service provider having hundreds of millions of mailboxes... >> >> In all cases they were based on domains found in actual email >> traffic, so I've tweaked that text to say so explicitly. > > My concern was about 'actual' versus something else, but about which=20 > types of activity were being logged. The last sentence, above, was=20 > meant as an example of the distinction I think would help some=20 > readers. That is, the question is /which/ activity was logged and by=20 > whom or by what kind of 'whom'. > > >>> As I recall, these are activity logs of large receivers. Unless >>> there is a reason to sanitize their names, use them. >> >> I've added the survey numbers in the case of the DNS surveys to the >> credits at the end, which allows attribution. I could add them >> parenthetically to the "DNS Survey #X" tags as well if you like. > > Again, my intent is to focus on a characterization of the organization = > doing the logging, so the reader will have a sense of the nature and=20 > scale of their operation. That will provide a heuristic about the=20 > population of data from which they are logging activity. > > >>>> Fewer than 4.5% of these advertised the SUBMITTER extension. >>> >>> This is picky, but the earlier, table format for this kind of >>> data, makes it particularly easy to extract core data from the >>> document. I suggest re-using the format for all data, such as the >>> one here. >> >> I'll see what I can come up with. There are so few numbers in this >> case that it seems like overkill to create a table, but perhaps I can >> add a line that's more illustrative to make it worthwhile. > > My suggestion is totally Procrustean. I'm only making it because I=20 > believe the numbers are the essence of the report and that a document=20 > like this gets casual readers who tend to scan rather than contemplate = > the data. The tabular format greatly aids the scanning. > > Again, my focus is on looking for way to bullet-proof against misreadin= g. > > > > Thanks! > > d/ > > --=20 > Philip Gladstone > Distinguished Engineer > Product Development > pgladstone@cisco.com > Phone: +1 978-ZEN-TOAD (+1 978 936 8623) > Google: +1 978 800 1010 > Ham radio: N1DQ --------------020008000401090208050905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Not inline: 

The data that I provided was not from email traffic but was from the top 1 million alexa websites. I did mix in the domains that I found in my personal mailbox and it only added a few new domains ( > 90% of my correspondents domains were already in the top 1 million list [170 out of 1776 were newly added]). [When I say top 1M list, this was actually the union of two top 1m lists from about a month apart. This totalled 1.23M entries. The other domains were in the noise, so the grand total was 1.23M (1228850). To generate the sqlite database, each domain was looked up, and if a include or redirect were found, then the target was added to the list of domains to be looked up. I don't know how many of these include/redirects were found.]

Philip

On 4/30/2012 12:31 PM, Dave Crocker wrote:
Sorry for dragging this out another iteration...


On 4/29/2012 11:29 PM, Murray S. Kucherawy wrote:
The surveys are, presumably, distinguished by which activity logs
they were based on.  The introduction should state this and should
provide some basic description of the operational activities that
provided the sources of logging data.  A log from a personal email
operation is a rather different sampling environment from an email
service provider having hundreds of millions of mailboxes...

In all cases they were based on domains found in actual email
traffic, so I've tweaked that text to say so explicitly.

My concern was about 'actual' versus something else, but about which types of activity were being logged.  The last sentence, above, was meant as an example of the distinction I think would help some readers. That is, the question is /which/ activity was logged and by whom or by what kind of 'whom'.


As I recall, these are activity logs of large receivers.  Unless
there is a reason to sanitize their names, use them.

I've added the survey numbers in the case of the DNS surveys to the
credits at the end, which allows attribution.  I could add them
parenthetically to the "DNS Survey #X" tags as well if you like.

Again, my intent is to focus on a characterization of the organization doing the logging, so the reader will have a sense of the nature and scale of their operation.  That will provide a heuristic about the population of data from which they are logging activity.


Fewer than 4.5% of these advertised the SUBMITTER extension.

This is picky, but the earlier, table format for this kind of
data, makes it particularly easy to extract core data from the
document.  I suggest re-using the format for all data, such as the
one here.

I'll see what I can come up with.  There are so few numbers in this
case that it seems like overkill to create a table, but perhaps I can
add a line that's more illustrative to make it worthwhile.

My suggestion is totally Procrustean.  I'm only making it because I believe the numbers are the essence of the report and that a document like this gets casual readers who tend to scan rather than contemplate the data.  The tabular format greatly aids the scanning.

Again, my focus is on looking for way to bullet-proof against misreading.



Thanks!

d/ 

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
--------------020008000401090208050905-- From spf2@kitterman.com Mon Apr 30 14:25: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 CC07B21E8094 for ; Mon, 30 Apr 2012 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRyKYLgR7jK1 for ; Mon, 30 Apr 2012 14:25:12 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CF7E021E808B for ; Mon, 30 Apr 2012 14:25:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F1A9D20E410E; Mon, 30 Apr 2012 17:25:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1335821111; bh=n7wys81s20avA6AWHiQSw1oscaq+RNWXkwnV0ev6KlI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=UbaG2JowzIx913+9fWCyX1y6YKeudJWiOYl1Hk0s9MsCi7/gAy0bxKpM2WdcsZOnq vH7FCghpWWZ2mzu3OAQ2XwtxQBeYf2bUoK31iSa0QY2FCKlr5AGo/rLV/RT8u/1beU kmuGQejMr8CZ1sWi/nE0L9jfaFsHAP3YzlAZ1X/U= Received: from scott-latitude-e6320.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 ESMTPSA id D85A820E408F; Mon, 30 Apr 2012 17:25:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 30 Apr 2012 17:25:10 -0400 Message-ID: <4515001.OynnCJLaov@scott-latitude-e6320> User-Agent: KMail/4.8.2 (Linux/3.2.0-24-generic-pae; KDE/4.8.2; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4F9D8038.3040601@dcrocker.net> <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.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] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Apr 2012 21:25:12 -0000 On Monday, April 30, 2012 06:29:40 AM Murray S. Kucherawy wrote: > I have made the changes stated below in my working copy, but will hold off > including them in a posted -08 until we're sure there's no objection and > WGLC has ended (or the chairs direct me otherwise). > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Dave Crocker Sent: Sunday, April 29, 2012 10:54 AM > > Cc: spfbis@ietf.org > > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment > > > > > 3.1. DNS Resource Record Types > > > > ... > > > > > these surveys pulled a large number of domain names > > > > > > from recent activity logs > > > > The surveys are, presumably, distinguished by which activity logs they > > were based on. The introduction should state this and should provide > > some basic description of the operational activities that provided the > > sources of logging data. A log from a personal email operation is a > > rather different sampling environment from an email service provider > > having hundreds of millions of mailboxes... > > In all cases they were based on domains found in actual email traffic, so > I've tweaked that text to say so explicitly. > > As I recall, these are activity logs of large receivers. Unless there > > is a reason to sanitize their names, use them. > > I've added the survey numbers in the case of the DNS surveys to the credits > at the end, which allows attribution. I could add them parenthetically to > the "DNS Survey #X" tags as well if you like. > > Also, what is the difference between an "activity log" and a > > "nameserver > > log"? The text uses both terms without explanation. (I'm suggesting > > adding clauses, not sentences, to explain these.) > > Clarified in the text. "activity log" is email traffic data; "nameserver > log" is a trace of queries received by a nameserver. > > > 3.2. Implementations > > > > It might be worth adding an analytic conclusion suggesting that these > > data point mean that there are reasonably good software choices for > > using either mechanism, so that the gating factor probably was > > operational policy, rather than lack of coding sources. > > Added. > > > > 3.3. The SUBMITTER SMTP Extension > > > > I suggest starting with a one sentence summary of the function. It > > isn't explained elsewhere in the doc. > > > > Hmmm, probably worth doing a sentence describing PRA, too. > > Added. > > > > Fewer than 4.5% of these advertised the > > > > > > SUBMITTER extension. > > > > This is picky, but the earlier, table format for this kind of data, > > makes it particularly easy to extract core data from the document. I > > suggest re-using the format for all data, such as the one here. > > I'll see what I can come up with. There are so few numbers in this case > that it seems like overkill to create a table, but perhaps I can add a line > that's more illustrative to make it worthwhile. > > > Over 97% of the responding MTAs advertising the SUBMITTER SMTP > > > > > > extension were different instances of one MTA. > > > > My general fear of common problems in casual reading during reviews > > worries that this sentence might be mis-read to mean that 97% of active > > MTAs implement the feature, rather than 97% of the 4.5%. > > Fixed. > > > > 4. Evidence of Differences > > > > It is probably worth adding a sentence at the end of this section that > > > > observes something along the lines of: > > Anecdotally, the differences in conclusions have not been noted > > > > as > > causing significant operational problems by the email-receiving > > community. > > Added. > > > > 5. Analysis > > > > ... > > > > > 6. Although they may be marginal, there remain obstacles to > > > > > > deployment of protocols that use DNS RRTYPEs other than the > > > > most > > > > > common ones, > > > > Drop the opening clause. Opinions about the import of the obstacles > > vary quite a bit, and it is not necessary to resolve it in this > > document. > > > > The fact is that barriers remain and that they are important enough to > > mention here. > > Done. Since you're doing another update, I'll take another shot at resolving my objection to the introduction.... The current published version starts: In April 2006, the IETF published the [SPF] and Sender ID email authentication protocols, the latter consisting of three documents ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of a specific domain name. The two protocols made use of this same policy statement and some specific (but different) logic to evaluate whether the email client sending or relaying a message was authorized to do so. Consensus did not clearly support one protocol over the other, and there was significant concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents as Experimental, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication in order to determine a reasonable path forward. Reading it again, I'm also not sure any reference to consensus is appropriate as there were never any IETF attempts at consensus on these two documents. I'd be happy with the following if you think it's OK: In April 2006, the IETF published the [SPF] and Sender ID email authentication protocols, the latter consisting of three documents ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of a specific domain name. There was significant concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents as Experimental, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication in order to determine a reasonable path forward. I think that says enough for our purpose and avoids the issue I was concerned about. Scott K From msk@cloudmark.com Mon Apr 30 23:01: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 4298E21F86D7 for ; Mon, 30 Apr 2012 23:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.258 X-Spam-Level: X-Spam-Status: No, score=-102.258 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe+voEAaMFgZ for ; Mon, 30 Apr 2012 23:01:13 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id BB2B621F8656 for ; Mon, 30 Apr 2012 23:01:13 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 4W1d1j0010ZaKgw01W1d7d; Mon, 30 Apr 2012 23:01:37 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=WuKpwKjv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ePc26DvMG94A:10 a=_uL0CHs9PZ0A:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=n3p35pEGYvZFYFd26IkA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=cbBVmKM2sy6cR1Aob64A:9 a=n8MMC00fhG8opMHqbIoA:7 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=zGZ2ENc0OZBJVHWA:21 a=x59x6dQ_Ar0KwAgJ:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 23:01:12 -0700 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Thread-Topic: [spfbis] WGLC for draft-ietf-spfbis-experiment Thread-Index: AQHNIlseXt7nF5KnvEq9U7F2f34qNJaykr8AgABbSVCAAYyWQA== Date: Tue, 1 May 2012 06:01:12 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810794F@exch-mbx901.corp.cloudmark.com> References: <20120424204450.GR55967@mail.yitter.info> <4F9D8038.3040601@dcrocker.net> <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928106914@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.153] Content-Type: multipart/mixed; boundary="_002_9452079D1A51524AA5749AD23E00392810794Fexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335852097; bh=pLye7XKnPbPwlzDTyD+/hZFauvqNsEoOvrYiXaMYSjc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ejnaoK83kGuy98HTq2or+fyZw2f9W/YlLdtMLGZmEA+/PmhjaXYMvyLHrkQBy6jID W/v8H/2UEavH4BmWi5+Nvy/sjmw2l8zVycZ/7PsG6SZ2b0I+TCRpFRdJvxs6lvt43F xfyV6JTslwD5RfQ/yO0zxx+1xDeW/0khk7XKBiM4= Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 06:01:16 -0000 --_002_9452079D1A51524AA5749AD23E00392810794Fexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Sunday, April 29, 2012 11:30 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] WGLC for draft-ietf-spfbis-experiment >=20 > I have made the changes stated below in my working copy, but will hold > off including them in a posted -08 until we're sure there's no > objection and WGLC has ended (or the chairs direct me otherwise). A proposed diff to -07, for the WG's consideration. -MSK --_002_9452079D1A51524AA5749AD23E00392810794Fexchmbx901corpclo_ Content-Type: text/html; name="spfbis.html" Content-Description: spfbis.html Content-Disposition: attachment; filename="spfbis.html"; size=93372; creation-date="Tue, 01 May 2012 06:00:46 GMT"; modification-date="Tue, 01 May 2012 05:59:55 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjMzOiByZmNkaWZmIC0gLWh0bWwg ZHJhZnQtaWV0Zi1zcGZiaXMtZXhwZXJpbWVudC0wNy50eHQgZHJhZnQtaWV0Zi1zcGZiaXMtZXhw ZXJpbWVudC50eHQgLS0+IAo8IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQg SFRNTCA0LjAxIFRyYW5zaXRpb25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IEZyZWVCU0QgbWVkdXNh IDYuMi1SRUxFQVNFIEZyZWVCU0QgNi4yLVJFTEVBU0UgIzA6IEZyaSBKYW4gMTIgMDg6NDM6MzAg VVRDIDIwMDcgICAgIHJvb3RAcG9ydG5veS5jc2UuYnVmZmFsby5lZHU6L3Vzci9vYmovdXNyL3Ny Yy9zeXMvU01QICBhbWQ2NCAtLT4gCjwhLS0gVXNpbmcgYXdrOiAvdXNyL2xvY2FsL2Jpbi9nYXdr OiBHTlUgQXdrIDMuMS43IC0tPiAKPCEtLSBVc2luZyBkaWZmOiAvdXNyL2Jpbi9kaWZmOiBkaWZm IC0gR05VIGRpZmZ1dGlscyB2ZXJzaW9uIDIuNyAtLT4gCjwhLS0gVXNpbmcgd2RpZmY6IC91c3Iv bG9jYWwvYmluL3dkaWZmOiBHTlUgd2RpZmYgMC41IC0tPiAKPGh0bWw+IAo8aGVhZD4gCiAgPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9 aXNvLTg4NTktMSIgLz4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBj b250ZW50PSJ0ZXh0L2NzcyIgLz4gCiAgPHRpdGxlPkRpZmY6IGRyYWZ0LWlldGYtc3BmYmlzLWV4 cGVyaW1lbnQtMDcudHh0IC0gZHJhZnQtaWV0Zi1zcGZiaXMtZXhwZXJpbWVudC50eHQ8L3RpdGxl PiAKICA8c3R5bGUgdHlwZT0idGV4dC9jc3MiPiAKICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4 OyBtYXJnaW4tcmlnaHQ6IGF1dG87IH0gCiAgICB0ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3 aGl0ZS1zcGFjZTogcHJlOyBmb250LWZhbWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjog dG9wOyBmb250LXNpemU6IDAuODZlbTt9IAogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVt OyB9IAogICAgLnNtYWxsICB7IGZvbnQtc2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsg Zm9udC1mYW1pbHk6IFZlcmRhbmEsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0 ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQt Y29sb3I6ICNGRkY7IH0gCiAgICAuZGlmZiAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSAK ICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQkZCOyB9IAogICAgLnJibG9jayB7IGJh Y2tncm91bmQtY29sb3I6ICNGRjg7IH0gCiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjog IzhGRjsgfSAKICAgIC5kZWxldGUgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUNGOyB9IAogICAgLnZv aWQgICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkI7IH0gCiAgICAuY29udCAgIHsgYmFja2dyb3Vu ZC1jb2xvcjogI0VFRTsgfSAKICAgIC5saW5lYnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9 IAogICAgLmxpbmVubyB7IGNvbG9yOiByZWQ7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQt c2l6ZTogMC43ZW07IHRleHQtYWxpZ246IHJpZ2h0OyBwYWRkaW5nOiAwIDJweDsgfSAKICAgIC5l bGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjREREOyB9IAogICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xv cjogI0VFRTsgfSAKICAgIC5sYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9 IAogICAgLnJibG9jayAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5z ZXJ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEFEOyB9IAogICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0 cyB0aCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IHBhZGRpbmc6IDJweCAwOyB9IAogIDwvc3R5 bGU+IAo8L2hlYWQ+IAo8Ym9keSA+IAogIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMCI+IAogIDx0ciBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD4m bmJzcDtkcmFmdC1pZXRmLXNwZmJpcy1leHBlcmltZW50LTA3LnR4dCZuYnNwOzwvdGg+PHRoPiA8 L3RoPjx0aD4mbmJzcDtkcmFmdC1pZXRmLXNwZmJpcy1leHBlcmltZW50LnR4dCZuYnNwOzwvdGg+ PHRoPjwvdGg+PC90cj4gCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+U1BG QklTIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg TS4gS3VjaGVyYXd5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+U1BGQklTIFdvcmtp bmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gS3VjaGVy YXd5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIENsb3VkbWFyazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENs b3VkbWFyazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5JbnRl bmRlZCBzdGF0dXM6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXBy aWwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MjQsPC9zcGFuPiAyMDEyPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBcHJpbCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4zMCw8L3NwYW4+IDIw MTI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PY3RvYmVyIDI2LDwvc3Bhbj4gMjAxMjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5Ob3ZlbWJlciAxLDwvc3Bhbj4gMjAxMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgUmVzb2x1dGlvbiBvZiBUaGUgU1BGIGFuZCBTZW5kZXIgSUQgRXhwZXJpbWVu dHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICBSZXNvbHV0aW9u IG9mIFRoZSBTUEYgYW5kIFNlbmRlciBJRCBFeHBlcmltZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MDIiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYt c3BmYmlzLWV4cGVyaW1lbnQtMDxzcGFuIGNsYXNzPSJkZWxldGUiPjc8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1z cGZiaXMtZXhwZXJpbWVudC0wPHNwYW4gY2xhc3M9Imluc2VydCI+ODwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluIDIwMDYgdGhlIElF VEYgcHVibGlzaGVkIGEgc3VpdGUgb2YgcHJvdG9jb2wgZG9jdW1lbnRzIGNvbXByaXNpbmc8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbiAyMDA2IHRoZSBJRVRGIHB1Ymxpc2hl ZCBhIHN1aXRlIG9mIHByb3RvY29sIGRvY3VtZW50cyBjb21wcmlzaW5nPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNQRiBhbmQgU2VuZGVy IElELCB0d28gcHJvcG9zZWQgZW1haWwgYXV0aGVudGljYXRpb24gcHJvdG9jb2xzLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNQRiBhbmQgU2VuZGVyIElELCB0d28gcHJvcG9z ZWQgZW1haWwgYXV0aGVudGljYXRpb24gcHJvdG9jb2xzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCZWNhdXNlIG9mIHBvc3NpYmxlIGlu dGVyb3BlcmFiaWxpdHkgaXNzdWVzLCBwYXJ0aWN1bGFybHkgYnV0IG5vdDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJlY2F1c2Ugb2YgcG9zc2libGUgaW50ZXJvcGVyYWJpbGl0 eSBpc3N1ZXMsIHBhcnRpY3VsYXJseSBidXQgbm90PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9ubHkgdGhvc2UgY3JlYXRlZCBieSBzaW11 bHRhbmVvdXMgdXNlIG9mIHRoZSB0d28gcHJvdG9jb2xzIGJ5IGE8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBvbmx5IHRob3NlIGNyZWF0ZWQgYnkgc2ltdWx0YW5lb3VzIHVzZSBv ZiB0aGUgdHdvIHByb3RvY29scyBieSBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlY2VpdmVyLCB0aGUgSUVTRyB3YXMgdW5hYmxlIHRv IGRldGVybWluZSB0ZWNobmljYWwgY29uc2Vuc3VzIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHJlY2VpdmVyLCB0aGUgSUVTRyB3YXMgdW5hYmxlIHRvIGRldGVybWluZSB0 ZWNobmljYWwgY29uc2Vuc3VzIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWNpZGVkIGl0IHdhcyBiZXN0IHRvIHB1Ymxpc2ggYWxs IG9mIFJGQzQ0MDUsIFJGQzQ0MDYsIFJGQzQ0MDcgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgZGVjaWRlZCBpdCB3YXMgYmVzdCB0byBwdWJsaXNoIGFsbCBvZiBSRkM0NDA1 LCBSRkM0NDA2LCBSRkM0NDA3IGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBSRkM0NDA4IGFzIEV4cGVyaW1lbnRhbCBkb2N1bWVudHMu ICBUaGUgSUVTRyBpbnZpdGVkIHRoZSBjb21tdW5pdHkgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBSRkM0NDA4IGFzIEV4cGVyaW1lbnRhbCBkb2N1bWVudHMuICBUaGUgSUVT RyBpbnZpdGVkIHRoZSBjb21tdW5pdHkgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+ PHRoPjxhIG5hbWU9InBhcnQtbDIiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGVtPiBwYWdlIDEsIGxpbmUgNDI8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJw YXJ0LXIyIiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAx LCBsaW5lIDQyPC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFm dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRhc2sgRm9yY2UgKElFVEYp LiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3Ro ZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0 cy9jdXJyZW50Ly48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgbWF5IGJl IHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFu eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRpbWUuICBJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0 ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDAwMyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgd2lsbCBleHBpcmUgb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+T2N0b2JlciAyNjwvc3Bh bj4sIDIwMTIuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJu ZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gPHNwYW4gY2xhc3M9Imluc2VydCI+Tm92ZW1iZXIgMTwv c3Bhbj4sIDIwMTIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5Db3B5cmlnaHQgTm90aWNl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5k IHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgQ29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlk ZW50aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwg cmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0 byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0 byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zp c2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3Jn L2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykg aW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQ bGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNl IGRvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFy dC1sMyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMiwg bGluZSAyMTwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjMiIC8+PHNtYWxs PnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDIsIGxpbmUgMjE8L2VtPjwv dGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBC U0QgTGljZW5zZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXNjcmliZWQg aW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlRhYmxl IG9mIENvbnRlbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAxLiAgSW50cm9kdWN0 aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxLiAgSW50cm9kdWN0aW9uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMi4gIERlZmlu aXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMi4gIERlZmluaXRpb25zICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDMuICBF dmlkZW5jZSBvZiBEZXBsb3ltZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDMuICBFdmlkZW5jZSBv ZiBEZXBsb3ltZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg IDMuMS4gIEROUyBSZXNvdXJjZSBSZWNvcmQgVHlwZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDMuMS4gIERO UyBSZXNvdXJjZSBSZWNvcmQgVHlwZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAzLjIuICBJbXBsZW1lbnRhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAzLjIu ICBJbXBsZW1lbnRhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA1PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgMy4zLiAgVGhlIFNVQk1JVFRFUiBTTVRQIEV4dGVuc2lvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg My4zLiAgVGhlIFNVQk1JVFRFUiBTTVRQIEV4dGVuc2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDQiIC8+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICA0LiAgRXZpZGVuY2Ugb2YgRGlmZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIDQuICBFdmlkZW5jZSBvZiBEaWZmZXJlbmNlcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+Nzwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICA1LiAgQW5hbHlzaXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjY8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDUuICBBbmFseXNpcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+Nzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICA2LiAgQ29uY2x1c2lvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjc8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDYuICBDb25jbHVzaW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9 Imluc2VydCI+ODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICA3LiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+SUFOQTwvc3Bhbj4g Q29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNw YW4gY2xhc3M9ImRlbGV0ZSI+LiAuICA4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICA3LiAgPHNwYW4gY2xhc3M9Imluc2VydCI+U2VjdXJpdHk8L3NwYW4+IENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij45PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDguICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5TZWN1cml0 eTwvc3Bhbj4gQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIDguICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5JQU5BPC9zcGFuPiBDb25z aWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij4uIC4gIDk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgOS4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVs ZXRlIj44PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA5LiAgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA5LjEuICBOb3JtYXRpdmUgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFz cz0iZGVsZXRlIj44PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAg IDkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA5LjIuICBJbmZvcm1h dGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3Bh biBjbGFzcz0iZGVsZXRlIj44PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgIDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXBwZW5kaXgg QS4gIEJhY2tncm91bmQgb24gdGhlIFJSVFlQRSBJc3N1ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj45PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBBcHBlbmRpeCBBLiAgQmFja2dyb3VuZCBvbiB0aGUgUlJUWVBFIElzc3VlICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imluc2VydCI+MTA8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXBw ZW5kaXggQi4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUiPjEwPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBBcHBlbmRpeCBCLiAgQWNrbm93bGVkZ21lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imluc2VydCI+MTE8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgQXV0aG9yJ3MgQWRkcmVzcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUiPjExPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imluc2VydCI+MTI8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgSW4gQXByaWwgMjAwNiwgdGhlIElFVEYgcHVibGlzaGVkIHRoZSBb U1BGXSBhbmQgU2VuZGVyIElEIGVtYWlsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgSW4gQXByaWwgMjAwNiwgdGhlIElFVEYgcHVibGlzaGVkIHRoZSBbU1BGXSBhbmQgU2VuZGVy IElEIGVtYWlsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGF1dGhlbnRpY2F0aW9uIHByb3RvY29scywgdGhlIGxhdHRlciBjb25zaXN0aW5n IG9mIHRocmVlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGF1 dGhlbnRpY2F0aW9uIHByb3RvY29scywgdGhlIGxhdHRlciBjb25zaXN0aW5nIG9mIHRocmVlIGRv Y3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAoW1NVQk1JVFRFUl0sIFtTRU5ERVItSURdLCBhbmQgW1BSQV0pLiAgQm90aCBvZiB0 aGVzZSBwcm90b2NvbHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoW1NVQk1J VFRFUl0sIFtTRU5ERVItSURdLCBhbmQgW1BSQV0pLiAgQm90aCBvZiB0aGVzZSBwcm90b2NvbHM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZW5hYmxlIG9uZSB0byBwdWJsaXNoIHZpYSB0aGUgRG9tYWluIE5hbWUgU3lzdGVtIGEgcG9saWN5 IGRlY2xhcmluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGVuYWJsZSBvbmUg dG8gcHVibGlzaCB2aWEgdGhlIERvbWFpbiBOYW1lIFN5c3RlbSBhIHBvbGljeSBkZWNsYXJpbmc8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg d2hpY2ggbWFpbCBzZXJ2ZXJzIHdlcmUgYXV0aG9yaXplZCB0byBzZW5kIGVtYWlsIG9uIGJlaGFs ZiBvZiBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2hpY2ggbWFpbCBzZXJ2 ZXJzIHdlcmUgYXV0aG9yaXplZCB0byBzZW5kIGVtYWlsIG9uIGJlaGFsZiBvZiBhPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpZmlj IGRvbWFpbiBuYW1lLiAgVGhlIHR3byBwcm90b2NvbHMgbWFkZSB1c2Ugb2YgdGhpcyBzYW1lIHBv bGljeTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNwZWNpZmljIGRvbWFpbiBu YW1lLiAgVGhlIHR3byBwcm90b2NvbHMgbWFkZSB1c2Ugb2YgdGhpcyBzYW1lIHBvbGljeTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzdGF0 ZW1lbnQgYW5kIHNvbWUgc3BlY2lmaWMgKGJ1dCBkaWZmZXJlbnQpIGxvZ2ljIHRvIGV2YWx1YXRl IHdoZXRoZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzdGF0ZW1lbnQgYW5k IHNvbWUgc3BlY2lmaWMgKGJ1dCBkaWZmZXJlbnQpIGxvZ2ljIHRvIGV2YWx1YXRlIHdoZXRoZXI8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDQiIC8+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDQsIGxpbmUgMTM8L2Vt PjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI0IiAvPjxzbWFsbD5za2lwcGluZyB0 byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA0LCBsaW5lIDEzPC9lbT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBhcmUgdGhlIFRYVCBSUlRZUEUgKDE2KSBhbmQgdGhlIFNQRiBSUlRZ UEUgKDk5KS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhcmUgdGhlIFRYVCBS UlRZUEUgKDE2KSBhbmQgdGhlIFNQRiBSUlRZUEUgKDk5KS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjMuICBFdmlkZW5jZSBvZiBEZXBsb3ltZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+My4gIEV2aWRlbmNlIG9mIERlcGxveW1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFRoaXMgc2VjdGlvbiBwcmVzZW50cyB0aGUgY29sbGVjdGVkIHJlc2VhcmNoIGRv bmUgdG8gZGV0ZXJtaW5lIHdoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU aGlzIHNlY3Rpb24gcHJlc2VudHMgdGhlIGNvbGxlY3RlZCByZXNlYXJjaCBkb25lIHRvIGRldGVy bWluZSB3aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHBhcnRzIG9mIHRoZSB0d28gcHJvdG9jb2wgc3VpdGVzIGFyZSBpbiBnZW5lcmFs IHVzZSwgYXMgd2VsbCBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBhcnRz IG9mIHRoZSB0d28gcHJvdG9jb2wgc3VpdGVzIGFyZSBpbiBnZW5lcmFsIHVzZSwgYXMgd2VsbCBh czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICByZWxhdGVkIGlzc3VlcyBsaWtlIFtETlNdIHN1cHBvcnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgcmVsYXRlZCBpc3N1ZXMgbGlrZSBbRE5TXSBzdXBwb3J0LjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+My4xLiAgRE5TIFJlc291cmNlIFJlY29yZCBUeXBlczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuMS4gIEROUyBSZXNvdXJjZSBSZWNvcmQgVHlw ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNSIg Lz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFQ8c3BhbiBjbGFzcz0iZGVsZXRlIj53bzwvc3Bhbj4g bGFyZ2Utc2NhbGUgRE5TIHN1cnZleXMgd2VyZSBydW4gdGhhdCBsb29rZWQgZm9yIHRoZSB0d288 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVDxzcGFuIGNsYXNzPSJpbnNlcnQi PmhyZWU8L3NwYW4+IGxhcmdlLXNjYWxlIEROUyBzdXJ2ZXlzIHdlcmUgcnVuIHRoYXQgbG9va2Vk IGZvciB0aGUgdHdvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHN1cHBvcnRlZCBraW5kcyBvZiBSUlRZUEVzIHRoYXQgY2FuIGNvbnRhaW4g U1BGIHBvbGljeSBzdGF0ZW1lbnRzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHN1cHBvcnRlZCBraW5kcyBvZiBSUlRZUEVzIHRoYXQgY2FuIGNvbnRhaW4gU1BGIHBvbGljeSBz dGF0ZW1lbnRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDYiIC8+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5TcGVjaWZpY2FsbHksIHRoZXNlPC9zcGFuPiBzdXJ2ZXlz IDxzcGFuIGNsYXNzPSJkZWxldGUiPnB1bGxlZCBhIGxhcmdlIG51bWJlcjwvc3Bhbj4gb2YgZG9t YWluIG5hbWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPlRoZXNlPC9zcGFuPiBzdXJ2ZXlzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnNlbGVj dGVkIHN1YnN0YW50aWFsIHNldHM8L3NwYW4+IG9mIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRpc3Rp bmN0PC9zcGFuPiBkb21haW4gbmFtZXMgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZnJvbSBy ZWNlbnQgYWN0aXZpdHkgbG9nczwvc3Bhbj4gYW5kIHF1ZXJpZWQgdGhlaXIgbmFtZXNlcnZlcnMg Zm9yIGJvdGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcXVlcmllZCB0aGVp ciBuYW1lc2VydmVycyBmb3IgYm90aCBSUlRZUEVzIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFNQRjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IFJSVFlQRXMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgU1BGIGFuZC9vciBTZW5kZXIgSUQuICBJbiB0 aGUgdGFibGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFuZC9vciBTZW5k ZXIgSUQuICBJbiB0aGUgdGFibGVzIGJlbG93LCBvbmx5IHN5bnRhY3RpY2FsbHkgdmFsaWQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBi ZWxvdywgb25seSBzeW50YWN0aWNhbGx5IHZhbGlkIHJlcGxpZXMgYXJlIGNvdW50ZWQuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHJlcGxpZXMgYXJlIGNvdW50ZWQuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDciIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBETlMgU3VydmV5ICMxPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIEROUyBTdXJ2ZXkgIzE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gKENpc2NvKTwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLSstLS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tKzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIHwgRG9tYWlucyBxdWVy aWVkICB8IDEsMDAwLDAwMCB8ICAgLSAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgIHwgRG9tYWlucyBxdWVyaWVkICB8IDEsMDAwLDAwMCB8ICAgLSAgIHw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICB8IFRYVCBy ZXBsaWVzICAgICAgfCAgIDM5Nyw1MTEgfCAzOS44JSB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICB8IFRYVCByZXBsaWVzICAgICAgfCAgIDM5Nyw1MTEgfCAzOS44JSB8PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg fCBTUEYgcmVwbGllcyAgICAgIHwgICAgIDYsNjI3IHwgJmx0OzAuMSUgfDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgfCBTUEYgcmVwbGllcyAgICAgIHwgICAgIDYsNjI3IHwg Jmx0OzAuMSUgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgIHwgU1BGK1RYVCByZXBsaWVzICB8ICAgICA2LDYwMyB8ICZsdDswLjElIHw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIHwgU1BGK1RYVCByZXBsaWVzICB8 ICAgICA2LDYwMyB8ICZsdDswLjElIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICB8IHNwZjIuMC8qIHJlcGxpZXMgfCAgICAgNSwyOTEg fCAmbHQ7MC4xJSB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICB8IHNwZjIu MC8qIHJlcGxpZXMgfCAgICAgNSwyOTEgfCAmbHQ7MC4xJSB8PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLSstLS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tKzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGhlICJzcGYyLjAvKiIgcmVwbGllcyBhcmUgdGhvc2UgcmVwbGll cyB3aG9zZSBwYXlsb2FkIHN0YXJ0ZWQgd2l0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRoZSAic3BmMi4wLyoiIHJlcGxpZXMgYXJlIHRob3NlIHJlcGxpZXMgd2hvc2UgcGF5 bG9hZCBzdGFydGVkIHdpdGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHN0cmluZyAic3BmMi4wLyIsIHdoaWNoIGFyZSBzcGVjaWZp YyByZXF1ZXN0cyBmb3IgU2VuZGVyIElEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgdGhlIHN0cmluZyAic3BmMi4wLyIsIHdoaWNoIGFyZSBzcGVjaWZpYyByZXF1ZXN0cyBmb3Ig U2VuZGVyIElEPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IHByb2Nlc3NpbmcuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHByb2Nlc3Np bmcuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Eb21haW5zIHdlcmUgc2VsZWN0ZWQgYXMgdGhlIHRv cCBtaWxsaW9uIGRvbWFpbnMgYXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHJlcG9ydGVkIGJ5IEFsZXhhLCB3aGljaCBtb25p dG9ycyBicm93c2VyIGFjdGl2aXR5Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEROUyBT dXJ2ZXkgIzI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgRE5TIFN1cnZleSAj MjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAoVGhlIFRydXN0ZWQgRG9tYWluIFByb2plY3QpPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tKy0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0rPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDAxMCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgfCBEb21haW5zIHF1ZXJpZWQgIHwgICA8 c3BhbiBjbGFzcz0iZGVsZXRlIj4yNTksOTE4PC9zcGFuPiB8ICAgLSAgIHw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICB8IERvbWFpbnMgcXVlcmllZCAgfCAgIDxzcGFuIGNs YXNzPSJpbnNlcnQiPjI2NSwzNTE8L3NwYW4+IHwgICAtICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgfCBUWFQgcmVwbGllcyAg ICAgIHwgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xNDIsNjQwPC9zcGFuPiB8IDxzcGFuIGNsYXNz PSJkZWxldGUiPjU0LjklPC9zcGFuPiB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgfCBUWFQgcmVwbGllcyAgICAgIHwgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNDYsOTA3 PC9zcGFuPiB8IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjU1LjMlPC9zcGFuPiB8PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICB8IFNQRiBy ZXBsaWVzICAgICAgfCAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Miw3Mjc8L3NwYW4+IHwgIDEu MCUgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIHwgU1BGIHJlcGxpZXMg ICAgICB8ICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yLDc3Mzwvc3Bhbj4gfCAgMS4wJSB8PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ICB8IFNQRitUWFQgcmVwbGllcyAgfCAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Miw1NTQ8L3Nw YW4+IHwgJmx0OzAuMSUgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIHwg U1BGK1RYVCByZXBsaWVzICB8ICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yLDU5Njwvc3Bhbj4g fCAmbHQ7MC4xJSB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgICB8IHNwZjIuMC8qIHJlcGxpZXMgfCAgICAgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+Niw5NzI8L3NwYW4+IHwgIDIuNyUgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAgIHwgc3BmMi4wLyogcmVwbGllcyB8ICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij43 LDEyOTwvc3Bhbj4gfCAgMi43JSB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSst LS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDExIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoaXMgc3Vy dmV5IHNlbGVjdGVkIGl0cyBkb21haW5zIGZyb20gZGF0YSBhYm91dCBvYnNlcnZlZCBlbWFpbDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgdHJhZmZpYyBhbmQgcHJldmlvdXMgU1BGIGFuZCBTZW5kZXIgSUQgZXZhbHVhdGlvbnMs IGNvbGxlY3RlZCBmcm9tIDIzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICByZXBvcnRpbmcgaG9zdHMgYWNyb3NzIGEgaGFuZGZ1 bCBvZiB1bnJlbGF0ZWQgb3BlcmF0b3JzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEdXJpbmcgdGhpcyBzZWNvbmQgc3VydmV5LCBzb21l IGRvbWFpbnMgd2VyZSBvYnNlcnZlZCB0byBwcm92aWRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgRHVyaW5nIHRoaXMgc2Vjb25kIHN1cnZleSwgc29tZSBkb21haW5zIHdlcmUg b2JzZXJ2ZWQgdG8gcHJvdmlkZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbW1lZGlhdGUgYW5zd2VycyBmb3IgUlJUWVBFIDE2IHF1ZXJp ZXMsIGJ1dCB3b3VsZCB0aW1lIG91dCB3YWl0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgaW1tZWRpYXRlIGFuc3dlcnMgZm9yIFJSVFlQRSAxNiBxdWVyaWVzLCBidXQgd291 bGQgdGltZSBvdXQgd2FpdGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb3IgcmVwbGllcyB0byBSUlRZUEUgOTkgcXVlcmllcy4gIEZv ciBleGFtcGxlLCBpdCB3YXMgb2JzZXJ2ZWQgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGZvciByZXBsaWVzIHRvIFJSVFlQRSA5OSBxdWVyaWVzLiAgRm9yIGV4YW1wbGUs IGl0IHdhcyBvYnNlcnZlZCB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDQsMTc5IChvdmVyIDEuNiUpIGRpc3RpbmN0IGRvbWFpbnMg aW4gdGhlIHN1cnZleSByZXR1cm5lZCBhIHJlc3VsdCBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIDQsMTc5IChvdmVyIDEuNiUpIGRpc3RpbmN0IGRvbWFpbnMgaW4gdGhlIHN1 cnZleSByZXR1cm5lZCBhIHJlc3VsdCBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzb21lIGtpbmQgKGEgcmVjb3JkIG9yIGFuIGVycm9y KSBmb3IgdGhlIFRYVCBxdWVyeSBpbiB0aW1lIE4sIHdoaWxlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgc29tZSBraW5kIChhIHJlY29yZCBvciBhbiBlcnJvcikgZm9yIHRoZSBU WFQgcXVlcnkgaW4gdGltZSBOLCB3aGlsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgU1BGIHF1ZXJ5IHVsdGltYXRlbHkgZmFpbGVk IGFmdGVyIGF0IGxlYXN0IHRpbWUgNE4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgdGhlIFNQRiBxdWVyeSB1bHRpbWF0ZWx5IGZhaWxlZCBhZnRlciBhdCBsZWFzdCB0aW1lIDRO LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDEyIiAv PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgRE5TIFN1cnZleSAjMzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBETlMgU3VydmV5ICMzPHNwYW4gY2xhc3M9Imluc2VydCI+IChIb3Rt YWlsKTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tKzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIHwgRG9t YWlucyBxdWVyaWVkICB8ICAgMTAwLDAwMCB8ICAgLSAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgIHwgRG9tYWlucyBxdWVyaWVkICB8ICAgMTAwLDAwMCB8ICAgLSAgIHw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICB8IFRYVCByZXBsaWVzICAgICAgfCAgICA0NiwyMjEgfCA0Ni4yJSB8PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICB8IFRYVCByZXBsaWVzICAgICAgfCAgICA0NiwyMjEgfCA0 Ni4yJSB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgfCBTUEYgcmVwbGllcyAgICAgIHwgICAgICAgOTU0IHwgJmx0OzAuMSUgfDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgfCBTUEYgcmVwbGllcyAgICAgIHwgICAg ICAgOTU0IHwgJmx0OzAuMSUgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIHwgU1BGK1RYVCByZXBsaWVzICB8ICAgICAxLDM4MyB8ICAx LjQlIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIHwgU1BGK1RYVCByZXBs aWVzICB8ICAgICAxLDM4MyB8ICAxLjQlIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tKy0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICArLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTMiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBB IHN1cnZleSB3YXMgZG9uZSBvZiBxdWVyaWVzIGZvciBSUlRZUEUgMTYgYW5kIFJSVFlQRSA5OSBy ZWNvcmRzIGJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPkhvdG1haWwncyBkb21haW4gc2V0IHdhcyBzZWxlY3RlZCBmcm9tIGxpdmUgZW1h aWwgdHJhZmZpYyBhdCB0aGUgdGltZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBvYnNlcnZpbmcgbmFtZXNlcnZlciA8c3Bh biBjbGFzcz0iZGVsZXRlIj5sb2dzLjwvc3Bhbj4gIE9ubHkgYSBmZXcgcXVlcmllcyB3ZXJlIGV2 ZXIgcmVjZWl2ZWQgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIHRoZSBzYW1wbGUgd2FzIGV4dHJhY3RlZC48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgUlJUWVBF IDk5IHJlY29yZHMsIGFuZCB0aG9zZSBhbG1vc3QgZXhjbHVzaXZlbHkgY2FtZSBmcm9tIG9uZSBs YXJnZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ZW1haWwgc2VydmljZSBwcm92aWRlciB0aGF0IHF1ZXJpZWQgZm9yIGJvdGggUlJUWVBFcy4gIFRo ZSB2YXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEEgPHNwYW4gY2xhc3M9 Imluc2VydCI+c2VwYXJhdGU8L3NwYW4+IHN1cnZleSB3YXMgZG9uZSBvZiBxdWVyaWVzIGZvciBS UlRZUEUgMTYgYW5kIFJSVFlQRSA5OTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG1ham9yaXR5IG9mIG90aGVyIHF1ZXJ5aW5nIGFnZW50 cyBvbmx5IGV2ZXIgcmVxdWVzdGVkIFJSVFlQRSAxNi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgcmVjb3JkcyBieSBvYnNlcnZpbmcgbmFtZXNlcnZlciA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij50cmFmZmljIHJlY29yZHMuPC9zcGFuPiAgT25seSBhIGZldyBxdWVyaWVzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHdlcmUgZXZlciByZWNlaXZlZCBmb3IgUlJU WVBFIDk5IHJlY29yZHMsIGFuZCB0aG9zZSBhbG1vc3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgZXhjbHVzaXZlbHkgY2FtZSBmcm9tIG9uZSBsYXJnZSBlbWFpbCBzZXJ2aWNl IHByb3ZpZGVyIHRoYXQgcXVlcmllZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICBmb3IgYm90aCBSUlRZUEVzLiAgVGhlIHZhc3QgbWFqb3JpdHkgb2Ygb3RoZXIgcXVlcnlpbmcg YWdlbnRzIG9ubHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZXZlciByZXF1 ZXN0ZWQgUlJUWVBFIDE2LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+My4yLiAgSW1wbGVt ZW50YXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+My4yLiAgSW1wbGVtZW50 YXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJdCBpcyBsaWtlbHkgaW1wb3Nz aWJsZSB0byBkZXRlcm1pbmUgZnJvbSBhIHN1cnZleSB3aGljaCBNYWlsPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSXQgaXMgbGlrZWx5IGltcG9zc2libGUgdG8gZGV0ZXJtaW5l IGZyb20gYSBzdXJ2ZXkgd2hpY2ggTWFpbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUcmFuc2ZlciBBZ2VudHMgKE1UQXMpIGhhdmUgU1BG IGFuZC9vciBTZW5kZXIgSUQgY2hlY2tpbmcgZW5hYmxlZCBhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFRyYW5zZmVyIEFnZW50cyAoTVRBcykgaGF2ZSBTUEYgYW5kL29yIFNl bmRlciBJRCBjaGVja2luZyBlbmFibGVkIGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1lc3NhZ2UgaW5ncmVzcyBzaW5jZSBpdCBkb2Vz IG5vdCBhcHBlYXIsIGZvciBleGFtcGxlLCBpbiB0aGUgcmVwbHk8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBtZXNzYWdlIGluZ3Jlc3Mgc2luY2UgaXQgZG9lcyBub3QgYXBwZWFy LCBmb3IgZXhhbXBsZSwgaW4gdGhlIHJlcGx5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHRoZSBFSExPIGNvbW1hbmQgZnJvbSBleHRl bmRlZCBbU01UUF0uICBXZSB0aGVyZWZvcmUgcmVseSBvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHRvIHRoZSBFSExPIGNvbW1hbmQgZnJvbSBleHRlbmRlZCBbU01UUF0uICBX ZSB0aGVyZWZvcmUgcmVseSBvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBldmlkZW5jZSBmb3VuZCB2aWEgd2ViIHNlYXJjaGVzLCBhbmQg b2JzZXJ2ZWQgdGhlIGZvbGxvd2luZzo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBldmlkZW5jZSBmb3VuZCB2aWEgd2ViIHNlYXJjaGVzLCBhbmQgb2JzZXJ2ZWQgdGhlIGZvbGxv d2luZzo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIEEgd2ViIHNpdGUgW1NJRC1J TVBMXSBkZWRpY2F0ZWQgdG8gaGlnaGxpZ2h0aW5nIFNlbmRlciBJRDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIG8gIEEgd2ViIHNpdGUgW1NJRC1JTVBMXSBkZWRpY2F0ZWQgdG8g aGlnaGxpZ2h0aW5nIFNlbmRlciBJRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+ PGEgbmFtZT0icGFydC1sNSIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48 ZW0+IHBhZ2UgNSwgbGluZSA0MzwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQt cjUiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUsIGxp bmUgNDk8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGxpc3RlZC48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBsaXN0ZWQuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBvICBUaGUgW09QRU5TUEZdIHdlYiBzaXRlIG1haW50YWlucyBhIGxpc3Qg b2YgaW1wbGVtZW50YXRpb25zIG9mIFNQRi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBvICBUaGUgW09QRU5TUEZdIHdlYiBzaXRlIG1haW50YWlucyBhIGxpc3Qgb2YgaW1wbGVt ZW50YXRpb25zIG9mIFNQRi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgQXQgdGhlIHRpbWUgb2YgdGhpcyBkb2N1bWVudCdzIHdyaXRp bmcgaXQgbGlzdGVkIHNpeCBsaWJyYXJpZXMsIDIyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgQXQgdGhlIHRpbWUgb2YgdGhpcyBkb2N1bWVudCdzIHdyaXRpbmcgaXQgbGlz dGVkIHNpeCBsaWJyYXJpZXMsIDIyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE1UQXMgd2l0aCBidWlsdC1pbiBTUEYgaW1wbGVtZW50 YXRpb25zLCBhbmQgbnVtZXJvdXMgcGF0Y2hlcyBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICBNVEFzIHdpdGggYnVpbHQtaW4gU1BGIGltcGxlbWVudGF0aW9ucywgYW5k IG51bWVyb3VzIHBhdGNoZXMgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE1UQXMgYW5kIG1haWwgY2xpZW50cy4gIFRoZSBzZXQg aW5jbHVkZWQgYSBtaXggb2YgY29tbWVyY2lhbCBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICBNVEFzIGFuZCBtYWlsIGNsaWVudHMuICBUaGUgc2V0IGluY2x1ZGVkIGEg bWl4IG9mIGNvbW1lcmNpYWwgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGZyZWUgb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb25z LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGZyZWUgb3BlbiBzb3VyY2Ug aW1wbGVtZW50YXRpb25zLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+My4zLiAgVGhlIFNV Qk1JVFRFUiBTTVRQIEV4dGVuc2lvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMu My4gIFRoZSBTVUJNSVRURVIgU01UUCBFeHRlbnNpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGUg UFJBIGlzIHRoZSBvdXRwdXQgb2YgYSBoZXVyaXN0aWMgdGhhdCBzZWVrcyB0byBzY2FuIGEgbWVz c2FnZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgaGVhZGVyIGFuZCBleHRyYWN0IGZyb20gaXQgdGhlIGVtYWlsIGFkZHJlc3Mg bW9zdCBsaWtlbHkgdG8gYmUgdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBvbmUgcmVzcG9uc2libGUgZm9yIGluamVjdGlv biBvZiB0aGF0IG1lc3NhZ2UgaW50byB0aGUgbWFpbCBzdHJlYW0uPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRoZSBT VUJNSVRURVIgZXh0ZW5zaW9uIHRvIFNNVFAgaXMgYSBtZWNoYW5pc20gdG8gcHJvdmlkZSBhbiBl YXJseTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgaGludCAoaS5lLiwgYXMgcGFydCBvZiB0aGUgTUFJTCBjb21tYW5kIGluIGFu IFNNVFAgc2Vzc2lvbikgdG8gdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICByZWNlaXZpbmcgTVRBIG9mIHdoYXQgdGhlIFBS QSB3b3VsZCBiZSBvbiBmdWxsIHJlY2VpcHQgb2YgdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBtZXNzYWdlLjwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbiBhIHJl dmlldyBvZiBudW1lcm91cyBNVEFzIGluIGN1cnJlbnQgb3IgcmVjZW50IHVzZSwgdHdvPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gYSByZXZpZXcgb2YgbnVtZXJvdXMgTVRB cyBpbiBjdXJyZW50IG9yIHJlY2VudCB1c2UsIHR3bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoU2FudHJvbmljcyBXaW5TZXJ2ZXIgYW5k IE1jQWZlZSBNeExvZ2ljKSB3ZXJlIGZvdW5kIHRvIGNvbnRhaW48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAoU2FudHJvbmljcyBXaW5TZXJ2ZXIgYW5kIE1jQWZlZSBNeExvZ2lj KSB3ZXJlIGZvdW5kIHRvIGNvbnRhaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBTTVRQIFNVQk1J VFRFUiBleHRlbnNpb24gYXMgcGFydCBvZiB0aGUgTVRBPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBTTVRQIFNVQk1JVFRFUiBleHRlbnNp b24gYXMgcGFydCBvZiB0aGUgTVRBPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlcnZpY2UsIHdoaWNoIGNvdWxkIGFjdCBhcyBhbiBlbmFi bGVyIHRvIFNlbmRlciBJRC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZXJ2 aWNlLCB3aGljaCBjb3VsZCBhY3QgYXMgYW4gZW5hYmxlciB0byBTZW5kZXIgSUQuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBbiB1bmtub3duIG51bWJlciBvZiBTTVRQIGNsaWVudHMg aW1wbGVtZW50IFNVQk1JVFRFUi4gIEFsdGhvdWdoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgQW4gdW5rbm93biBudW1iZXIgb2YgU01UUCBjbGllbnRzIGltcGxlbWVudCBTVUJN SVRURVIuICBBbHRob3VnaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICB0aGVyZSBpcyBzdWJzdGFudGlhbCBhY3Rpdml0eSBzaG93aW5nIGl0 cyB1c2UgaW4gTVRBIGxvZ3MsIGl0IGlzIG5vdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHRoZXJlIGlzIHN1YnN0YW50aWFsIGFjdGl2aXR5IHNob3dpbmcgaXRzIHVzZSBpbiBN VEEgbG9ncywgaXQgaXMgbm90PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHBvc3NpYmxlIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZXkgYXJl IG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHBvc3NpYmxlIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZXkgYXJlIG11bHRpcGxl IGluc3RhbmNlcyBvZiB0aGUgc2FtZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjbGllbnQsIG9yIHNlcGFyYXRlIGNsaWVudCBpbXBsZW1l bnRhdGlvbnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2xpZW50LCBvciBz ZXBhcmF0ZSBjbGllbnQgaW1wbGVtZW50YXRpb25zLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE1IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQW4g YWN0aXZlIHN1cnZleSB3YXMgZG9uZSBvZiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5hIGFwcHJveGlt YXRlbHkgMTYwLDAwMDwvc3Bhbj4gcnVubmluZyBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgQW4gYWN0aXZlIHN1cnZleSB3YXMgZG9uZSBvZiBydW5uaW5nIGFuZCBwdWJs aWNseSByZWFjaGFibGUgTVRBcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBwdWJsaWNseSByZWFjaGFibGUgTVRBcy4gIDxzcGFuIGNs YXNzPSJkZWxldGUiPkZld2VyIHRoYW4gNC41JSBvZiB0aGVzZSBhZHZlcnRpc2VkIHRoZTwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+VGhlPC9zcGFuPiBNVEFzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnNlbGVjdGVkIHdlcmU8L3Nw YW4+IGZvdW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmJ5IHF1ZXJ5aW5nIGZvciBNWDwvc3Bhbj4g YW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkEgcmVjb3JkcyBvZjwvc3Bhbj4gYTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgIFNVQk1JVFRFUiBleHRlbnNpb24uICBCYXNlZCBvbiB0aGUgU01UUCBiYW5u ZXIgcHJlc2VudGVkIHVwb248L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnN1YnNldCBvZiBhbGwgZG9tYWlucyBvYnNlcnZlZCBi eSBUaGUgVHJ1c3RlZCBEb21haW4gUHJvamVjdCdzIGRhdGE8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgY29ubmVjdGlvbiwgdGhlIGVudGlyZSBzZXQgb2YgU1VCTUlUVEVSLWVuYWJsZWQ8 L3NwYW4+IE1UQXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Y29uc2lzdGVkIG9mIHRoZTwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg Y29sbGVjdGlvbiBzeXN0ZW0gaW4gdGhlIHByZWNlZGluZyAyMCBtb250aHMuICBUaGUgcmVzdWx0 cyB3ZXJlIGFzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHR3bzwvc3Bhbj4gZm91bmQg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHVyaW5nIHRoZSByZXZpZXcgKGFib3ZlKTwvc3Bhbj4gYW5k IGEgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGhpcmQgd2hvc2UgaWRlbnRpdHkgY291bGQ8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IGZvbGxvd3M6PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIG5vdCBiZSBwb3NpdGl2ZWx5 IGRldGVybWluZWQuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNiIgLz48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPk92ZXIgOTclPC9zcGFuPiBv ZiB0aGUgcmVzcG9uZGluZyBNVEFzIGFkdmVydGlzaW5nIHRoZSBTVUJNSVRURVIgU01UUDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TVUJN SVRURVIgU3VydmV5IChUaGUgVHJ1c3RlZCBEb21haW4gUHJvamVjdCk8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+ZXh0ZW5zaW9uPC9zcGFuPiB3ZXJlIGRpZmZlcmVudCBpbnN0YW5jZXMg b2Ygb25lIE1UQS4gIFRoZSBzZXJ2aWNlIG9wZXJhdGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdGhhdCBNVEEgcmVwb3J0 ZWQgdGhhdCBhYm91dCAxMSUgb2YgYWxsIG9ic2VydmVkIFNNVFAgc2Vzc2lvbnM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tKzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBpbnZvbHZlZCBTTVRQ IGNsaWVudHMgd2hpY2ggbWFrZSB1c2Ugb2YgdGhlIFNVQk1JVFRFUiBleHRlbnNpb24uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgfCBN VEFzIHNlbGVjdGVkICAgICB8ICAgMzM5LDc1MCB8ICAgLSAgIHw8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgfCBNVEFzIHJl c3BvbmRpbmcgICB8ICAgMjYzLDQ4MCB8IDc3LjYlIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgfCBTVUJNSVRURVIgZW5h YmxlZCB8ICAgIDEyLDE2NSB8ICA0LjYlIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgfCBNWExvZ2ljIGJhbm5lciAgICB8 ICAgIDExLDgwNiB8ICA0LjUlIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0rLS0tLS0tLSs8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgTm90ZTogVGhlIGJvdHRvbSB0d28gcm93cyBpbmRp Y2F0ZSB0aGUgcGVyY2VudGFnZTwvc3Bhbj4gb2YgPHNwYW4gY2xhc3M9Imluc2VydCI+cmVzcG9u ZGluZyBNVEFzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICB3aXRoIHRoZSBzdGF0ZWQgcHJvcGVydHksIG5vdCB0aGUgcGVyY2Vu dGFnZSBvZiBzZWxlY3RlZCBNVEFzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBCYXNlZCBvbiB0aGUgU01UUCBiYW5u ZXIgcHJlc2VudGVkIHVwb24gY29ubmVjdGlvbiw8L3NwYW4+IHRoZSA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5lbnRpcmUgc2V0IG9mPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBTVUJNSVRURVItZW5hYmxlZCBNVEFzIGNvbnNpc3Rl ZCBvZiB0aGUgdHdvIGZvdW5kIGR1cmluZyB0aGUgcmV2aWV3PC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAoYWJvdmUpIGFuZCBh IHRoaXJkIHdob3NlIGlkZW50aXR5IGNvdWxkIG5vdCBiZSBwb3NpdGl2ZWx5PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBkZXRl cm1pbmVkLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICBPZiB0aG9zZSBmZXc8L3NwYW4+IHJlc3BvbmRpbmcgTVRBcyBh ZHZlcnRpc2luZyB0aGUgU1VCTUlUVEVSIFNNVFA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ZXh0ZW5zaW9uLCA5NyU8L3NwYW4+IHdlcmUg ZGlmZmVyZW50IGluc3RhbmNlcyBvZiBvbmUgTVRBLiAgVGhlIHNlcnZpY2U8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgb3BlcmF0aW5nIHRoYXQgTVRBIDxzcGFuIGNsYXNzPSJp bnNlcnQiPihNWExvZ2ljLCBhIGRpdmlzaW9uIG9mIE1jQWZlZSk8L3NwYW4+IHJlcG9ydGVkIHRo YXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYWJvdXQgMTElIG9mIGFsbCBv YnNlcnZlZCBTTVRQIHNlc3Npb25zIGludm9sdmVkIFNNVFAgY2xpZW50cyB3aGljaDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBtYWtlIHVzZSBvZiB0aGUgU1VCTUlUVEVSIGV4 dGVuc2lvbi4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk5vdGUgdGhhdCB0aGlzIHJlcHJlc2VudHMg YWJvdXQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIDExJSBvZiA0LjUlIG9mIHRoZSByZXNwb25kaW5nIE1UQXMgaW4gdGhlIHN1 cnZleS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LiAgRXZpZGVuY2Ugb2Yg RGlmZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LiAgRXZpZGVuY2Ug b2YgRGlmZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1l PSJkaWZmMDAxNyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNlcGFyYXRlIHN1cnZleXMgY29t cGFyZWQgdGhlIGNhc2VzIHdoZXJlIHRoZSBQUkEgKHVzZWQgYnkgU2VuZGVyIElEKTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBTZXBhcmF0ZSBzdXJ2ZXlzIDxzcGFuIGNsYXNz PSJpbnNlcnQiPmZyb20gSG90bWFpbCBhbmQgVGhlIFRydXN0ZWQgRG9tYWluIFByb2plY3Q8L3Nw YW4+IGNvbXBhcmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgYW5kIHRoZSBSRkM1MzIxLk1haWxGcm9tIGFkZHJlc3MgKHVzZWQgYnkg U1BGKSBkaWZmZXJlZC4gIFRoZSByZXN1bHRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIHRoZSBjYXNlcyB3aGVyZSB0aGUgUFJBICh1c2VkIGJ5IFNlbmRlciBJRCkgYW5kIHRo ZSBSRkM1MzIxLk1haWxGcm9tPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgb2YgdGhlc2UgdGVzdHMgc2hvd2VkIHRoYXQgYXQgbGVhc3Qg NTAlIG9mIHRoZSB0aW1lIHRoZSB0d28gYWRkcmVzc2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIGFkZHJlc3MgKHVzZWQgYnkgU1BGKSBkaWZmZXJlZC4gIFRoZSByZXN1bHRz IG9mIHRoZXNlIHRlc3RzIHNob3dlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHdlcmUgdGhlIHNhbWUsIGJ1dCBiZXlvbmQgdGhhdCB0 aGUgcGVyY2VudGFnZSB2YXJpZWQgc3Vic3RhbnRpYWxseTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICB0aGF0IGF0IGxlYXN0IDUwJSBvZiB0aGUgdGltZSB0aGUgdHdvIGFkZHJl c3NlcyB3ZXJlIHRoZSBzYW1lLCBidXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBmcm9tIG9uZSBzYW1wbGluZyBsb2NhdGlvbiB0byB0 aGUgbmV4dCBkdWUgdG8gdGhlIG5hdHVyZSBvZiB0aGUgbWFpbDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBiZXlvbmQgdGhhdCB0aGUgcGVyY2VudGFnZSB2YXJpZWQgc3Vic3Rh bnRpYWxseSBmcm9tIG9uZSBzYW1wbGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHN0cmVhbXMgdGhleSBlYWNoIHJlY2VpdmUuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGxvY2F0aW9uIHRvIHRoZSBuZXh0IGR1 ZSB0byB0aGUgbmF0dXJlIG9mIHRoZSBtYWlsIHN0cmVhbXMgdGhleSBlYWNoPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHJlY2VpdmUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTgiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8 c3BhbiBjbGFzcz0iZGVsZXRlIj5EZXNwaXRlIHRoaXMsIG9uZSB3b3JraW5nIGdyb3VwIGNvbnRy aWJ1dG9yPC9zcGFuPiBhbmFseXplZCBhcHByb3hpbWF0ZWx5PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkZ1cnRoZXIsIFRoZSBUcnVzdGVk IERvbWFpbiBQcm9qZWN0PC9zcGFuPiBhbmFseXplZCBhcHByb3hpbWF0ZWx5IDE1MCwwMDA8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAx NTAsMDAwIG1lc3NhZ2VzIGFuZCBmb3VuZCB0aGF0IGluIG1vcmUgdGhhbiA5NSUgb2YgdGhvc2Ug Y2FzZXMsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG1lc3NhZ2VzIGFuZCBm b3VuZCB0aGF0IGluIG1vcmUgdGhhbiA5NSUgb2YgdGhvc2UgY2FzZXMsIFNlbmRlciBJRDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNl bmRlciBJRCBhbmQgU1BGIHJlYWNoIHRoZSBzYW1lIGNvbmNsdXNpb24gYWJvdXQgYSBtZXNzYWdl LCBtZWFuaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFuZCBTUEYgcmVh Y2ggdGhlIHNhbWUgY29uY2x1c2lvbiBhYm91dCBhIG1lc3NhZ2UsIG1lYW5pbmcgZWl0aGVyPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ZWl0aGVyIGJvdGggcHJvdG9jb2xzIHJldHVybiBhICJwYXNzIiByZXN1bHQgb3IgYm90aCByZXR1 cm4gYSAiZmFpbCI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYm90aCBwcm90 b2NvbHMgcmV0dXJuIGEgInBhc3MiIHJlc3VsdCBvciBib3RoIHJldHVybiBhICJmYWlsIiByZXN1 bHQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgcmVzdWx0LiAgVGhlIGRhdGEgc2V0IHlpZWxkaW5nIHRoaXMgcmVzcG9uc2UgY291bGQg bm90IGZ1cnRoZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xh c3M9Imluc2VydCI+Tm90ZSB0aGF0IHRoaXMgZG9lcyBub3QgaW5jbHVkZSBhbiBldmFsdWF0aW9u IG9mIHdoZXRoZXIgImZhaWwiIG1lYW50PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzcGFtIG9yIG90aGVyIGFidXNpdmUgbWFp bCB3YXMgdGh1cyBkZXRlY3RlZCBvciB0aGF0ICJwYXNzIiBtYWlsIGlzPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBnb29kIG1h aWw7IGl0IGlzIG1lcmVseSBhIG1lYXN1cmUgb2YgaG93IG9mdGVuIHRoZSB0d28gcHJvdG9jb2xz PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICBjb25jdXJyZWQuPC9zcGFuPiAgVGhlIGRhdGEgc2V0IHlpZWxkaW5nIHRoaXMgcmVz cG9uc2UgY291bGQgbm90IGZ1cnRoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2hhcmFjdGVyaXplIHRoZSBjYXNlcyBpbiB3aGljaCB0 aGUgYW5zd2VycyBkaWZmZXJlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBj aGFyYWN0ZXJpemUgdGhlIGNhc2VzIGluIHdoaWNoIHRoZSBhbnN3ZXJzIGRpZmZlcmVkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE5IiAvPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgQSBzZWNvbmQgYW5hbHlzaXMgb2YgdGhlIHNhbWUgbmF0dXJlIGJ5 IDxzcGFuIGNsYXNzPSJkZWxldGUiPmEgbXVjaCBsYXJnZXIgbWFpbGJveDwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQSBzZWNvbmQgYW5hbHlzaXMgb2YgdGhlIHNh bWUgbmF0dXJlIGJ5IDxzcGFuIGNsYXNzPSJpbnNlcnQiPkhvdG1haWw8L3NwYW4+IGZvdW5kIHRo YXQgdGhlIHR3bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHByb3ZpZGVyPC9zcGFuPiBmb3VuZCB0 aGF0IHRoZSB0d28gcHJvdG9jb2xzIHlpZWxkZWQgdGhlIHNhbWUgcmVzdWx0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHByb3RvY29scyB5aWVsZGVkIHRoZSBzYW1lIHJlc3Vs dCBhcHByb3hpbWF0ZWx5IDgwJSBvZiB0aGUgdGltZSB3aGVuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYXBwcm94aW1hdGVseSA4MCUg b2YgdGhlIHRpbWUgd2hlbiBldmFsdWF0ZWQgYWNyb3NzIGJpbGxpb25zIG9mPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGV2YWx1YXRlZCBhY3Jvc3MgYmlsbGlvbnMgb2YgbWVz c2FnZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgbWVzc2FnZXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xh c3M9Imluc2VydCI+QW5lY2RvdGFsbHksIHRoZSBkaWZmZXJlbmNlcyBpbiBjb25jbHVzaW9ucyBo YXZlIG5vdCBiZWVuIG5vdGVkIGFzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBjYXVzaW5nIHNpZ25pZmljYW50IG9wZXJhdGlv bmFsIHByb2JsZW1zIGJ5IHRoZSBlbWFpbC1yZWNlaXZpbmc8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGNvbW11bml0eS48L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LiAgQW5hbHlzaXM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij41LiAgQW5hbHlzaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIEdpdmVuIHRoZSBzaXggeWVhcnMgdGhhdCBoYXZlIHBhc3NlZCBzaW5jZSB0aGUgcHVi bGljYXRpb24gb2YgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgR2l2ZW4g dGhlIHNpeCB5ZWFycyB0aGF0IGhhdmUgcGFzc2VkIHNpbmNlIHRoZSBwdWJsaWNhdGlvbiBvZiB0 aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgRXhwZXJpbWVudGFsIFJGQ3MsIGFuZCB0aGUgZXZpZGVuY2UgcmVwb3J0ZWQgaW4gdGhlIGVh cmxpZXIgc2VjdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFeHBlcmlt ZW50YWwgUkZDcywgYW5kIHRoZSBldmlkZW5jZSByZXBvcnRlZCBpbiB0aGUgZWFybGllciBzZWN0 aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBvZiB0aGlzIGRvY3VtZW50LCB0aGUgZm9sbG93aW5nIGFuYWx5c2lzIGFwcGVhcnMgdG8g YmUgc3VwcG9ydGVkOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIHRoaXMg ZG9jdW1lbnQsIHRoZSBmb2xsb3dpbmcgYW5hbHlzaXMgYXBwZWFycyB0byBiZSBzdXBwb3J0ZWQ6 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAxLiAgVGhlcmUgaGFzIG5vdCBiZWVuIHN1 YnN0YW50aWFsIGFkb3B0aW9uIG9mIHRoZSBSUlRZUEUgOTkgKFNQRik8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAxLiAgVGhlcmUgaGFzIG5vdCBiZWVuIHN1YnN0YW50aWFsIGFk b3B0aW9uIG9mIHRoZSBSUlRZUEUgOTkgKFNQRik8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIEROUyByZXNvdXJjZSByZWNvcmQuICBJ biBhbGwgbGFyZ2Utc2NhbGUgc3VydmV5cyBwZXJmb3JtZWQgZm9yPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgIEROUyByZXNvdXJjZSByZWNvcmQuICBJbiBhbGwgbGFyZ2Ut c2NhbGUgc3VydmV5cyBwZXJmb3JtZWQgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICB0aGlzIHdvcmssIGxlc3MgdGhhbiAyJSBv ZiByZXNwb25kaW5nIGRvbWFpbnMgcHVibGlzaGVkIFJSVFlQRSA5OTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICB0aGlzIHdvcmssIGxlc3MgdGhhbiAyJSBvZiByZXNwb25k aW5nIGRvbWFpbnMgcHVibGlzaGVkIFJSVFlQRSA5OTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+ PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNiIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0 PC9zbWFsbD48ZW0+IHBhZ2UgNywgbGluZSAyMTwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5h bWU9InBhcnQtcjYiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBw YWdlIDgsIGxpbmUgMTU8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDQuICBBIHJl dmlldyBvZiBrbm93biBpbXBsZW1lbnRhdGlvbnMgc2hvd3Mgc2lnbmlmaWNhbnQgc3VwcG9ydCBm b3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA0LiAgQSByZXZpZXcgb2Yga25v d24gaW1wbGVtZW50YXRpb25zIHNob3dzIHNpZ25pZmljYW50IHN1cHBvcnQgZm9yPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICBib3Ro IHByb3RvY29scywgdGhvdWdoIHRoZXJlIHdlcmUgbW9yZSBpbXBsZW1lbnRhdGlvbnMgaW4gc3Vw cG9ydDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBib3RoIHByb3RvY29s cywgdGhvdWdoIHRoZXJlIHdlcmUgbW9yZSBpbXBsZW1lbnRhdGlvbnMgaW4gc3VwcG9ydDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg b2YgU1BGIHRoYW4gb2YgU2VuZGVyIElELiAgRnVydGhlciwgdGhlIFNQRiBpbXBsZW1lbnRhdGlv bnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgb2YgU1BGIHRoYW4gb2Yg U2VuZGVyIElELiAgRnVydGhlciwgdGhlIFNQRiBpbXBsZW1lbnRhdGlvbnM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIHNob3dlZCBi ZXR0ZXIgdXBrZWVwIGFuZCBjdXJyZW50IGludGVyZXN0IHRoYW4gdGhlIFNlbmRlciBJRDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBzaG93ZWQgYmV0dGVyIHVwa2VlcCBh bmQgY3VycmVudCBpbnRlcmVzdCB0aGFuIHRoZSBTZW5kZXIgSUQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIGltcGxlbWVuYXRpb25z LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBpbXBsZW1lbmF0aW9ucy48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDUuICBBIHN1cnZleSBvZiBydW5uaW5nIE1U QXMgc2hvd3MgZmV3ZXIgdGhhbiA1JSBvZiB0aGVtIGFkdmVydGlzZWQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICA1LiAgQSBzdXJ2ZXkgb2YgcnVubmluZyBNVEFzIHNob3dzIGZl d2VyIHRoYW4gNSUgb2YgdGhlbSBhZHZlcnRpc2VkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICB0aGUgU1VCTUlUVEVSIGV4dGVuc2lv biwgd2hpY2ggaXMgYSBTZW5kZXIgSUQgZW5hYmxlci4gIE9ubHk8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgdGhlIFNVQk1JVFRFUiBleHRlbnNpb24sIHdoaWNoIGlzIGEg U2VuZGVyIElEIGVuYWJsZXIuICBPbmx5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICB0aHJlZSBpbXBsZW1lbnRhdGlvbnMgb2YgaXQg d2VyZSBmb3VuZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgdGhyZWUg aW1wbGVtZW50YXRpb25zIG9mIGl0IHdlcmUgZm91bmQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjAiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA2 LiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+QWx0aG91Z2ggdGhleSBtYXkgYmUgbWFyZ2luYWwsIHRo ZXJlPC9zcGFuPiByZW1haW4gb2JzdGFjbGVzIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIDYuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5BbXBsZSBvcHRpb25zIGFyZSBhdmFp bGFibGUgaW4gdGVybXMgb2Ygc29mdHdhcmUgdG8gaW1wbGVtZW50PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICBkZXBs b3ltZW50IG9mIHByb3RvY29scyB0aGF0IHVzZSBETlMgUlJUWVBFcyBvdGhlciB0aGFuIHRoZSBt b3N0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgICAgICBlaXRoZXIgb2YgdGhlIHR3byBwcm90b2NvbHMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICBjb21tb24g b25lcywgaW5jbHVkaW5nIGZpcmV3YWxscyBhbmQgRE5TIHNlcnZlcnMgdGhhdCBibG9jayBvcjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgIGRpc2NhcmQgcmVxdWVzdHMgZm9yIHVua25vd24gUlJUWVBFcy4gIEZ1cnRoZXIs IGZldyBpZiBhbnkgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+d2ViLTwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgNy4gIFRoZXJlPC9z cGFuPiByZW1haW4gb2JzdGFjbGVzIHRvIGRlcGxveW1lbnQgb2YgcHJvdG9jb2xzIHRoYXQgdXNl IEROUzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICBiYXNlZDwvc3Bhbj4gRE5TIGNvbmZpZ3Vy YXRpb24gdG9vbHMgb2ZmZXIgc3VwcG9ydCBmb3IgUlJUWVBFIDk5PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgICBSUlRZUEVzIG90aGVyIHRoYW4gdGhlIG1vc3QgY29tbW9u IG9uZXMsIGluY2x1ZGluZyBmaXJld2FsbHMgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIHJlY29yZHMuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICBETlMgc2VydmVycyB0aGF0IGJsb2NrIG9yIGRp c2NhcmQgcmVxdWVzdHMgZm9yIHVua25vd24gUlJUWVBFcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgICAgIEZ1cnRoZXIsIGZldyBpZiBhbnkgPHNwYW4gY2xhc3M9Imluc2Vy dCI+d2ViLWJhc2VkPC9zcGFuPiBETlMgY29uZmlndXJhdGlvbiB0b29scyBvZmZlcjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgc3VwcG9ydCBmb3IgUlJUWVBFIDk5IHJl Y29yZHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LiAgQ29uY2x1c2lvbnM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij42LiAgQ29uY2x1c2lvbnM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIEluIGxpZ2h0IG9mIHRoZSBhbmFseXNpcyBpbiB0aGUgcHJldmlvdXMg c2VjdGlvbiwgdGhlIGZvbGxvd2luZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IEluIGxpZ2h0IG9mIHRoZSBhbmFseXNpcyBpbiB0aGUgcHJldmlvdXMgc2VjdGlvbiwgdGhlIGZv bGxvd2luZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBjb25jbHVzaW9ucyBhcmUgc3VwcG9ydGVkOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGNvbmNsdXNpb25zIGFyZSBzdXBwb3J0ZWQ6PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAxLiAgVGhlIGV4cGVyaW1lbnRzIGNvbXByaXNpbmcgdGhlIHNlcmllcyBv ZiBSRkNzIGRlZmluaW5nIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEu ICBUaGUgZXhwZXJpbWVudHMgY29tcHJpc2luZyB0aGUgc2VyaWVzIG9mIFJGQ3MgZGVmaW5pbmcg dGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICBTVUJNSVRURVIgU01UUCBleHRlbnNpb24gKFJGQzQ0MDUpLCB0aGUgU2VuZGVyIElE IG1lY2hhbmlzbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBTVUJNSVRU RVIgU01UUCBleHRlbnNpb24gKFJGQzQ0MDUpLCB0aGUgU2VuZGVyIElEIG1lY2hhbmlzbTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg KFJGQzQ0MDYpLCB0aGUgUHVycG9ydGVkIFJlc3BvbnNpYmxlIGFkZHJlc3MgYWxnb3JpdGhtIChS RkM0NDA3KSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgKFJGQzQ0MDYp LCB0aGUgUHVycG9ydGVkIFJlc3BvbnNpYmxlIGFkZHJlc3MgYWxnb3JpdGhtIChSRkM0NDA3KSw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgIGFuZCBTUEYgKFJGQzQ0MDgpLCBzaG91bGQgYmUgY29uc2lkZXJlZCBjb25jbHVkZWQuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIGFuZCBTUEYgKFJGQzQ0MDgpLCBz aG91bGQgYmUgY29uc2lkZXJlZCBjb25jbHVkZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAyLiAgVGhlIGFic2VuY2Ugb2Ygc2lnbmlmaWNhbnQgYWRvcHRpb24gb2YgdGhlIFJSVFlQ RSA5OSBETlMgUmVzb3VyY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAyLiAg VGhlIGFic2VuY2Ugb2Ygc2lnbmlmaWNhbnQgYWRvcHRpb24gb2YgdGhlIFJSVFlQRSA5OSBETlMg UmVzb3VyY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgIFJlY29yZCBzdWdnZXN0cyB0aGF0IGl0IGhhcyBub3QgYXR0cmFjdGVkIGVu b3VnaCBzdXBwb3J0IHRvIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg IFJlY29yZCBzdWdnZXN0cyB0aGF0IGl0IGhhcyBub3QgYXR0cmFjdGVkIGVub3VnaCBzdXBwb3J0 IHRvIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgICB1c2VmdWwuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg IHVzZWZ1bC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDAyMSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDMuICBUaGUgYWJzZW5jZSBvZiBzaWduaWZp Y2FudCBhZG9wdGlvbiBvZiB0aGUgW1NVQk1JVFRFUl0gZXh0ZW5zaW9uLDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAzLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+VW5hdmFpbGFi aWxpdHkgb2Ygc29mdHdhcmUgaW1wbGVtZW50aW5nIHRoZSBwcm90b2NvbHMgd2FzIG5vdCBhPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICAgICAgZ2F0aW5nIGZhY3RvciBpbiB0ZXJtcyBvZiB0aGUgc2VsZWN0aW9uIG9mIHdoaWNo IHRvIHVzZS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgNC48L3NwYW4+ICBUaGUgYWJzZW5jZSBvZiBzaWduaWZpY2Fu dCBhZG9wdGlvbiBvZiB0aGUgW1NVQk1JVFRFUl0gZXh0ZW5zaW9uLDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgW1NFTkRFUi1JRF0s IGFuZCBbUFJBXSwgaW5kaWNhdGVzIHRoYXQgdGhlcmUgaXMgbm90IGEgc3Ryb25nPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIFtTRU5ERVItSURdLCBhbmQgW1BSQV0sIGlu ZGljYXRlcyB0aGF0IHRoZXJlIGlzIG5vdCBhIHN0cm9uZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgY29tbXVuaXR5IGRlcGxveWlu ZyBhbmQgdXNpbmcgdGhlc2UgcHJvdG9jb2xzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICBjb21tdW5pdHkgZGVwbG95aW5nIGFuZCB1c2luZyB0aGVzZSBwcm90b2NvbHMu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjIiIC8+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj40PC9zcGFuPi4gIFtT UEZdIGhhcyB3aWRlc3ByZWFkIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50LCBjb21wYXJh YmxlIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJp bnNlcnQiPjU8L3NwYW4+LiAgW1NQRl0gaGFzIHdpZGVzcHJlYWQgaW1wbGVtZW50YXRpb24gYW5k IGRlcGxveW1lbnQsIGNvbXBhcmFibGUgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIHRoYXQgb2YgbWFueSBzdGFuZGFyZHMgdHJh Y2sgcHJvdG9jb2xzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICB0aGF0 IG9mIG1hbnkgc3RhbmRhcmRzIHRyYWNrIHByb3RvY29scy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIEFwcGVuZGl4IEEgaXMgb2ZmZXJlZCBhcyBhIGNhdXRpb25hcnkgcmV2aWV3IG9m IHByb2JsZW1zIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBcHBlbmRp eCBBIGlzIG9mZmVyZWQgYXMgYSBjYXV0aW9uYXJ5IHJldmlldyBvZiBwcm9ibGVtcyB0aGF0PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFm ZmVjdGVkIHRoZSBwcm9jZXNzIG9mIGRldmVsb3BpbmcgU1BGIGFuZCBTZW5kZXIgSUQgaW4gdGVy bXMgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhZmZlY3RlZCB0aGUgcHJv Y2VzcyBvZiBkZXZlbG9waW5nIFNQRiBhbmQgU2VuZGVyIElEIGluIHRlcm1zIG9mPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZWlyIHVz ZSBvZiB0aGUgRE5TLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZWlyIHVz ZSBvZiB0aGUgRE5TLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDIzIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+Ny4gIDxzcGFuIGNsYXNzPSJkZWxldGUi PklBTkEgQ29uc2lkZXJhdGlvbnM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ ICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBubyBhY3Rpb25zIGZvciBJQU5BLiAgW1JGQyBFZGl0 b3I6IFBsZWFzZTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4g Y2xhc3M9ImRlbGV0ZSI+ICAgcmVtb3ZlIHRoaXMgc2VjdGlvbiBwcmlvciB0byBwdWJsaWNhdGlv bi5dPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPjguPC9zcGFuPiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBU aGlzIGRvY3VtZW50IGNvbnRhaW5zIGluZm9ybWF0aW9uIGZvciB0aGUgY29tbXVuaXR5LCBha2lu IHRvIGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBj b250YWlucyBpbmZvcm1hdGlvbiBmb3IgdGhlIGNvbW11bml0eSwgYWtpbiB0byBhbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbXBsZW1l bnRhdGlvbiByZXBvcnQsIGFuZCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGltcGxlbWVudGF0aW9uIHJlcG9ydCwg YW5kIGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IHNlY3VyaXR5PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbmNlcm5zLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbmNlcm5zLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDI0IiAvPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjgu ICBJQU5BIENvbnNpZGVyYXRpb25zPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMg bm8gYWN0aW9ucyBmb3IgSUFOQS4gIFtSRkMgRWRpdG9yOiBQbGVhc2U8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHJlbW92ZSB0 aGlzIHNlY3Rpb24gcHJpb3IgdG8gcHVibGljYXRpb24uXTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij45LiAgUmVmZXJlbmNlczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjkuICBSZWZlcmVuY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij45LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBbRE5TXSAgICAgIE1vY2thcGV0cmlzLCBQLiwgIkRvbWFpbiBuYW1lcyAtIGlt cGxlbWVudGF0aW9uIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtETlNd ICAgICAgTW9ja2FwZXRyaXMsIFAuLCAiRG9tYWluIG5hbWVzIC0gaW1wbGVtZW50YXRpb24gYW5k PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgc3BlY2lmaWNhdGlvbiIsIFNURCAxMywgUkZDIDEwMzUsIE5vdmVtYmVyIDE5 ODcuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBzcGVjaWZp Y2F0aW9uIiwgU1REIDEzLCBSRkMgMTAzNSwgTm92ZW1iZXIgMTk4Ny48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFtQUkFdICAgICAgTHlvbiwgSi4sICJQdXJwb3J0ZWQgUmVzcG9uc2li bGUgQWRkcmVzcyBpbiBFLU1haWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBb UFJBXSAgICAgIEx5b24sIEouLCAiUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MgaW4gRS1N YWlsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgTWVzc2FnZXMiLCBSRkMgNDQwNywgQXByaWwgMjAwNi48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIE1lc3NhZ2VzIiwgUkZDIDQ0MDcs IEFwcmlsIDIwMDYuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9 ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNyIgLz48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTAsIGxpbmUgMzY8L2VtPjwvdGg+PHRoPiA8 L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI3IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8 L3NtYWxsPjxlbT4gcGFnZSAxMSwgbGluZSAzMzwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgY29ycmVjdCwgYnV0IHRoZSByZWFsaXR5IGlzIHRoYXQgdGhleSBhcmUgYW1vbmcgdXMg YW5kIGxpa2VseSB3aWxsIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29y cmVjdCwgYnV0IHRoZSByZWFsaXR5IGlzIHRoYXQgdGhleSBhcmUgYW1vbmcgdXMgYW5kIGxpa2Vs eSB3aWxsIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGZvciBzb21lIHRpbWUsIGFuZCB0aGlzIG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQg YXMgbmV3IHByb3RvY29scyBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBm b3Igc29tZSB0aW1lLCBhbmQgdGhpcyBuZWVkcyB0byBiZSBjb25zaWRlcmVkIGFzIG5ldyBwcm90 b2NvbHMgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIElFVEYgcHJvY2VkdXJlcyBhcmUgZGV2ZWxvcGVkLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIElFVEYgcHJvY2VkdXJlcyBhcmUgZGV2ZWxvcGVkLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QXBwZW5kaXggQi4gIEFja25vd2xlZGdtZW50czwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFwcGVuZGl4IEIuICBBY2tub3dsZWRnbWVudHM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBmb2xsb3dpbmcgcHJvdmlkZWQgb3BlcmF0 aW9uYWwgZGF0YSB0aGF0IGNvbnRyaWJ1dGVkIHRvIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFRoZSBmb2xsb3dpbmcgcHJvdmlkZWQgb3BlcmF0aW9uYWwgZGF0YSB0aGF0 IGNvbnRyaWJ1dGVkIHRvIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBldmlkZW5jZSBwcmVzZW50ZWQgYWJvdmU6PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXZpZGVuY2UgcHJlc2VudGVkIGFib3ZlOjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ2lzY286ICBjb250cmlidXRlZCBkYXRhIGFib3V0IG9i c2VydmVkIFNlbmRlciBJRCBhbmQgU1BGIHJlY29yZHMgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBDaXNjbzogIGNvbnRyaWJ1dGVkIGRhdGEgYWJvdXQgb2JzZXJ2ZWQgU2Vu ZGVyIElEIGFuZCBTUEYgcmVjb3JkcyBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjUiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAgICB0aGUgRE5TIGZvciBhIGxhcmdlIG51bWJlciBvZiBkb21haW5z PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIHRoZSBETlMgZm9yIGEgbGFy Z2UgbnVtYmVyIG9mIGRvbWFpbnM8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gKEROUyBzdXJ2ZXkgIzEp PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSG90bWFpbDogIGNvbnRyaWJ1 dGVkIGRhdGEgYWJvdXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEhvdG1haWw6ICBjb250cmlidXRlZCBkYXRhIGFib3V0IHRoZSBkaWZm ZXJlbmNlIGJldHdlZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgUkZDNTMyMS5NYWlsRnJvbSBhbmQgUkZDNTMyMi5Gcm9tIGRvbWFp bnMgYWNyb3NzIGxhcmdlIG1haWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBSRkM1MzIxLk1haWxGcm9tIGFuZCBSRkM1MzIyLkZyb20gZG9tYWlucyBhY3Jvc3MgbGFyZ2Ug bWFpbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjYiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICB2 b2x1bWVzLCBhbmQgYSBzdXJ2ZXkgb2YgRE5TIDxzcGFuIGNsYXNzPSJkZWxldGUiPnF1ZXJpZXM8 L3NwYW4+IG9ic2VydmVkIGluIHJlc3BvbnNlIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgIHZvbHVtZXMsIGFuZCBhIHN1cnZleSBvZiBETlMgPHNwYW4gY2xhc3M9Imlu c2VydCI+cmVwbGllczwvc3Bhbj4gb2JzZXJ2ZWQgaW4gcmVzcG9uc2UgdG88L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICA8c3BhbiBj bGFzcz0iZGVsZXRlIj5vdXRnb2luZzwvc3Bhbj4gbWFpbCB0cmFmZmljPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmluY29taW5nPC9z cGFuPiBtYWlsIHRyYWZmaWMgPHNwYW4gY2xhc3M9Imluc2VydCI+KEROUyBzdXJ2ZXkgIzMpPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSm9obiBMZXZpbmU6ICBjb25kdWN0 ZWQgYSBzdXJ2ZXkgb2YgRE5TIHNlcnZlciBsb2dzIHRvIGV2YWx1YXRlIFNQRi08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBKb2huIExldmluZTogIGNvbmR1Y3RlZCBhIHN1cnZl eSBvZiBETlMgc2VydmVyIGxvZ3MgdG8gZXZhbHVhdGUgU1BGLTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICByZWxhdGVkIHF1ZXJ5IHRy YWZmaWM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICByZWxhdGVkIHF1ZXJ5 IHRyYWZmaWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1jQWZlZTogIHByb3ZpZGVk IGRldGFpbHMgYWJvdXQgdGhlaXIgU1VCTUlUVEVSIGltcGxlbWVudGF0aW9uIGFuZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE1jQWZlZTogIHByb3ZpZGVkIGRldGFpbHMgYWJv dXQgdGhlaXIgU1VCTUlUVEVSIGltcGxlbWVudGF0aW9uIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB1c2FnZSBzdGF0aXN0aWNz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdXNhZ2Ugc3RhdGlzdGljczwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwMjciIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgU2FudHJvbmljczogIGNvbnRyaWJ1dGVkIGRhdGEgYWJvdXQgdGhlIHVzZSBvZiB0 aGUgU1VCTUlUVEVSPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU2FudHJvbmlj czogIGNvbnRyaWJ1dGVkIGRhdGEgYWJvdXQgdGhlIHVzZSBvZiB0aGUgU1VCTUlUVEVSPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGV4 dGVuc2lvbiBpbiBhZ2dyZWdhdGUgU01UUCBjbGllbnQgdHJhZmZpYzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIGV4dGVuc2lvbiBpbiBhZ2dyZWdhdGUgU01UUCBjbGllbnQg dHJhZmZpYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjgiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIFRydXN0ZWQgRG9tYWluIFByb2plY3Q6ICBjb250cmlidXRl ZCBkYXRhIGFib3V0IHRoZSBkaWZmZXJlbmNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgVGhlIFRydXN0ZWQgRG9tYWluIFByb2plY3Q6ICBjb250cmlidXRlZCBkYXRhIGFib3V0 IHRoZSBkaWZmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyOSIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgIGJldHdlZW4gU2VuZGVyIElEIGFuZCBTUEYgcmVzdWx0cywgY29uZHVjdGVkIG9u ZSBvZiB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dHdvPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgICBiZXR3ZWVuIFNlbmRlciBJRCBhbmQgU1BGIHJlc3VsdHMs IGNvbmR1Y3RlZCBvbmUgb2YgdGhlIGRldGFpbGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgZGV0YWlsZWQgVFhUL1NQRiBSUlRZ UEUgc3VydmV5cyBpbmNsdWRpbmcgY29sbGVjdGluZyB0aW1pbmcgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+ZGF0YSw8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIFRY VC9TUEYgUlJUWVBFIHN1cnZleXMgaW5jbHVkaW5nIGNvbGxlY3RpbmcgdGltaW5nIDxzcGFuIGNs YXNzPSJpbnNlcnQiPmRhdGEgKEROUzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBhbmQgY29uZHVjdGVkIHRoZSBNVEEg U1VCTUlUVEVSIHN1cnZleTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICAgICBzdXJ2ZXkgIzIpLDwvc3Bhbj4gYW5kIGNvbmR1Y3RlZCB0aGUg TVRBIFNVQk1JVFRFUiBzdXJ2ZXk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBh dXRob3Igd291bGQgYWxzbyBsaWtlIHRvIHRoYW5rIHRoZSBmb2xsb3dpbmcgZm9yIHRoZWlyPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGF1dGhvciB3b3VsZCBhbHNvIGxp a2UgdG8gdGhhbmsgdGhlIGZvbGxvd2luZyBmb3IgdGhlaXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29udHJpYnV0aW9ucyB0byB0aGUg ZGV2ZWxvcG1lbnQgb2YgdGhlIHRleHQgaW4gdGhpcyBkb2N1bWVudDogRGF2ZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbnRyaWJ1dGlvbnMgdG8gdGhlIGRldmVsb3BtZW50 IG9mIHRoZSB0ZXh0IGluIHRoaXMgZG9jdW1lbnQ6IERhdmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ3JvY2tlciwgU2NvdHQgS2l0dGVy bWFuLCBCYXJyeSBMZWliYSwgSm9obiBMZXNsaWUsIEpvaG4gTGV2aW5lLDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIENyb2NrZXIsIFNjb3R0IEtpdHRlcm1hbiwgQmFycnkgTGVp YmEsIEpvaG4gTGVzbGllLCBKb2huIExldmluZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSGVjdG9yIFNhbnRvcywgYW5kIEFsZXNzYW5k cm8gVmVzZWx5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhlY3RvciBTYW50 b3MsIGFuZCBBbGVzc2FuZHJvIFZlc2VseS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkF1 dGhvcidzIEFkZHJlc3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BdXRob3IncyBB ZGRyZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBNdXJyYXkgUy4gS3VjaGVyYXd5 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTXVycmF5IFMuIEt1Y2hlcmF3eTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBD bG91ZG1hcms8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDbG91ZG1hcms8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgoKICAgICA8dHI+PHRk PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0aCBjb2xzcGFuPSI1 IiBhbGlnbj0iY2VudGVyIj48YSBuYW1lPSJlbmQiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAyOSBj aGFuZ2UgYmxvY2tzLiZuYnNwOzwvYT48L3RoPjwvdHI+CiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+ PHRkPjwvdGQ+PHRoPjxpPjgwIGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0aD48 aT4gPC9pPjwvdGg+PHRoPjxpPjEyOCBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRk PjwvdGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiIGNsYXNz PSJzbWFsbCI+PGJyLz5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjMz LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3 dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyIgPmh0dHA6Ly90b29scy5pZXRmLm9yZy90 b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3RhYmxlPgogICA8L2JvZHk+CiAgIDwv aHRtbD4K --_002_9452079D1A51524AA5749AD23E00392810794Fexchmbx901corpclo_--