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

Stuart Gathman <> Mon, 02 May 2016 01:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDFA812B042 for <>; Sun, 1 May 2016 18:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, 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 fNYaTfiAWVFW for <>; Sun, 1 May 2016 18:24:32 -0700 (PDT)
Received: from ( [IPv6:2001:470:5:c85::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73A5412B015 for <>; Sun, 1 May 2016 18:24:32 -0700 (PDT)
Authentication-Results:; iprev=pass policy.iprev="2001:470:8:809:11::1009" (; auth=pass (PLAIN sslbits=128) smtp.auth=stuart
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=default; t=1462152269; h=Subject : To : References : From : Message-ID : Date : MIME-Version : In-Reply-To : Content-Type : Content-Transfer-Encoding : Subject : From : Date; bh=QK4GXjkPadYUzd+/1YdJqHE1etlEgjgCJNLwgN1nkEY=; b=dejWDilQtewMcctAXxH2nFHMBvIRVux9JTP6hj4sxPT3WAp5Cpz1sSXCHj4Kd4iv+lS8xO 1x+q2hepHo40TaMNq8MDQZQhWfMwhqwIdY88yXWuKARHTvXVI/obcoUosB4b5n3k805kcNhC +lVEOWHQH9e2TOujaGYtSFFIrD7AI=
Received: from ( [IPv6:2001:470:8:809:11::1009]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id u421ON12031462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <>; Sun, 1 May 2016 21:24:29 -0400
References: <002101d1a342$c93e3000$5bba9000$> <>
From: Stuart Gathman <>
Organization: Gathman Systems
Message-ID: <>
Date: Sun, 1 May 2016 21:24:24 -0400
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
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:23:34 -0000

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.