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

Scott Kitterman <> Mon, 02 May 2016 02:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1B1012B018 for <>; Sun, 1 May 2016 19:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AjU-sMbcEIVC for <>; Sun, 1 May 2016 19:33:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D8BC12B014 for <>; Sun, 1 May 2016 19:33:09 -0700 (PDT)
Received: from kitterma-e6430.localnet ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A3141C40152 for <>; Sun, 1 May 2016 21:33:07 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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 <>
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: <>
References: <002101d1a342$c93e3000$5bba9000$> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [spfbis] Question about SPF checks based on RFC 7208
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SPFbis discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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