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

From: "Frank Bulk" <[email-masked]>
Date: Sat, 30 Apr 2016 19:45:40 -0500

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
	[email-masked]

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.)."

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?

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.

Frank

5.4.  "mx"

   This mechanism matches if <ip> is one of the MX hosts for a domain
   name.

   mx               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]

   check_host() first performs an MX lookup on the <target-name>.  Then
   it performs an address lookup on each MX name returned.  The <ip> is
   compared to each returned IP address.  To prevent denial-of-service
   (DoS) attacks, the processing limits defined in Section 4.6.4 MUST be
   followed.  If the MX lookup limit is exceeded, then "permerror" is
   returned and the evaluation is terminated.  If any address matches,
   the mechanism matches.

   Note regarding implicit MXes: If the <target-name> has no MX record,
   check_host() MUST NOT apply the implicit MX rules of [RFC5321] by
   querying for an A or AAAA record for the same name.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 30 Apr 2016 21:08:50 -0400

>   querying for an A or AAAA record for the same name.

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.

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 30 Apr 2016 21:14:37 -0700

On Sat, Apr 30, 2016 at 6:08 PM, Scott Kitterman <[email-masked]> 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.
>
> Scott K

Scott, your own analysis tool also has a problem with the scenario that was
described as do several others that I checked. When the connection is
coming in on an IPv6 connection, it seems that only AAAA records are being
sought in the resolution of the MX records into IP addresses. When the
first two that are checked result in no AAAA found, it is more or less
game-over according to the 7208 spec. This seems like a lurking time-bomb
in SPF as people begin sending mail on IPv6, potentially before they enable
inbound connections on IPv6.

--Kurt Andersen