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

Scott Kitterman <scott@kitterman.com> Wed, 21 August 2013 17:03 UTC

Return-Path: <scott@kitterman.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 4BABB11E8234 for <ietf@ietfa.amsl.com>; Wed, 21 Aug 2013 10:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5OFgwqsVWUI for <ietf@ietfa.amsl.com>; Wed, 21 Aug 2013 10:03:15 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CEA7011E8261 for <ietf@ietf.org>; Wed, 21 Aug 2013 10:02:42 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9625F20E40FD; Wed, 21 Aug 2013 13:02:34 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377104554; bh=GcWrSpVK6erHJw9dpjBsB//k6ggIbktwXjh5P1XscM0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jDJwYrYOwhudPbJwO32hP4JWuVAE52iObz7XnB2K27FWTNMaBPxB9d4WB9/Ef+4Gn vwwxrLICLZYRmX/asFhFIuavlsdqdPm9o7RjwTGg5jixDcDGKC8MgB+huKdoruLi/C p/DjfPDJPCtzoSbCTYbrimzvT8owmItcXycvmTRI=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7FCC520E40C2; Wed, 21 Aug 2013 13:02:34 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: ietf@ietf.org
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
Date: Wed, 21 Aug 2013 13:02:33 -0400
Message-ID: <7917527.VmCQD3a6Q3@scott-latitude-e6320>
User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; )
In-Reply-To: <20130821133233.D0A6B38BE02F@drugs.dv.isc.org>
References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <13637683.gDTVOaM8nE@scott-latitude-e6320> <20130821133233.D0A6B38BE02F@drugs.dv.isc.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
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 17:03:20 -0000

On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
> I object to the removal of the SPF record.

This is not a shock.  You were in the rough when we discussed it in the WG 
too.

> Name servers already have access controls down to the granuality
> of TYPE.  If this draft proceeds as currently described it is forcing
> name server vendors to access controls at the sub TYPE granuality.

It's primarily an issue for applications.  To the DNS, it's exactly what it 
is, a TXT record.

> With SPF lookup first I can specify the SPF policy using SPF and
> leave TXT free for other uses without having to worry about the
> records being misinterpeted.

Unless you have some specific reason to be concerned about accidentally 
starting an unrelated TXT record with "v=spf1 ", I can't imagine you don't 
have more important things to worry about.  This being a "problem" is a great 
theory, but it just doesn't happen in practice.

> SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF.
> This is similar to not proceeding to A/AAAA lookups on MX lookup
> failures.

Except that it's quite common for a SERVFAIL on TYPESPF to occur for a domain 
that has an actual SPF record due to various operational issues.  SERVFAIL on 
type SPF doesn't reliably tell you anything about what a type TXT lookup would 
produce.  So it's similar, but only superficially so.

> I would also suggest that there be a sunset date published for the
> use of TXT for SPF.

Do you also suggest creation of an Internet police force to enforce this?  
What would be be mandatory minimum sentence?

Scott K