Re: Question about Test Suite

On Tuesday, September 23, 2014 14:03:50 you wrote:
> Hi Everyone,
> 
> I'm in the midst of writing an SPF implementation and toolkit in Ruby.  You
> can find the source code here - https://github.com/petergoldstein/coppertone
> 
> I've implemented a runner for the RFC 7208 OpenSPF test suite as defined
> here - http://www.openspf.org/svn/project/test-suite/ - and I've got all
> but two of the specs passing.  You can find the RSpec version of the test
> suite in the repository referenced above, under the spec/open_spf directory.
> 
> Two of the specs, both related to subdomain resolution in 'p' macro
> expansion are not passing, and I can't figure out why the results specified
> in the suite are correct.  The two specs are p-macro-ip4-valid on line 2110
> and p-macro-ip6-valid on line 2132.
> 
> In both cases, I get the expected 'fail' result, but the p macro does not
> resolve, because the current domain (e6.example.com) is not a subdomain of
> any of the PTR records returned by 41.218.168.192.in-addr.arpa or
> 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.E.B.A.B.E.F.A.C.ip6.arpa
> respectively.
> 
> The only returned PTR record in each case in 'mx.example.com', which is not
> a subdomain of e6.example.com and thus, according to my reading of the
> spec, should not be used.  So my explanation is 'connect from unknown' as
> opposed to the 'connect from mx.example.com'
> 
> Am I misunderstanding the RFC here?  If not, why is this value correct?
> 
> Any help is appreciated.  Thanks.

In the zone data for that test, it has:

  mx.example.com:
    - A: 192.168.218.41
    - A: 192.168.218.42
    - AAAA: CAFE:BABE::2
    - AAAA: CAFE:BABE::3
...
  42.218.168.192.in-addr.arpa:
    - PTR: mx.example.com
    - PTR: mx.e7.example.com
  3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.E.B.A.B.E.F.A.C.ip6.arpa:
    - PTR: mx.example.com
  mx.e7.example.com:
    - A: 192.168.218.42

Since these match:

mx.example.com -> 192.168.218.42 -> 42.218.168.192.in-addr.arpa -> 
mx.example.com

mx.example.com -> CAFE:BABE::3 -> 
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.E.B.A.B.E.F.A.C.ip6.arpa -> 
mx.example.com

mx.e7.example.com -> 192.168.218.42 -> 42.218.168.192.in-addr.arpa -> 
mx.e7.example.com

mx.example.com and mx.e7.example.com (for IPv4) and mx.example.com (for IPv6) 
are validated PTRs that can be used for 'p'.  Since they neither match exactly 
nor are they a subdomain, the mechanism doesn't match, so the result is, as 
you say, fail.  Since they are validated though, they should be used to 
describe who the connect was from.  

This is the validation test in Section 5.5 (top of page 23) that's referenced 
in the discussion of 'p' in 7.3.  The validation is a precursor to the match 
domain/subdomain process.

Does that help?

Also, I added a new test to the unreleased version of the test suite over the 
weekend, so you might want to pull from svn if you haven't done so this week.

Scott K