Re: Question about Test Suite

Yes.  Certainly.  Just let me know what to put there and we'll be glad to list 
it.

Scott K

On Tuesday, September 23, 2014 14:44:22 Peter M. Goldstein via spf-devel 
wrote:
> Hi Scott,
> 
> Thanks for the quick reply.  So if I'm understanding your comments
> correctly, the subdomain restriction only applies when evaluating the
> mechanism, not when expanding the macro?
> 
> If that's the case I think my confusion arose from the fact that the
> definition of the p macro in section 7.3 references the mechanism
> definition in section 5.5 and I thought the subdomain restriction was
> included in the macro definition.
> 
> I'll address this issue and make sure Coppertone passes any additional
> OpenSPF specs.
> 
> On a related note, once the library passes the test suite, would it be
> possible to get it listed on the OpenSPF site?  Thanks.
> 
> Best,
> 
> Peter
> 
> 
> On Tue, Sep 23, 2014 at 2:35 PM, Scott Kitterman <[email protected]>
> 
> wrote:
> > 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
> 
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
> 
> Archives: https://www.listbox.com/member/archive/1007/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1007/1109814-a298404b
> Modify Your Subscription:
> https://www.listbox.com/member/?&
> f Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&
> 616855&post_id=20140923174429:CA85C862-436A-11E4-99E0-BFBA4434DB42 Powered
> by Listbox: http://www.listbox.com