Overloaded TXT harmful (was" 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)

John C Klensin <john-ietf@jck.com> Tue, 27 August 2013 06:21 UTC

Return-Path: <john-ietf@jck.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 0CB8F11E8125 for <ietf@ietfa.amsl.com>; Mon, 26 Aug 2013 23:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.537
X-Spam-Level:
X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, 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 w0+PTItFvQgG for <ietf@ietfa.amsl.com>; Mon, 26 Aug 2013 23:21:25 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 313AB11E813A for <ietf@ietf.org>; Mon, 26 Aug 2013 23:21:25 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VECeU-000CqD-3T; Tue, 27 Aug 2013 02:21:18 -0400
Date: Tue, 27 Aug 2013 02:21:13 -0400
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>, Jelte Jansen <jelte.jansen@sidn.nl>
Subject: Overloaded TXT harmful (was" 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)
Message-ID: <E30070F220FC128EEF0A59CA@JcK-HP8200.jck.com>
In-Reply-To: <alpine.BSF.2.00.1308261046100.76616@joyce.lan>
References: <20130823143402.49936.qmail@joyce.lan> <521B165C.9000809@sidn.nl> <alpine.BSF.2.00.1308261005360.76238@joyce.lan> <521B69AD.5020108@sidn.nl> <alpine.BSF.2.00.1308261046100.76616@joyce.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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: Tue, 27 Aug 2013 06:21:31 -0000

--On Monday, August 26, 2013 10:49 -0400 John R Levine
<johnl@taugh.com> wrote:

> Sorry if that last one came across as dismissive.
> 
>> Until such time, I'd personally prefer to see some explicit
>> notion that the odd history of the SPF TXT record should not
>> be seen as a precedent and best practice, rather than hope
>> that this is implicit.
> 
> I'd have thought that the debate here and elsewhere already
> documented that.  Since it's not specific to SPF, perhaps we
> could do a draft on "overloaded TXT considered harmful" to get
> it into the RFC record.

With the help of a few others, I've got a I-D in the pipe whose
function is to create an IANA registry of structured protocol
uses for TXT RR data and how to recognize them.  I hope it will
be posted later this week.  Its purpose is to lower the odds of
"overloaded" sliding into "different uses for forms that are not
easily distinguished".  Other than inspiration, its only
relationship to the current SPF discussion is that some
SPF-related information is a candidate for registration (whether
as an active use or as a deprecated one).

It already contains some text that warns that overloading TXT is
a bad idea but that, because it happens and has happened,
identifying those uses is appropriate.  Once it is posted, I/we
would appreciate any discussion that would lead to consensus
about just how strong that warning should be and how it should
be stated.

best,
   john