Re: [spfbis] Question about SPF checks based on RFC 7208

Scott Kitterman <spf2@kitterman.com> Mon, 02 May 2016 02:33 UTC

Return-Path: <spf2@kitterman.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B1012B018 for <spfbis@ietfa.amsl.com>; Sun, 1 May 2016 19:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjU-sMbcEIVC for <spfbis@ietfa.amsl.com>; Sun, 1 May 2016 19:33:09 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8BC12B014 for <spfbis@ietf.org>; Sun, 1 May 2016 19:33:09 -0700 (PDT)
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A3141C40152 for <spfbis@ietf.org>; Sun, 1 May 2016 21:33:07 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1462156387; bh=D0+Xxrs5sVv9U95S5uq0/ATJDu0kYL77JrjOsOMldqc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Yz0P/a6XACA3VVpOqYVzLW8qqpcR4PevVXiKF93inlWxC0BgiEFN4/4aYli8O7pEX yOkteL+LZQhJ9OrQFWApyyMAMBTKSMsc13MkQSfOVj63IW2fdGRnjiDIopdWPo5lNf zb7ufcG1v5xoiahAykk9rI9UvdOSWosNF1CHRG2w=
From: Scott Kitterman <spf2@kitterman.com>
To: spfbis@ietf.org
Date: Sun, 01 May 2016 22:33:06 -0400
Message-ID: <5060996.Nvmh582kyi@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <5726AC48.7090306@gathman.org>
References: <002101d1a342$c93e3000$5bba9000$@iname.com> <255DF248-2870-4727-9F10-259598592509@kitterman.com> <5726AC48.7090306@gathman.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/EA0nx4TzTzn3_YrGCpxOrdFB0A4>
Subject: Re: [spfbis] Question about SPF checks based on RFC 7208
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2016 02:33:11 -0000

On Sunday, May 01, 2016 09:24:24 PM Stuart Gathman wrote:
> On 04/30/2016 09:08 PM, Scott Kitterman wrote:
> > I think they are just wrong.  If either an IPv4 or IPv6 address is
> > returned it's not a void look up.  That's described at the end of 4.6.4
> > and is, I think clear.  I'd report it as a bug.
> If the connection is an IPv6 connection, then only AAAA RRs are queried
> (because an A RR could never match).  If the domain has only A RRs, then
> the AAAA queries will have empty results.   This seems to be
> indistinguishable from a non-existent domain.  This is the problem the
> OP is complaining about.
> 
> This means that pyspf, on detecting 2 "void" lookups for an AAAA, would
> then have to make at least 2 additional useless queries for the A record
> type to see if the lookups were actually "void" according to your
> interpretation.  Since I think your interpretation is somewhat
> reasonable, this *could* be an errata.
> 
> But I don't think so.  This is actually a case of "doctor, doctor, it
> hurts when I do this!"  Don't use an mx mechanism with A only names when
> valid connections can come in via IPv6.   Or at least, make it the
> *last* mechanism as recommended.  I can't think of any good reason to
> tweak or "clarify" the spec to enable this kind of SPF record.

I think it might make sense that to clarify that an mx mechanism is only void 
if neither A nor AAAA exist.  Implementations could either do the extra lookup 
or just not count it as void if only looking up one.  From an interoperability 
perspective, I think either would be fine.

Scott K