Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

Eliot Lear <lear@cisco.com> Wed, 21 August 2013 10:27 UTC

Return-Path: <lear@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B073521F8413 for <ietf@ietfa.amsl.com>; Wed, 21 Aug 2013 03:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.123
X-Spam-Level:
X-Spam-Status: No, score=-110.123 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 k6AcmiNR1WGc for <ietf@ietfa.amsl.com>; Wed, 21 Aug 2013 03:26:58 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id C102D11E81BA for <ietf@ietf.org>; Wed, 21 Aug 2013 03:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6459; q=dns/txt; s=iport; t=1377080818; x=1378290418; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=YQ0TfDENoA66D7xHtuoNBr6bnzL7iaUIDFNhSLgu28k=; b=E8vX9XUuEge4Qs8f/HiB6f6LJMm1R/2H6+AvmcB+ncJ3bBRFHDg6v74m XIFrPEAYdPP/oNSP9WP2j2swCLcEwxzUqh1V1MimrRwAIHExhs3moNd3m iDQO9LFy6VEEcnBpw8mSzuRqb2DZnzrHec8n4pv+273L3kxgTHJ5Zc669 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFADaVFFKQ/khM/2dsb2JhbABagwWEIIVdtmKBJRZ0giQBAQEEI1UBEAsYCRYEBwICCQMCAQIBRQYNAQUCAQGIDKMiimuPDIFJB4JogSwDl2WRVoFhgT06gS4HFwY
X-IronPort-AV: E=Sophos; i="4.89,927,1367971200"; d="scan'208,217"; a="16880473"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 21 Aug 2013 10:26:54 +0000
Received: from ams3-vpn-dhcp4704.cisco.com (ams3-vpn-dhcp4704.cisco.com [10.61.82.95]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7LAQqR2022845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 10:26:52 GMT
Message-ID: <521495EB.7060207@cisco.com>
Date: Wed, 21 Aug 2013 12:26:51 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Patrik Fältström <paf@frobbit.se>
Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
References: <20130819150521.GB21088@besserwisser.org> <20130819160549.61542.qmail@joyce.lan> <20130819190533.GA30516@besserwisser.org> <4751241.GTNxysAlzm@scott-latitude-e6320> <B443E973-858A-4958-964B-B0F0FBDF5A7A@virtualized.org> <CAMm+LwhcHOeUv0iqZmZ6wX-jOD1r-mRR0x8sbxaKrsU3k4CNBQ@mail.gmail.com> <20130821040003.GL607@mx1.yitter.info> <64700EE4-85B3-4179-904A-885770C6BBF4@virtualized.org> <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se>
In-Reply-To: <7F8D4DA5-F80B-432B-8231-5B40ADB61783@frobbit.se>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------070402010809020806060909"
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 10:27:13 -0000

Patrik,

First, I appreciate that you and Dave are bringing data to the table. 
However, in this case, it is not in dispute that queries are happening. 
What *is* in dispute is whether there are answers.  I must admit I am
having a difficult time understanding the logic, even so.  The *hard*
part about this was supposed to be implementation of the record in the
application software.  Can the shepherd answer this question:

  * To what extent has that happened?

The easy part was supposed to be people actually using the SPF record,
once it was out there.  And so your data doesn't indicate what sort of
answers you're getting.

And another thing. Randy, is it your position that WGs shouldn't create
new TXT records due to transition issues?

Eliot


On 8/21/13 12:15 PM, Patrik Fältström wrote:
> On 21 aug 2013, at 09:17, David Conrad <drc@virtualized.org> wrote:
>
>> On Aug 20, 2013, at 9:00 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>>> The WG had a hard time coming up with really good data about what validators look for, ... If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt.
>> Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack:
> :
> :
> :
>> totals: spf: 1389, txt: 19435, 7.146900%
>>
>> (the numbers are queries since the name server last restarted/dumped stats)
>>
>> Will look for better data than my measly little name server.
> I have been looking at the queries to one of the nameservers that Frobbit runs (which is authoritative for quite a number of zones, although not GoDaddy), and a tcpdump for a while today gives the following data:
>
> $ /usr/sbin/tcpdump -nr dns.pcap | grep 'SPF?' | wc -l
> reading from file dns.pcap, link-type EN10MB (Ethernet)
> tcpdump: pcap_loop: truncated dump file; tried to read 271 captured bytes, only got 95
> 1105
> $ /usr/sbin/tcpdump -nr dns.pcap | grep 'TXT?' | wc -l
> reading from file dns.pcap, link-type EN10MB (Ethernet)
> tcpdump: pcap_loop: truncated dump file; tried to read 94 captured bytes, only got 18
> 2819
>
> I.e. 2819 queries for TXT while there was 1105 for SPF resource record.
>
> Now, I have no idea whether all of those queries for TXT was only for the SPF usage of TXT of course, but this gives it was at least 28% of (TXT+SPF)-queries that was for SPF.
>
> Deprecating something that is in use that much just does not make any sense.
>
>    Patrik
>