From nobody Mon Oct 6 23:37:44 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA581A1B34 for ; Mon, 6 Oct 2014 23:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Tb-Rjrx5mC4 for ; Mon, 6 Oct 2014 23:37:40 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [192.36.115.55]) by ietfa.amsl.com (Postfix) with ESMTP id B7ABF1A1AF9 for ; Mon, 6 Oct 2014 23:37:40 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 80BB89CF4; Tue, 7 Oct 2014 08:37:38 +0200 (CEST) Date: Tue, 7 Oct 2014 08:37:38 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: spfbis@ietf.org Message-ID: <20141007063737.GA28581@besserwisser.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/0ITXqSEUdKIDkdjri5NaPQUIzmM Subject: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 06:37:43 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Since only 14.82 percent of the combined TXT||SPF queries received by my authoritative master are SPF we must surely congratulate the SPF working group in being correct by determining that there are impassable barriers to deplying new RR types on the Internet. Only 1 in 7 queries -- clearly a minority -- are for this new, unusable RR type. ----- Forwarded message from Cron Daemon ----- Date: Mon, 6 Oct 2014 22:27:09 GMT =46rom: Cron Daemon To: root@primary.se Subject: Cron /usr/local/libexec/spf-txt.sh TXT:12065 SPF:2100 ----- End forwarded message ----- --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Everybody gets free BORSCHT! --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlQzijEACgkQ02/pMZDM1cWx5QCgpBZPI7/JZwu4J/vMvzOe8gn5 Z7YAn0cMMaoozh+H84n/0FibWT9TaD9t =dA1X -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From nobody Tue Oct 7 03:07:40 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4951ACD3B for ; Tue, 7 Oct 2014 03:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jr-CudGk4-GR for ; Tue, 7 Oct 2014 03:07:36 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FC21ACD01 for ; Tue, 7 Oct 2014 03:07:36 -0700 (PDT) Received: from [172.16.34.16] (unknown [50.189.173.0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id F28298A031; Tue, 7 Oct 2014 10:07:25 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Andrew Sullivan X-Mailer: iPhone Mail (11D257) In-Reply-To: <20141007063737.GA28581@besserwisser.org> Date: Tue, 7 Oct 2014 06:07:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141007063737.GA28581@besserwisser.org> To: =?utf-8?Q?M=C3=A5ns_Nilsson?= Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/VrTgb8CoGa8L6rTG_pY8DieAqjs Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 10:07:38 -0000 It's always fun to be sarcastic, but you seem to be missing a point. =20 The WG did not decide to deprecate the type for fun. The problem was that t= here was a bug in the original RFC: the way the TXT and TYPE99 RRtype use wa= s specified, it was possible for two implementations to be fully conforming w= ithout being able to interoperate. So we had to make an incompatible change o= f some kind, and given the empirical evidence we had the WG decided that pic= king only one was safest. TXT remains the overwhelming leader, so it won. =20= A --=20 Andrew Sullivan=20 Please excuse my clumbsy thums.=20 > On Oct 7, 2014, at 2:37, M=C3=A5ns Nilsson wro= te: >=20 > Since only 14.82 percent of the combined TXT||SPF queries received by my > authoritative master are SPF we must surely congratulate the SPF working > group in being correct by determining that there are impassable barriers > to deplying new RR types on the Internet. Only 1 in 7 queries -- > clearly a minority -- are for this new, unusable RR type. >=20 > ----- Forwarded message from Cron Daemon ----- >=20 > Date: Mon, 6 Oct 2014 22:27:09 GMT > From: Cron Daemon > To: root@primary.se > Subject: Cron /usr/local/libexec/spf-txt.sh >=20 > TXT:12065 SPF:2100 >=20 > ----- End forwarded message ----- >=20 > --=20 > M=C3=A5ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > Everybody gets free BORSCHT! > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From nobody Tue Oct 7 07:37:26 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2F31ACDA4 for ; Tue, 7 Oct 2014 07:37:24 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.786, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1BDkuA4VmfV for ; Tue, 7 Oct 2014 07:37:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C0F1A6F3D for ; Tue, 7 Oct 2014 07:37:21 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.129.236]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s97Eb3EP006659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 07:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1412692636; x=1412779036; bh=kAW5noSWW0eKzmahd4k4BXN8McGSrBm4LUkLsMuACFM=; h=Date:To:From:Subject:In-Reply-To:References; b=zFngK5rfBUNDzbf7m9wni99Rk7o+q8boKbehqfN1w+Vb/dsRETV7IZPMTWkXCWpBN 93C+DQNGabsxASuFdAm7UfiOcdPQHVIzo0Ow2fLSqB9wVNiWY+XUIHwRTzz5lQGl06 ihlbCPVAJ5qrWPvjKgRVlT1p7noc85te3GJhXaMM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1412692636; x=1412779036; i=@elandsys.com; bh=kAW5noSWW0eKzmahd4k4BXN8McGSrBm4LUkLsMuACFM=; h=Date:To:From:Subject:In-Reply-To:References; b=QV8FVCVY/bpHsoykaCrNAbQcelyqjNxLbXKCRhlYqfcPWq3wsVjbBaMW3o2EgVoeF oWD1c2pbWwZpolY+cJfdNmywKq67DO6m6Ek+As2Fs2OTK+/wYHUpPkAG5TzZ8I45Xo eiRA/TgV9LBLA4/RjJMtDUTfxaSPnGFGGjI+zWj4= Message-Id: <6.2.5.6.2.20141007065756.0be13418@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Oct 2014 07:31:09 -0700 To: Mans Nilsson , spfbis@ietf.org From: S Moonesamy In-Reply-To: <20141007063737.GA28581@besserwisser.org> References: <20141007063737.GA28581@besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/kaLTXbGBJLPxFBlaOYVz-hzA15I Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:37:24 -0000 Hello, At 23:37 06-10-2014, Mans Nilsson wrote: >Since only 14.82 percent of the combined TXT||SPF queries received by my >authoritative master are SPF we must surely congratulate the SPF working >group in being correct by determining that there are impassable barriers >to deplying new RR types on the Internet. Only 1 in 7 queries -- >clearly a minority -- are for this new, unusable RR type. The following is from the write-up: "There was an intermediate conclusion about the topic of whether the SPF protocol should use the SPF RRTYPE or the TXT resource record. It was followed by an objection. After discussion of the topic at the IETF 83 SPFBIS WG session the conclusion reached was that the decision would be not to publish RRTYPE 99 and and not to query RRTYPE 99. The WG consensus about the RRTYPE can be described as particularly rough. The topic of obsoleting the SPF RRTYPE generated a lot of controversy near the end of the WGLC. There were a very high number of messages about the topic on the SPFBIS mailing list and the DNSEXT mailing list as some DNSEXT WG participants were not aware of RFC 6686." The decision about which RR type to choose was not about one of them being clearly a minority. I went through the discussions about the RR Type several times. I also did that after the decision was taken to see whether it was the wrong choice. A choice had to be made. I am okay with being criticized for that choice. Regards, S. Moonesamy From nobody Tue Oct 7 09:15:54 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1621A6FC0 for ; Tue, 7 Oct 2014 09:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcI1BR78y81j for ; Tue, 7 Oct 2014 09:15:51 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DBE1A0299 for ; Tue, 7 Oct 2014 09:15:50 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x13so9669075wgg.18 for ; Tue, 07 Oct 2014 09:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=44hbQwxJHz/EVLWhLVYIqd17jjKcc/eyNFTNVbv3eqM=; b=ksBRATQWrrr/AjqIAbORVJE2Yi01B74Rl2L6sboealp76wB7/rz+86cbabS7PkVTye NQqCsXZCWeSS9d8u5kW6SuW5yocUOaWxs9YnMJVTaDJ2zU8R3CI+HhGFEET5/N/cRzz2 N6Apu7iGvhQv4EO7s5G3pJNZvkpY+iBZCeDiIlqCvxNUMKkIZOPLhwrXge7kTuaD/WU2 Itm6v6JwAs+hhoBWcpZSKsS6U58J0q7TSGkT4SEqiobgrCaAqy8UXTrt2obUE4CaDEdf 0PZQIrmPfbX9NjjdCzvc45nvRBctkSCXJqEWPhlpd9IaMFqLUVXHwhb/iN0gluoEtCiW TiKw== MIME-Version: 1.0 X-Received: by 10.194.219.193 with SMTP id pq1mr6113566wjc.5.1412698549109; Tue, 07 Oct 2014 09:15:49 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 7 Oct 2014 09:15:49 -0700 (PDT) In-Reply-To: References: <20141007063737.GA28581@besserwisser.org> Date: Tue, 7 Oct 2014 09:15:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c2862031cc280504d783ef Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/zIiMxZrhStDHXBvcqCB8QUzTrGY Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:15:52 -0000 --001a11c2862031cc280504d783ef Content-Type: text/plain; charset=UTF-8 On Tue, Oct 7, 2014 at 3:07 AM, Andrew Sullivan wrote: > It's always fun to be sarcastic, but you seem to be missing a point. > > The WG did not decide to deprecate the type for fun. The problem was that > there was a bug in the original RFC: the way the TXT and TYPE99 RRtype use > was specified, it was possible for two implementations to be fully > conforming without being able to interoperate. So we had to make an > incompatible change of some kind, and given the empirical evidence we had > the WG decided that picking only one was safest. TXT remains the > overwhelming leader, so it won. > Given the survey work recorded in RFC6686, I would be curious to hear people's theories explaining the substantial uptick of TYPE99 queries in the last two years while the industry has actually gone in the opposite direction. Of course, that presumes there's ample breadth and no bias in the traffic seen by this one resolver. -MSK --001a11c2862031cc280504d783ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 7, 2014 at 3:07 AM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
It's always fun= to be sarcastic, but you seem to be missing a point.

The WG did not decide to deprecate the type for fun.=C2=A0 The problem was = that there was a bug in the original RFC: the way the TXT and TYPE99 RRtype= use was specified, it was possible for two implementations to be fully con= forming without being able to interoperate. So we had to make an incompatib= le change of some kind, and given the empirical evidence we had the WG deci= ded that picking only one was safest.=C2=A0 TXT remains the overwhelming le= ader, so it won.

Given the survey work = recorded in RFC6686, I would be curious to hear people's theories expla= ining the substantial uptick of TYPE99 queries in the last two years while = the industry has actually gone in the opposite direction.=C2=A0 Of course, = that presumes there's ample breadth and no bias in the traffic seen by = this one resolver.

-MSK
--001a11c2862031cc280504d783ef-- From nobody Tue Oct 7 09:42:32 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB761ACE4C for ; Tue, 7 Oct 2014 09:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpppcMjzhw1X for ; Tue, 7 Oct 2014 09:42:24 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA771ACE54 for ; Tue, 7 Oct 2014 09:42:24 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E8EA38A031 for ; Tue, 7 Oct 2014 16:42:22 +0000 (UTC) Date: Tue, 7 Oct 2014 12:42:21 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20141007164221.GF19697@mx1.yitter.info> References: <20141007063737.GA28581@besserwisser.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/L-vRCyschbtVWBvjPOvPuIOAP0k Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:42:25 -0000 On Tue, Oct 07, 2014 at 09:15:49AM -0700, Murray S. Kucherawy wrote: > > Given the survey work recorded in RFC6686, I would be curious to hear > people's theories explaining the substantial uptick of TYPE99 queries in > the last two years while the industry has actually gone in the opposite > direction. Of course, that presumes there's ample breadth and no bias in > the traffic seen by this one resolver. We had methodological issues at the time of RFC 6686, too, so I think we ought to be careful about speculating too much. But I seem to recall someone telling us, right around the time of 6686, that some new SPF checking code had just shipped that used TYPE99 as the default. This news came too late in the publication cycle to change the text. But it shouldn't be surprising that we see this now. None of that matters, however, because the original RFC had that interoperability bug in it, and the only reasonable thing to do was to pick one type to look up. I'm unhappy about using TXT, too, and registered that unhappiness at the time. But the deployed code is a strong argument. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Oct 7 11:04:20 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFF21A8FD4 for ; Tue, 7 Oct 2014 11:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVm1OGUdXFCr for ; Tue, 7 Oct 2014 11:04:15 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C8C1ACEF5 for ; Tue, 7 Oct 2014 11:03:35 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 14:03:07 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 7 Oct 2014 14:03:34 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s97I3Nc8002721; Tue, 7 Oct 2014 14:03:23 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Scott Rose In-Reply-To: Date: Tue, 7 Oct 2014 14:03:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <55ED1A31-355E-4281-8EBE-EBBB19FEAB96@gmail.com> References: <20141007063737.GA28581@besserwisser.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/qSlj1QVZt-ALoKl6bx_8rg5OnMs Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 18:04:17 -0000 On Oct 7, 2014, at 12:15 PM, Murray S. Kucherawy = wrote: > Given the survey work recorded in RFC6686, I would be curious to hear = people's theories explaining the substantial uptick of TYPE99 queries in = the last two years while the industry has actually gone in the opposite = direction. Of course, that presumes there's ample breadth and no bias = in the traffic seen by this one resolver. >=20 I know there has been a push to deploy SPF and DKIM in the .gov TLD, so = that may be some of the uptick. =46rom past experience, I would wager = most enterprises are using older, already deployed code that does = queries for both TYPE99 and TXT RR's when looking for SPF polices. For = .gov agencies, if they have existing, known code that has the = functionality, it's easier to turn it on then upgrade. Wouldn't account = for all of the increase though. Scott > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Oct 7 14:27:20 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C291A8868 for ; Tue, 7 Oct 2014 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.687 X-Spam-Level: X-Spam-Status: No, score=-7.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StH8bA_zHkGk for ; Tue, 7 Oct 2014 14:27:06 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C191A886A for ; Tue, 7 Oct 2014 14:27:06 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 961161FCAA0; Tue, 7 Oct 2014 21:27:02 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2A459160068; Tue, 7 Oct 2014 21:30:02 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id E80E716005A; Tue, 7 Oct 2014 21:30:01 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DB75220DE476; Wed, 8 Oct 2014 08:26:57 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20141007063737.GA28581@besserwisser.org> <20141007164221.GF19697@mx1.yitter.info> In-reply-to: Your message of "Tue, 07 Oct 2014 12:42:21 -0400." <20141007164221.GF19697@mx1.yitter.info> Date: Wed, 08 Oct 2014 08:26:57 +1100 Message-Id: <20141007212657.DB75220DE476@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/2tBYv31sLPeJuBzGtitBiLoVzT8 Cc: spfbis@ietf.org Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:27:17 -0000 In message <20141007164221.GF19697@mx1.yitter.info>, Andrew Sullivan writes: > On Tue, Oct 07, 2014 at 09:15:49AM -0700, Murray S. Kucherawy wrote: > > > > Given the survey work recorded in RFC6686, I would be curious to hear > > people's theories explaining the substantial uptick of TYPE99 queries in > > the last two years while the industry has actually gone in the opposite > > direction. Of course, that presumes there's ample breadth and no bias in > > the traffic seen by this one resolver. > > We had methodological issues at the time of RFC 6686, too, so I think > we ought to be careful about speculating too much. > > But I seem to recall someone telling us, right around the time of > 6686, that some new SPF checking code had just shipped that used > TYPE99 as the default. This news came too late in the publication > cycle to change the text. But it shouldn't be surprising that we see > this now. The working group got told repeatedly that they just had to wait as new code went from being written to being deployed. They got given data that showed type spf queries were increasing. They just refused to listen and used the stupid excuse of type txt not "working" with type spf to claim that they had to abandon the transition. There was plenty of time to change the decision but they refused to listen. Transitions like this take about a decade and they abandoned the transition early. > None of that matters, however, because the original RFC had that > interoperability bug in it, and the only reasonable thing to do was to > pick one type to look up. I'm unhappy about using TXT, too, and > registered that unhappiness at the time. But the deployed code is a > strong argument. When you jump to the end state of SPF only, of course it won't work with TXT. However there was nothing wrong with that. Also there was nothing preventing people publishing both types if they wanted to during the transition. There was nothing preventing the transition continuing. The real reason that most of the working group didn't want to move from TXT and resented that DNS people said use a seperate type for this and resisted changing things. > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Oct 7 14:54:12 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C421A88C8 for ; Tue, 7 Oct 2014 14:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewiSOrVVcw11 for ; Tue, 7 Oct 2014 14:54:08 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2181A884C for ; Tue, 7 Oct 2014 14:54:08 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so5624417vcb.38 for ; Tue, 07 Oct 2014 14:54: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; bh=iFdnaBLUa4cOEKt7T0RGrC27+vGodDDpvHbuDA2T5wY=; b=PXKzc0eJK678GFCLCFtIKYj/mnRQUaFouMvMqbOxrKc98frPpnWJjTpVjp1Aqpeaji DQQKRPHuKi1ABcpZArbovVsGcyyEiWuWRimH54kIBk6DgoxXuBEafY4g5hXP3T8ELGO4 N/NIHHGFw6KZcL24g+492lsdIZM6yG9OsqV8TTw89gM1mmB6xgaGzOKUfmeu66uRiBVB tIFnvTUIe+Oe9ZSj8000EXwp8BpzqCStzGTDjgaww/IWbvbn0UjzYsrqtb6IWxQY+CfQ dVgqPzHoXlywJuikj9Sr2tdb+xvKsWfINMihUV0z3BB+d34HUUTccJ4wWNY1fyyE5p89 HD7g== MIME-Version: 1.0 X-Received: by 10.52.227.39 with SMTP id rx7mr5030945vdc.13.1412718847711; Tue, 07 Oct 2014 14:54:07 -0700 (PDT) Received: by 10.52.79.66 with HTTP; Tue, 7 Oct 2014 14:54:07 -0700 (PDT) In-Reply-To: <20141007212657.DB75220DE476@rock.dv.isc.org> References: <20141007063737.GA28581@besserwisser.org> <20141007164221.GF19697@mx1.yitter.info> <20141007212657.DB75220DE476@rock.dv.isc.org> Date: Tue, 7 Oct 2014 14:54:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews , Scott Kitterman Content-Type: multipart/alternative; boundary=089e01161ba615e0b30504dc3dcc Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/L3DvdJcHjBx3utPDLg_-otz0MCM Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:54:10 -0000 --089e01161ba615e0b30504dc3dcc Content-Type: text/plain; charset=UTF-8 On Tue, Oct 7, 2014 at 2:26 PM, Mark Andrews wrote: > The working group got told repeatedly that they just had to wait > as new code went from being written to being deployed. They got > given data that showed type spf queries were increasing. They just > refused to listen and used the stupid excuse of type txt not "working" > with type spf to claim that they had to abandon the transition. > Sorry, but "refused to listen" is false. Your position was heard and extensively debated. The working group simply did not concur. When you jump to the end state of SPF only, of course it won't work > with TXT. However there was nothing wrong with that. Also there > was nothing preventing people publishing both types if they wanted > to during the transition. There was nothing preventing the transition > continuing. > It would be wonderful to have any evidence other than DNS RRTYPE counts to support the idea that there was any such organized transition in progress. Perhaps you or Mans can share from whom all these new type 99 queries are coming? Meanwhile, I have not heard one peep from anyone in any of the email communities to which I am connected that there's an attempt to move toward type 99, not in 2012 and not today. In fact, the contrary is probably true given that the main open source implementation has (as I understand it) since removed its type 99 query code. Does anyone still paying attention to this list have any such information? I'm genuinely curious. I've put out some feelers to the places where I think the increased type 99 queries might be originating. I've yet to hear back. Scott, I can't think of anyone more connected to SPF than you are: Are you aware of such a transition? > The real reason that most of the working group didn't want to move > from TXT and resented that DNS people said use a seperate type for > this and resisted changing things. I don't think I can parse this sentence. I suspect though that Appendix A of RFC6686 better characterizes the situation than "resented"; the resistance to which you refer was a lot more pragmatic than emotional. -MSK --089e01161ba615e0b30504dc3dcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 7, 2014 at 2:26 PM, Mark Andrews <marka@isc.org> wrote:
The working group= got told repeatedly that they just had to wait
as new code went from being written to being deployed.=C2=A0 They got
given data that showed type spf queries were increasing.=C2=A0 They just refused to listen and used the stupid excuse of type txt not "working&= quot;
with type spf to claim that they had to abandon the transition.

Sorry, but "refused to listen" is false.= =C2=A0 Your position was heard and extensively debated.=C2=A0 The working g= roup simply did not concur.

When you jump to the end state of SPF only, of course = it won't work
with TXT.=C2=A0 However there was nothing wrong with that.=C2=A0 Also there=
was nothing preventing people publishing both types if they wanted
to during the transition.=C2=A0 There was nothing preventing the transition=
continuing.

It would be wonderful to ha= ve any evidence other than DNS RRTYPE counts to support the idea that there= was any such organized transition in progress.=C2=A0 Perhaps you or Mans c= an share from whom all these new type 99 queries are coming?

Meanwhi= le, I have not heard one peep from anyone in any of the email communities t= o which I am connected that there's an attempt to move toward type 99, = not in 2012 and not today.=C2=A0 In fact, the contrary is probably true giv= en that the main open source implementation has (as I understand it) since = removed its type 99 query code.=C2=A0 Does anyone still paying attention to= this list have any such information?=C2=A0 I'm genuinely curious.=C2= =A0 I've put out some feelers to the places where I think the increased= type 99 queries might be originating.=C2=A0 I've yet to hear back.
=
Scott, I can't think of anyone more connected to SPF tha= n you are: Are you aware of such a transition?
=C2=A0
The real reason that most of the working group didn't want to move
from TXT and resented that DNS people said use a seperate type for
this and resisted changing things.

I don= 9;t think I can parse this sentence.=C2=A0 I suspect though that Appendix A= of RFC6686 better characterizes the situation than "resented"; t= he resistance to which you refer was a lot more pragmatic than emotional.
-MSK
--089e01161ba615e0b30504dc3dcc-- From nobody Tue Oct 7 15:07:17 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E1E1A8937 for ; Tue, 7 Oct 2014 15:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa1R4QqoQIaM for ; Tue, 7 Oct 2014 15:07:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049E61A892A for ; Tue, 7 Oct 2014 15:07:15 -0700 (PDT) Received: from [10.180.120.144] (158.sub-70-192-193.myvzw.com [70.192.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EE139C40060; Tue, 7 Oct 2014 17:07:13 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1412719634; bh=6mR/Ve7lB/Ju22gN43JbSiRAdGYTgin064HB2tEvNow=; h=In-Reply-To:References:Subject:From:Date:To:From; b=iLBQb4ESsz0vVvIOI/VNLA8q33Y9aU5mlgO3uH1L0G9HCiB3GPqB2BT2zz/8rLq16 +nNGIuJ9x6lJ9VIfNa/fLQO3QyjaFXMZNvb7wnJyNBSrnBu3TDlzGfIpxqQh+IS1Ej EC7XBxcGggEDFC2Nhp95ldB09P9tL3uYcBSBbMyA= User-Agent: K-9 Mail for Android In-Reply-To: References: <20141007063737.GA28581@besserwisser.org> <20141007164221.GF19697@mx1.yitter.info> <20141007212657.DB75220DE476@rock.dv.isc.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 07 Oct 2014 18:07:11 -0400 To: "spfbis@ietf.org" Message-ID: <30D75E02-C7C5-4D6B-8435-B11D822C5262@kitterman.com> Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/a25-SyiaNEFlUEjVoPA7RKt4F_Q Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 22:07:17 -0000 On October 7, 2014 5:54:07 PM EDT, "Murray S. Kucherawy" wrote: >On Tue, Oct 7, 2014 at 2:26 PM, Mark Andrews wrote: > >> The working group got told repeatedly that they just had to wait >> as new code went from being written to being deployed. They got >> given data that showed type spf queries were increasing. They just >> refused to listen and used the stupid excuse of type txt not >"working" >> with type spf to claim that they had to abandon the transition. >> > >Sorry, but "refused to listen" is false. Your position was heard and >extensively debated. The working group simply did not concur. > >When you jump to the end state of SPF only, of course it won't work >> with TXT. However there was nothing wrong with that. Also there >> was nothing preventing people publishing both types if they wanted >> to during the transition. There was nothing preventing the >transition >> continuing. >> > >It would be wonderful to have any evidence other than DNS RRTYPE counts >to >support the idea that there was any such organized transition in >progress. >Perhaps you or Mans can share from whom all these new type 99 queries >are >coming? > >Meanwhile, I have not heard one peep from anyone in any of the email >communities to which I am connected that there's an attempt to move >toward >type 99, not in 2012 and not today. In fact, the contrary is probably >true >given that the main open source implementation has (as I understand it) >since removed its type 99 query code. Does anyone still paying >attention >to this list have any such information? I'm genuinely curious. I've >put >out some feelers to the places where I think the increased type 99 >queries >might be originating. I've yet to hear back. > >Scott, I can't think of anyone more connected to SPF than you are: Are >you >aware of such a transition? > I'm not particularly interested in spending time relitigating the issue with people throwing ad hominem attacks around. I have my opinion on whose listening skills were deficient. The working group decided and it's done. Revisiting it now doesn't make any sense. Scott K >> The real reason that most of the working group didn't want to move >> from TXT and resented that DNS people said use a seperate type for >> this and resisted changing things. > > >I don't think I can parse this sentence. I suspect though that >Appendix A >of RFC6686 better characterizes the situation than "resented"; the >resistance to which you refer was a lot more pragmatic than emotional. > >-MSK > > >------------------------------------------------------------------------ > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From nobody Tue Oct 7 21:48:16 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F4C1A90DA for ; Tue, 7 Oct 2014 21:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id darLbP844gzN for ; Tue, 7 Oct 2014 21:48:12 -0700 (PDT) Received: from smtp122.ord1c.emailsrvr.com (smtp122.ord1c.emailsrvr.com [108.166.43.122]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845831A90D9 for ; Tue, 7 Oct 2014 21:48:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id F197D8083D; Wed, 8 Oct 2014 00:48:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 991E1807F9; Wed, 8 Oct 2014 00:48:09 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.0.1.52] ([UNAVAILABLE]. [208.72.142.196]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.2.13); Wed, 08 Oct 2014 04:48:10 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_26E2CA07-CE8F-4003-B963-48CAA3692A7A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Olafur Gudmundsson In-Reply-To: <30D75E02-C7C5-4D6B-8435-B11D822C5262@kitterman.com> Date: Wed, 8 Oct 2014 00:48:07 -0400 Message-Id: <599A194A-836D-4D61-B7F7-50E9D08D51F9@ogud.com> References: <20141007063737.GA28581@besserwisser.org> <20141007164221.GF19697@mx1.yitter.info> <20141007212657.DB75220DE476@rock.dv.isc.org> <30D75E02-C7C5-4D6B-8435-B11D822C5262@kitterman.com> To: Scott Kitterman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/ckRdLuLLES7vq5fbrgMhTwLBXsA Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 04:48:14 -0000 --Apple-Mail=_26E2CA07-CE8F-4003-B963-48CAA3692A7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 7, 2014, at 6:07 PM, Scott Kitterman wrote: >>=20 > I'm not particularly interested in spending time relitigating the = issue with people throwing ad hominem attacks around. I have my opinion = on whose listening skills were deficient. =20 >=20 > The working group decided and it's done. Revisiting it now doesn't = make any sense.=20 >=20 > Scott K +1=20 SPF fans (like me) get over it, we lost and its time to move on.=20 The only moral is there is a lag between RFC publications and until = effects are seen.=20 Olafur --Apple-Mail=_26E2CA07-CE8F-4003-B963-48CAA3692A7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I'm not particularly = interested in spending time relitigating the issue with people throwing = ad hominem attacks around. I have my opinion on whose listening skills = were deficient.  

The working group decided and it's done. =   Revisiting it now doesn't make any sense. 

Scott = K

+1 

S= PF fans (like me) get over it, we lost and its time to move = on. 
The only moral is there is a lag between RFC = publications and until effects are = seen. 

= Olafur

= --Apple-Mail=_26E2CA07-CE8F-4003-B963-48CAA3692A7A-- From nobody Tue Oct 7 22:56:02 2014 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1C41ACD4C for ; Tue, 7 Oct 2014 22:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQxUafj3CUCZ for ; Tue, 7 Oct 2014 22:55:58 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id E71D21A9100 for ; Tue, 7 Oct 2014 22:55:57 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 981D29CF4; Wed, 8 Oct 2014 07:55:55 +0200 (CEST) Date: Wed, 8 Oct 2014 07:55:55 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: "Murray S. Kucherawy" Message-ID: <20141008055554.GB28581@besserwisser.org> References: <20141007063737.GA28581@besserwisser.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/spfbis/WpoBZvGYFATa_I05R3IK3DSb_8U Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 05:56:00 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Proof of non-deployment [root@primary.se: Cron /usr/local/libexec/spf-txt.sh] Date: Tue, Oct 07, 2014 at 09:15:49= AM -0700 Quoting Murray S. Kucherawy (superuser@gmail.com): >=20 > Given the survey work recorded in RFC6686, I would be curious to hear > people's theories explaining the substantial uptick of TYPE99 queries in > the last two years while the industry has actually gone in the opposite > direction. Of course, that presumes there's ample breadth and no bias in > the traffic seen by this one resolver. It is an authoritative name server with recursion no; in its configuration. It hosts among others my personal domains, so there is all the reason to suspect bias. I've seen similar figures from other name servers, hosted by other people, but they also might suffer from similar bias. (Not the least because these other data sources also=20 are run by DNS people who seem to believe that support for new RR types is possible..) The methodolgy for such collection is indeed not established -- as far as I can tell. There is some argument that you probably hit a larger amount of SPF lookup implementations when you are looking at auth server data; further, there is reason to expect that the width of data is influenced by the amount of email directed at domains hosted at the name server, and, finally, the number of domains hosted on the name server would be a strong component in influencing the data quality/relevance. If, OTOH, you want to look at what people have deployed, in terms of records in zones, a resolver serving a large outgoing SMTP relay would be the best point. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Kids, the seven basic food groups are GUM, PUFF PASTRY, PIZZA, PESTICIDES, ANTIBIOTICS, NUTRA-SWEET and MILK DUDS!! --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlQ00eoACgkQ02/pMZDM1cWWLQCeNbz2UbcQtOB0+YhNbedacP+S 9L8AniazpT3QXxYjIh3kTBdCtvcPT2MU =QXad -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD--