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

Douglas Otis <doug.mtview@gmail.com> Tue, 10 September 2013 21:45 UTC

Return-Path: <doug.mtview@gmail.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 E2B1111E8128 for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2013 14:45:51 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Hiq0gAN6B4bN for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2013 14:45:51 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9229511E80E9 for <ietf@ietf.org>; Tue, 10 Sep 2013 14:45:50 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id lb1so8302135pab.26 for <ietf@ietf.org>; Tue, 10 Sep 2013 14:45:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3iViEybKt1S444r0gQAsas8m02y23s2TgiOfGZMZKrE=; b=MJstw2mD2+1jfxJgk7o9r3CdD6Zsc7W8naeDRtrIYd3Rr3pkMJ+i+Vti/Q3r8qjhEf h09XRVe9chV4wJSLBeKYjhwGNAShzThcGN+qNFZbHD9lOjtvdnoi1QK9VDFbPhuUfd5K 8y7YtmicZHVwGBKksNFa/62r1jXG6d9XMXPC9eKPZC6+eEu/ZMdoD8mAv6qE5VOFWzDS tBphKXJcjtyG8RczlqWB7I5/brYFUovbe0gvXCad+ZzrRbQPs22luWIMk75WmqqOYYVo ddoEf0B0poyWpYYZVrXjVMa0kb0zyEt1lJys6AvSaLAaN6eM9ae5Ty1/1iy9NyOpPYOL Zxlw==
X-Received: by 10.68.232.74 with SMTP id tm10mr27918867pbc.64.1378849550367; Tue, 10 Sep 2013 14:45:50 -0700 (PDT)
Received: from [192.168.2.201] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id pu5sm27064701pac.21.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 14:45:48 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CB9AAC40-9BFA-4E4D-91EE-73DAC4FAD3DD"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <CAMm+Lwid2jpsxZQ2Lw1nVy88DGdugWxcXdDfdu2a5Jd9_7WCmQ@mail.gmail.com>
Date: Tue, 10 Sep 2013 14:45:46 -0700
Message-Id: <8707E1CE-AA14-4AD1-BEEC-5E16251D37CC@gmail.com>
References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <Pine.SGI.4.61.1308291142180.193807@shell01.TheWorld.com> <CAMm+Lwid2jpsxZQ2Lw1nVy88DGdugWxcXdDfdu2a5Jd9_7WCmQ@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: IETF Discussion Mailing List <ietf@ietf.org>, Dan Schlitt <schlitt@theworld.com>
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: Tue, 10 Sep 2013 21:45:52 -0000

On Sep 2, 2013, at 5:54 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt <schlitt@theworld.com> wrote:
> As the manager of a modestly large network I found the TXT record as a useful tool in management of the network. Such a use was even suggested by other system managers. That was a time when the Internet was a friendlier place. Today I might do things differently and not make some of the TXT records visible on the public Internet. But they would still be useful for internal management.
> 
> TXT records can be useful for ad-hoc local configs and the SPF use has made this harder. But it is hard to see how the SPF record makes that situation any better.
> 
> 
> Probably a better solution would be to take a chunk of the reserved RR code space and stipulate that these have TXT form records so folk have 10,16 or so records for this use.
> 
> In the longer term, the problem with the SPF RR is that it is a point solution to 'fix' only one protocol. It is an MX record equivalent. Which was OK given the circumstances when it was developed.
> 
> 
> A shift from TXT to SPF records is not likely to happen for the niche SPF spec. But may well be practical for a wider client/initiator policy spec.

Dear Phillip,

It seems many of the larger providers are unwilling to process SPF macros due to inherent risks and inefficiency.  Rather than accessing data using the DNS resource selectors of Name, Type, and Class, SPF uses mechanisms above DNS to utilize an additional domain, IP address, and email address input parameters merged with results generated from a series of proscribed DNS transactions.  The macro feature was envisioned as leveraging these additional inputs to influence query construction. It seems lack of support by large providers has ensured scant few macros are published.

in the beginning, there were several wanting a macro language to  managing DNS processing with little idea where this would be headed.  At the time there was already a dedicated binary resource record able to fully satisfied the information now obtained and used from SPF.  Policy aspects of SPF are largely ignored due to exceptions often required.   An SRV resource record resolving the location of a service could include an APL RR with CIDR information of all outbound IP addresses.  This would offer load balancing and system priorities, while mapping outbound address space within two DNS transactions instead of the 111 recursive transactions expected by SPF.  If one were starting over, DANE TLS or DTLS is a better solution that should be even easier to administer since it avoids a need to trust IP addresses and NATs.   As with PKI, there are too many actors influencing routing's integrity.

Regards,
Douglas Otis