IETF Logo Mail Archive

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> Thu, 22 August 2013 03:20 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 38AF411E818C for <ietf@ietfa.amsl.com>; Wed, 21 Aug 2013 20:20: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 AbgWnPlcTsdO for <ietf@ietfa.amsl.com>; Wed, 21 Aug 2013 20:20:30 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C4BA711E8179 for <ietf@ietf.org>; Wed, 21 Aug 2013 20:20:30 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AD8FE20E40FD; Wed, 21 Aug 2013 23:20:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377141628; bh=rl4vRDm+wMLK5AUcYfxXMW6x0HWK8k0BNm+ulYZvH2Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=J+VAdFX2/QLKrOgm5dRn4d4yiapVXXOWjwOQwvZCL9nfjD10RTFbRDt0n21ZYZndY 2p+JiY7AkzoCPiJ8MKNInvH+S2fBlm3A8IX6+a0jQpkUcLq+RyhB7aQ98vNrnplomi HlwPW26U16v4jvq/vh3UKb8tyK9D3GDj7fkN8ebI=
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 959CC20E40C2; Wed, 21 Aug 2013 23:20:28 -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 23:20:25 -0400
Message-ID: <1810406.ESMbiX16Oo@scott-latitude-e6320>
User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; )
In-Reply-To: <20130821233103.39C5338C0A87@drugs.dv.isc.org>
References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <0c3746c3-dac1-471f-bd07-8faf20481337@email.android.com> <20130821233103.39C5338C0A87@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: Thu, 22 Aug 2013 03:20:39 -0000

On Thursday, August 22, 2013 09:31:03 Mark Andrews wrote:
> In message <0c3746c3-dac1-471f-bd07-8faf20481337@email.android.com>, Scott 
Kitterman writes:
> > Mark Andrews <marka@isc.org> wrote:
> > >In message <20130821214832.1C92538C0230@drugs.dv.isc.org>, Mark Andrews
> > >
> > >writes:
> > >> > It's primarily an issue for applications.  To the DNS, it's exactly
> > >
> > >what it
> > >
> > >> > is, a TXT record.
> > >
> > >I can hand update of A and AAAA records to the machine.
> > >I can hand update of MX records to the mail adminstrator.
> > >I can hand update of SPF records to the mail adminstrator.
> > >I can hand update of TXT records to ??????
> > 
> > No one because it has multiple uses.  This is true whether SPF exists or
> > not.  SPF use of RRTYPE TXT for SPF records mak es that neither better
> > nor worse.
> > 
> > You could publish:
> > 
> > example.com IN TXT v=spf1 redirect=_spf.example.com
> > _spf.example. com IN TXT v=spf1 [actual content here]
> > 
> > Then delegate _spf.example.com to the mail administrator.  Problem solved.
> 
> No, it is NOT solved.  You have to trust *everyone* with the ability
> to update TXT not to remove / alter that record.  You can't give someone
> you don't trust the ability to update TXT.
> 
> With a published SPF record and SPF lookup first stopping on success
> or lookup failure (SERVFAIL) you can give update control of TXT to
> someone you don't trust enough to not remove / alter the SPF TXT
> record.
> 
> You keep telling us the TXT is just another record in the DNS.  Well
> the DNS is managed at the granuality of the TYPE.  4408bis is forcing
> sub-type management to be developed and deployed to maintain the
> status quo.  TXT is no longer "just another record in the DNS" with
> 4408bis as it currently stands.
> 
> And to Google your motto is "Do No Evil".  Publishing a TXT SPF record
> without publish a SPF SPF record is "Evil" as it encourages other to
> do the same.

Your goal seems to be pretty much the opposite of the task the working group 
was given.  You say so even more clearly here:

http://www.ietf.org/mail-archive/web/spfbis/current/msg03948.html

Unless you come with something new, I think I'm done.

Scott K

v2.23.0 | Report a Bug | By Email