[dnsext] SPF, a cautionary tale

"John Levine" <johnl@taugh.com> Fri, 03 May 2013 17:37 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D228121F86AE for <dnsext@ietfa.amsl.com>; Fri, 3 May 2013 10:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.6
X-Spam-Level:
X-Spam-Status: No, score=-108.6 tagged_above=-999 required=5 tests=[HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 qs6+9BhzILnP for <dnsext@ietfa.amsl.com>; Fri, 3 May 2013 10:37:17 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BD5ED21F8BDE for <dnsext@ietf.org>; Fri, 3 May 2013 10:19:14 -0700 (PDT)
Received: (qmail 20512 invoked from network); 3 May 2013 17:19:07 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 May 2013 17:19:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5183f18b.xn--3zv.k1305; i=johnl@user.iecc.com; bh=AZ0cNOx9jrOgtm2bDHabDRDvtaRQ93aHLICOj8gt/fU=; b=RROdjn/YGIUv+wRSM6sGbe5GLHpMwXrlSLG+xbUz1xm7RZLLDAHH6kBrdCaP/V9tJGd5MBV6P2YTlkWrwZVc3Vjx2+JybjUA83yapcBdMpebno94lq3PxH8a4pkwSgD2pRtiKdFLLqxDnLfLWwELtxbA8+dLuHrWcOJjibk1bpQ=
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5183f18b.xn--3zv.k1305; olt=johnl@user.iecc.com; bh=AZ0cNOx9jrOgtm2bDHabDRDvtaRQ93aHLICOj8gt/fU=; b=SOg+2Yy7P0WCKvS8NzhYNg53RpOXmI4zOI+sObRezIKTEyzdVkG9b76QHGPldbFWt+nhTQfZDir8txsf4u6ju4NLvbWnghrTujRnFaa+DSEGB2v7byPFgHC+0rqmcb3GlZ44WrYVkLmpUKgaLPs9n11m9FEczLNTgoGy1O51avk=
Date: Fri, 03 May 2013 17:18:43 -0000
Message-ID: <20130503171843.39672.qmail@joyce.lan>
From: John Levine <johnl@taugh.com>
To: dnsext@ietf.org
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Cc: Ted.Lemon@nominum.com
Subject: [dnsext] SPF, a cautionary tale
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2013 17:37:22 -0000

> However, the point has been made with respect to SPF
>that it would have been better had it not been just a text record.

Uh, no.  SPF (the protocol) is overcomplex, with much of the
complexity ending up in the DNS records.  Decoding SPF records uses a
fairly complex parser; storing a tokenized version wouldn't help and
would probably be bulkier.

A decade ago there were a bunch of designated sender schemes kicking
around of which SPF was by far the most complicated and kludgy, but
it's the one that survived?  Why?  Partly it's because the proponents
of SPF were much better at PR than the rest of us, but mostly it's
because they correctly recognized that publishing the sender policies
in the DNS was the most difficult step, so SPF made it really easy to
do, even at the cost of making the rest of SPF much messier.  You go
to the SPF web wizard, check a few boxes to decribe your sending
setup, and it gives you a TXT record you can paste into your DNS and
you're done.  If stuff changes, e.g., the address of a mail host, or
the set of hosts your ISP uses, it's not your problem, your own SPF
record doesn't have to change.

SPF requires that mail recipients interpret a complex and fragile
description language to come up with a set of IP addresses for each
incoming message.  The other approaches had the sender publish the
addresses directly, rather than a rule for finding them.  But that
meant that senders had to do the equivalent work before publishing the
IPs, and had to update their DNS when the set changed.  That was and
is too hard for the small senders who are the bulk of sending domains
if not the bulk of mail, so SPF won.  (Don't argue, I'm describing the
actual history.)

SPF requires a ridiculous amount of work by recipients.  The source
for libspf2 is about 17,000 lines of code, and interpreting SPF
records requires more DNS queries than any other DNS application I
know.  But all this is to work around the chokepoint of publishing DNS
records, since everything else, looking them up, and calling libraries
from mail servers, is vastly easier.

Phill is right that 4408 added the type 99 record at the last minute
since it was otherwise blocked by the DNS theorists.  Nobody I know
ever thought there was a realistic chance of existing SPF users
switching.  There is a protocol bug in 4408 due to the last minute
insertion of type 99.  Apparently none of the type 99 enthusiasts
cared enough to review the changed spec and notice the bug, but of
course in the long run it didn't matter.

I agree that it's certainly somewhat easier to get an RRTYPE than it
was a decade ago, so long as you understand that you just ignore all
the nitpickery, but reasonable people still avoid doing so because
using a prefixed TXT or other existing type is so much easier.  It's
not just because they're all stupid.

R's,
John