Re: [spfbis] Proof of non-deployment [root@primary.se: Cron <root@primary> /usr/local/libexec/spf-txt.sh]

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 07 October 2014 16:42 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 <spfbis@ietfa.amsl.com>; 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 <spfbis@ietfa.amsl.com>; 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 <spfbis@ietf.org>; 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 <spfbis@ietf.org>; Tue, 7 Oct 2014 16:42:22 +0000 (UTC)
Date: Tue, 07 Oct 2014 12:42:21 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: spfbis@ietf.org
Message-ID: <20141007164221.GF19697@mx1.yitter.info>
References: <20141007063737.GA28581@besserwisser.org> <D6213AB4-ABB2-45C5-AA52-59369B03B88F@anvilwalrusden.com> <CAL0qLwYpA_snEkjnCeXFcxf6kzt-8rF1+Uovypn1yNe+5VVB+w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL0qLwYpA_snEkjnCeXFcxf6kzt-8rF1+Uovypn1yNe+5VVB+w@mail.gmail.com>
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 <root@primary> /usr/local/libexec/spf-txt.sh]
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=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