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

S Moonesamy <sm+ietf@elandsys.com> Mon, 02 May 2016 08:01 UTC

Return-Path: <sm@elandsys.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 81AED12D0F5 for <spfbis@ietfa.amsl.com>; Mon, 2 May 2016 01:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.786
X-Spam-Level:
X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=vDcmKLt+; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=yWTSUrMc
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 dhq0ZLizegqD for <spfbis@ietfa.amsl.com>; Mon, 2 May 2016 01:00:57 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C165712D0CF for <spfbis@ietf.org>; Mon, 2 May 2016 01:00:57 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.55.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u4280jMa016884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2016 01:00:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1462176056; x=1462262456; bh=2q+ZeaIiChxzZQbEJJelyaBnZoIvNyjsALjUy4g40BM=; h=Date:To:From:Subject:In-Reply-To:References; b=vDcmKLt+uUpMXKKj7wcYfMw4LcKjS4nlHY85xHAgxKUApqH4Or4B2U+onF4KppOb/ YG88S524LML2vNyucpZptj/hNof/Ev9L+rhd9OUenY54E3nE0WHtNsGe6xnDSPeJFr hNngi/tU6x+gh0NLDyTqH1zN8cXzbQJQ6ORFmgW4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1462176056; x=1462262456; i=@elandsys.com; bh=2q+ZeaIiChxzZQbEJJelyaBnZoIvNyjsALjUy4g40BM=; h=Date:To:From:Subject:In-Reply-To:References; b=yWTSUrMca8yR/AVDZo/hN/e3fhOUIVNiuIrMEYeTm6rwNvCqKh5ULFUvgbZ1td8/S +IHI9wzG0tJkwBMEMmpBzxmZEw1sVNUC2DL+bd8K7SP05spf4zOyyPtvav8VBUPwPo bhGUsmxLt3XKZ+uX7v69xkBGXate//7juKZOPj1A=
Message-Id: <6.2.5.6.2.20160502003646.101fc9c8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 02 May 2016 00:58:55 -0700
To: Frank Bulk <frnkblk@iname.com>, spfbis@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <002101d1a342$c93e3000$5bba9000$@iname.com>
References: <002101d1a342$c93e3000$5bba9000$@iname.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/sMRahTSJkwY7WBy9XTQGCth4mic>
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 08:01:07 -0000

Hi Frank,
At 17:45 30-04-2016, Frank Bulk wrote:
>While working through a SPF failure for a message sent from our IPv6-capable
>email server (for premieronline.net), I ran an across an SPF checker
>(http://vamsoft.com/support/tools/spf-policy-tester) that had a hard fail
>when these values were entered:
>         2607:fe28:0:4000::20
>         fbulk@premieronline.net
>
>premieronline.net's record is as follow:
>         v=spf1 mx ip4:96.31.0.0/24 ip6:2607:fe28:0:1000::/64
>ip6:2607:fe28:0:4000::/64 ~all
>
>The tool tries to work through the MX records of premieronline.net, but for
>some reason it specifically queries for an AAAA for each MX record, of which
>we don't have one (because our inbound email gateway does not yet support
>IPv6).  Since we have four MX records, it work through two of them (which
>both fail) and then the tool hard fails saying that,
>         "The maximum void DNS lookup limit of 2 has been exceeded during the
>evaluation (see RFC7208 Section 4.6.4.)."

There is the following in Section 5 of RFC 7208:

   'When any mechanism fetches host addresses to compare with <ip>, when
    <ip> is an IPv4, "A" records are fetched; when <ip> is an IPv6
    address, "AAAA" records are fetched.  SPF implementations on IPv6
    servers need to handle both "AAAA" and "A" records, for clients on
    IPv4-mapped IPv6 addresses [RFC4291].  IPv4 <ip> addresses are only
    listed in an SPF record using the "ip4" mechanism.'

It does not make sense to query for an "A" record when the client 
address is an IPv6 address.  The issue in your case is that your 
outbound is over IPv6 while you do not have inbound IPv6.  I took a 
quick look and I did not find a discussion about that in relation to 
the void DNS lookup limit in the mailing list archive.

>This is the only SPF tool to fail in this way, which makes we wonder if it's
>the site's SPF checking methodology for RFC 7208 section 5.4 is correct.  If
>so, and other email gateways have implemented their SPF checking in the same
>way, there could be more incorrect SPF evaluation checks out there.  If the
>site's SPF checking methodology is incorrect, can you point me to a section
>in any RFC that would suggest a better/proper approach?

I didn't find any text in the RFC about a better or proper approach.

>Either way, does RFC 7208 need some clarification on this matter?  My guess
>is that "it performs an address lookup on each MX name" is not equivalent to
>"check for an AAAA on each MX name and check for an A on each MX name", but
>I'm not sure.

Your question is about whether there is a "bug" in the technical 
specification.  The second sentence is about how to get around a 
"void DNS lookup".  At the moment I am not sure about what would be 
the appropriate answer.

Regards,
S. Moonesamy