IETF Logo Mail Archive

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

Stuart Gathman <stuart@gathman.org> Mon, 02 May 2016 01:24 UTC

Return-Path: <SRS0=fNnQE=Q3==stuart@gathman.org>
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 BDFA812B042 for <spfbis@ietfa.amsl.com>; Sun, 1 May 2016 18:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gathman.org
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 fNYaTfiAWVFW for <spfbis@ietfa.amsl.com>; Sun, 1 May 2016 18:24:32 -0700 (PDT)
Received: from mail.gathman.org (mail.gathman.org [IPv6:2001:470:5:c85::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A5412B015 for <spfbis@ietf.org>; Sun, 1 May 2016 18:24:32 -0700 (PDT)
Authentication-Results: mail.gathman.org; iprev=pass policy.iprev="2001:470:8:809:11::1009" (elissa.gathman.org); auth=pass (PLAIN sslbits=128) smtp.auth=stuart
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; 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 elissa.gathman.org (elissa.gathman.org [IPv6:2001:470:8:809:11::1009]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id u421ON12031462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <spfbis@ietf.org>; Sun, 1 May 2016 21:24:29 -0400
To: spfbis@ietf.org
References: <002101d1a342$c93e3000$5bba9000$@iname.com> <255DF248-2870-4727-9F10-259598592509@kitterman.com>
From: Stuart Gathman <stuart@gathman.org>
Organization: Gathman Systems
Jabber-Id: stuart@gathman.org
Message-ID: <5726AC48.7090306@gathman.org>
Date: Sun, 01 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: <255DF248-2870-4727-9F10-259598592509@kitterman.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/uK5F5eO_LKMbCGWiz6pP8QgH0cc>
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: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.

v2.23.0 | Report a Bug | By Email