Re: [Asrg] misconception in SPF

"Bill Cole" <asrg3@billmail.scconsult.com> Fri, 07 December 2012 22:07 UTC

Return-Path: <asrg3@billmail.scconsult.com>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A333221F86E2 for <asrg@ietfa.amsl.com>; Fri, 7 Dec 2012 14:07:35 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYHRW+8xwe14 for <asrg@ietfa.amsl.com>; Fri, 7 Dec 2012 14:07:35 -0800 (PST)
Received: from toaster.scconsult.com (client.scconsult.com [66.73.230.190]) by ietfa.amsl.com (Postfix) with ESMTP id 2F61121F8701 for <asrg@irtf.org>; Fri, 7 Dec 2012 14:07:34 -0800 (PST)
Received: from [192.168.254.21] (deepfield.scconsult.com [192.168.254.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTPSA id 3YJ78L216bzrX81 for <asrg@irtf.org>; Fri, 7 Dec 2012 17:07:30 -0500 (EST)
From: Bill Cole <asrg3@billmail.scconsult.com>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Date: Fri, 07 Dec 2012 17:07:24 -0500
Message-ID: <E1041B16-4AD9-4CE0-9383-C90A7023F41F@billmail.scconsult.com>
In-Reply-To: <20121206212116.10328.qmail@joyce.lan>
References: <20121206212116.10328.qmail@joyce.lan>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.5r3119)
Subject: Re: [Asrg] misconception in SPF
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2012 22:07:35 -0000

On 6 Dec 2012, at 16:21, John Levine wrote:

> In article 
> <CAFduganiaDkf0jFsV7FYcAvi9JjA9G-iTj8XLVzcDNY=jo_m=w@mail.gmail.com> 
> you write:
>> here is the proof of concept ! an email sent to John Levine claiming
>> to be from ygii-john@www.johnlevine.com !!!
>
> Life is too short to publish SPF -all records for every host name that
> doesn't send mail.

Well, not really. It's not 1999: no one competent and sane manages zones 
of non-trivial size or significance by editing canonical-format zone 
files in a 24x80 text editor. As a matter of standard practice, many 
domains have long been managed with an awareness that the MX/A issue 
creates problems which are mitigated by never creating an A record 
without also creating an MX, with non-mailing hosts getting MX records 
that are easily detected as a declaration of that status. This is useful 
because there are spam exclusion tactics which detect such declarations 
and so reject spoofed addresses. It is a simple matter with many (most?) 
modern MTA's to reject mail in SMTP before DATA if the sender domain has 
a bogus MX record. The cleanest form of bogosity is the "nullmx" 
approach proposed and used by Yahoo, but it is also useful for receivers 
to detect MX records pointing to names without A records or with A 
records pointing to  unusable addresses (i.e. permanently reserved 
and/or otherwise special address ranges.) If a domain owner is already 
publishing SPF for mailing names (where it can be problematic) and 
already publishing anti-functional MX records, they should have no 
problem with publishing SPF records as well for their non-mailing names. 
There is a nuisance cost in doing this sort of thing for mid-sized 
domains which have long been able to function managing their DNS in ad 
hoc ways, but that condition is pretty much doomed anyway by IPv6 and 
DNSSEC. We all are destined for needing to think more and more carefully 
about DNS.

I should add that I don't think this issue is significant in the big 
picture of spam control and it certainly isn't news with respect to SPF. 
The days of hope for SPF as the FUSSP are long gone. Even with DMARC we 
will never have a world where SPF plays a primary role in sender 
authentication and repudiation. SPF has a few narrow applications where 
it is very useful, but anyone hoping for it to be the fix for all sender 
spoofing ought to have been disillusioned by real world experience some 
years ago.