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

From: Stuart Gathman <[email-masked]>
Date: Sun, 1 May 2016 21:24:24 -0400

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.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 01 May 2016 22:33:06 -0400

On Sunday, May 01, 2016 09:24:24 PM Stuart Gathman 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.

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

---

From: "Stuart D. Gathman" <[email-masked]>
Date: Sun, 1 May 2016 22:43:33 -0400 (EDT)

Implementations will *always* lookup only one of A/AAAA - the type
matching the connect IP.  So taking your second option would mean that
A,MX mechanisms would never be void!

-- 
 	      Stuart D. Gathman <[email-masked]>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 01 May 2016 22:55:35 -0400

While I believe your assessment of the type of records that do this is correct 
(mx would have been next on my list to deprecate after ptr if I thought we 
could have pulled it off), I think it's only technically correct to count an mx 
as void if you've checked both (and that's what RFC 7208 already says).

We may want to make that clearer, but changing it so that only A or AAAA 
missing counts as void would be a technical change that has interoperability 
risks.  I don't think we should do it.

Scott K

On Sunday, May 01, 2016 10:43:33 PM Stuart D. Gathman wrote:
> > 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.

---

From: <[email-masked]>
Date: Sun, 1 May 2016 22:31:46 -0500

If I connect over IPv6 and the SPF record has 'mx' in it, that should not
result in failure just because there are no AAAA's for any of the MX
records.  Just because a domain has valid IPv6 senders that does not mean it
can accept email over IPv6.  Or that one can only use SPF if IP address
versions for sender and receiver are in the same family.  Sending IPv6
connectivity should not dictate that any of the MX records have an AAAA, and
Sending IPv4 connectivity should not dictate that any of the MX records have
an A.  Doing so is requiring more than what SPF means to accomplish.

I don't know if I'm saying it right, but I'd like to see it clarified that
when an 'mx' is evaluated that failure to obtain an A or AAAA should not
impact the void lookup count.  If that's unacceptable, then perhaps mx
should be deprecated, or it should be augmented with mx4 or mx6 to avoid
void lookup counts.

Frank

-----Original Message-----
From: spfbis [mailto:[email-masked]] On Behalf Of Stuart D. Gathman
Sent: Sunday, May 01, 2016 9:44 PM
To: Scott Kitterman <[email-masked]>
Cc: [email-masked]
Subject: Re: [spfbis] Question about SPF checks based on RFC 7208

> I think it might make sense that to clarify that an mx mechanism is only
void

_______________________________________________
spfbis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spfbis

---

From: S Moonesamy <[email-masked]>
Date: Mon, 02 May 2016 00:58:55 -0700

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

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

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 2 May 2016 08:56:17 -0700

On Mon, May 2, 2016 at 12:58 AM, S Moonesamy <[email-masked]> wrote:

>> . . . tries to work through the MX records of premieronline.net, but for
> 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.
>
> . . . does RFC 7208 need some clarification on this matter?  My guess
>>
> 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.
>

My suggestion is to clarify exactly what constitutes a "void DNS lookup" in
the case of an MX mechanism. I suggest that we define a void MX lookup to
be one that either returns no records or returns the "null MX record"
(RFC7505). Could this be done as an erratum item?

I think we also need to highlight the importance of putting "lookup
dependent mechanisms", and especially 2nd degree dependent mechanisms (such
as mx) *after* any explicit IP specifications to publishers of SPF records.
The "traditional"/historical suggestion that has been provided by many
record creation "wizards" is flawed by putting "a mx" at the beginning of
their recommendations.

--Kurt Andersen

---

From: S Moonesamy <[email-masked]>
Date: Mon, 02 May 2016 09:48:00 -0700

Hi Kurt,
At 08:56 02-05-2016, Kurt Andersen wrote:
>My suggestion is to clarify exactly what constitutes a "void DNS 
>lookup" in the case of an MX mechanism. I suggest that we define a 
>void MX lookup to be one that either returns no records or returns 
>the "null MX record" (RFC7505). Could this be done as an erratum item?

Please see https://www.rfc-editor.org/errata.php for information 
about how to report an erratum and how the erratum will be 
processed.  The above might be too much for an erratum.

>dependent mechanisms", and especially 2nd degree dependent 
>mechanisms (such as mx) after any explicit IP specifications to 
>publishers of SPF records. The "traditional"/historical suggestion 
>that has been provided by many record creation "wizards" is flawed 
>by putting "a mx" at the beginning of their recommendations.

There is the following in Section 4.6.4:

   "SPF implementations SHOULD limit "void lookups" to two.  An
    implementation MAY choose to make such a limit configurable.
    In this case, a default of two is RECOMMENDED.  Exceeding
    the limit produces a "permerror" result."

The following is from Section 11.1:

   'Operational experience since the publication of [RFC4408]
    suggests that mitigation of this class of attack can be
    accomplished with minimal impact on the deployed base by
    having the verifier abort processing and return "permerror"
    (Section 2.6.7) as soon as more than two "void lookups" have
    been encountered (defined in Section 4.6.4).'

In my personal opinion any text change would not be a 
clarification.   Which section of RFC 7208 would you like to change? :-)

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 May 2016 22:16:09 -0700

On Mon, May 2, 2016 at 9:48 AM, S Moonesamy <[email-masked]> wrote:

> My suggestion is to clarify exactly what constitutes a "void DNS lookup"
>> in the case of an MX mechanism. I suggest that we define a void MX lookup
>> to be one that either returns no records or returns the "null MX record"
> Please see https://www.rfc-editor.org/errata.php for information about
> how to report an erratum and how the erratum will be processed.  The above
> might be too much for an erratum.

I guess we used the term in the lists but the definition never made it into
the document.  Damn.

Anyway, I support logging an erratum for this if that's the main issue.
Who knows if and when there will be enough energy and interest to do an
update.

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 4 May 2016 08:37:33 -0700

On Tue, May 3, 2016 at 10:16 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> I guess we used the term in the lists but the definition never made it
> into the document.  Damn.
>

I'll have to go back and research the usage of the term in the spfbis
mailing lists. I'll follow up with a note here once I have a proposal with
concrete wording.

--Kurt

---

From: Stuart Gathman <[email-masked]>
Date: Wed, 4 May 2016 11:54:15 -0400

> I guess we used the term in the lists but the definition never made it
Kind of like "Natural Born Citizen".

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 May 2016 16:57:32 -0400

> mailing lists. I'll follow up with a note here once I have a proposal with

SPFbis picked this up from Mail::SPF under the charter terms that allowed 
"addition of any enhancements that have already gained widespread support" 
[1], so the relevant section of the Mail::SPF documentation [2] may also be a 
useful source of information.

Scott K

[1] https://datatracker.ietf.org/wg/spfbis/charter/
[2] https://metacpan.org/pod/Mail::SPF::Server