Re: Question about Test Suite
"Peter M. Goldstein via spf-devel" <[email protected]> Tue, 23 Sep 2014 14:44:22 -0700
| Newsgroups | gmane.mail.spam.spf.devel |
|---|---|
| Message-ID | <CAErFxE=79tgL-MUd=p-oKDsyJEWoPm2Ybi5zKkB95Gsh1ycy9w@mail.gmail.com> |
--e89a8f23587771a17d0503c27824 Content-Type: text/plain; charset=UTF-8 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/6959932-f3d1312d Modify Your Subscription: https://www.listbox.com/member/?member_id=6959932&id_secret=6959932-d95100fc Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959932&id_secret=6959932-4aedb9c4&post_id=20140923174429:CA85C862-436A-11E4-99E0-BFBA4434DB42 Powered by Listbox: http://www.listbox.com --e89a8f23587771a17d0503c27824 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Scott,<div><br></div><div>Thanks for the quick reply.= =C2=A0 So if I'm understanding your comments correctly, the subdomain r= estriction only applies when evaluating the mechanism, not when expanding t= he macro?</div><div><br></div><div>If that's the case I think my confus= ion arose from the fact that the definition of the p macro in section 7.3 r= eferences the mechanism definition in section 5.5 and I thought the subdoma= in restriction was included in the macro definition.</div><div><br></div><d= iv>I'll address this issue and make sure Coppertone passes any addition= al OpenSPF specs.</div><div><br></div><div>On a related note, once the libr= ary passes the test suite, would it be possible to get it listed on the Ope= nSPF site?=C2=A0 Thanks.</div><div><br></div><div>Best,</div><div><br></div= ><div>Peter</div><div><br><img src=3D"https://t.yesware.com/t/615ecac893247= 4f596391d7811607ca49192c7c9/a5aaacb8b052c218353c6b4516f10234/spacer.gif" st= yle=3D"border: 0; width: 0px; height: 0px;" width=3D"0" height=3D"0"><img s= rc=3D"http://t.yesware.com/t/615ecac8932474f596391d7811607ca49192c7c9/a5aaa= cb8b052c218353c6b4516f10234/spacer.gif" style=3D"border: 0; width: 0px; hei= ght: 0px;" width=3D"0" height=3D"0"><font face=3D"yw-615ecac8932474f596391d= 7811607ca49192c7c9-a5aaacb8b052c218353c6b4516f10234--to" style></font></div= ></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Se= p 23, 2014 at 2:35 PM, Scott Kitterman <span dir=3D"ltr"><<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>></spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div clas= s=3D"h5">On Tuesday, September 23, 2014 14:03:50 you wrote:<br> > Hi Everyone,<br> ><br> > I'm in the midst of writing an SPF implementation and toolkit in R= uby.=C2=A0 You<br> > can find the source code here - <a href=3D"https://github.com/petergol= dstein/coppertone" target=3D"_blank">https://github.com/petergoldstein/copp= ertone</a><br> ><br> > I've implemented a runner for the RFC 7208 OpenSPF test suite as d= efined<br> > here - <a href=3D"http://www.openspf.org/svn/project/test-suite/" targ= et=3D"_blank">http://www.openspf.org/svn/project/test-suite/</a> - and I= 9;ve got all<br> > but two of the specs passing.=C2=A0 You can find the RSpec version of = the test<br> > suite in the repository referenced above, under the spec/open_spf dire= ctory.<br> ><br> > Two of the specs, both related to subdomain resolution in 'p' = macro<br> > expansion are not passing, and I can't figure out why the results = specified<br> > in the suite are correct.=C2=A0 The two specs are p-macro-ip4-valid on= line 2110<br> > and p-macro-ip6-valid on line 2132.<br> ><br> > In both cases, I get the expected 'fail' result, but the p mac= ro does not<br> > resolve, because the current domain (<a href=3D"http://e6.example.com"= target=3D"_blank">e6.example.com</a>) is not a subdomain of<br> > any of the PTR records returned by 41.218.168.192.in-addr.arpa or<br> > 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.ar= pa<br> > respectively.<br> ><br> > The only returned PTR record in each case in '<a href=3D"http://mx= .example.com" target=3D"_blank">mx.example.com</a>', which is not<br> > a subdomain of <a href=3D"http://e6.example.com" target=3D"_blank">e6.= example.com</a> and thus, according to my reading of the<br> > spec, should not be used.=C2=A0 So my explanation is 'connect from= unknown' as<br> > opposed to the 'connect from <a href=3D"http://mx.example.com" tar= get=3D"_blank">mx.example.com</a>'<br> ><br> > Am I misunderstanding the RFC here?=C2=A0 If not, why is this value co= rrect?<br> ><br> > Any help is appreciated.=C2=A0 Thanks.<br> <br> </div></div>In the zone data for that test, it has:<br> <br> =C2=A0 <a href=3D"http://mx.example.com" target=3D"_blank">mx.example.com</= a>:<br> =C2=A0 =C2=A0 - A: 192.168.218.41<br> =C2=A0 =C2=A0 - A: 192.168.218.42<br> =C2=A0 =C2=A0 - AAAA: CAFE:BABE::2<br> =C2=A0 =C2=A0 - AAAA: CAFE:BABE::3<br> ...<br> =C2=A0 42.218.168.192.in-addr.arpa:<br> =C2=A0 =C2=A0 - PTR: <a href=3D"http://mx.example.com" target=3D"_blank">mx= .example.com</a><br> =C2=A0 =C2=A0 - PTR: <a href=3D"http://mx.e7.example.com" target=3D"_blank"= >mx.e7.example.com</a><br> =C2=A0 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:<br> =C2=A0 =C2=A0 - PTR: <a href=3D"http://mx.example.com" target=3D"_blank">mx= .example.com</a><br> =C2=A0 <a href=3D"http://mx.e7.example.com" target=3D"_blank">mx.e7.example= .com</a>:<br> =C2=A0 =C2=A0 - A: 192.168.218.42<br> <br> Since these match:<br> <br> <a href=3D"http://mx.example.com" target=3D"_blank">mx.example.com</a> ->= ; 192.168.218.42 -> 42.218.168.192.in-addr.arpa -><br> <a href=3D"http://mx.example.com" target=3D"_blank">mx.example.com</a><br> <br> <a href=3D"http://mx.example.com" target=3D"_blank">mx.example.com</a> ->= ; CAFE:BABE::3 -><br> 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 -&= gt;<br> <a href=3D"http://mx.example.com" target=3D"_blank">mx.example.com</a><br> <br> <a href=3D"http://mx.e7.example.com" target=3D"_blank">mx.e7.example.com</a= > -> 192.168.218.42 -> 42.218.168.192.in-addr.arpa -><br> <a href=3D"http://mx.e7.example.com" target=3D"_blank">mx.e7.example.com</a= ><br> <br> <a href=3D"http://mx.example.com" target=3D"_blank">mx.example.com</a> and = <a href=3D"http://mx.e7.example.com" target=3D"_blank">mx.e7.example.com</a= > (for IPv4) and <a href=3D"http://mx.example.com" target=3D"_blank">mx.exa= mple.com</a> (for IPv6)<br> are validated PTRs that can be used for 'p'.=C2=A0 Since they neith= er match exactly<br> nor are they a subdomain, the mechanism doesn't match, so the result is= , as<br> you say, fail.=C2=A0 Since they are validated though, they should be used t= o<br> describe who the connect was from.<br> <br> This is the validation test in Section 5.5 (top of page 23) that's refe= renced<br> in the discussion of 'p' in 7.3.=C2=A0 The validation is a precurso= r to the match<br> domain/subdomain process.<br> <br> Does that help?<br> <br> Also, I added a new test to the unreleased version of the test suite over t= he<br> weekend, so you might want to pull from svn if you haven't done so this= week.<br> <br> Scott K<br> <br> </blockquote></div><br></div> <div style=3D"width:auto;margin:0;padding:5px;background-color:#fff;clear:b= oth;border-top: 1px solid #ccc;" bgcolor=3D"#ffffff"> <p style=3D'font-family:Arial,sans-serif;margin:0.5em auto'>Sender Policy F= ramework: <a href=3D"http://www.openspf.net">http://www.openspf.net</a><br>= =0D Modify Your Subscription: <a href=3D"http://www.listbox.com/member/">http:/= /www.listbox.com/member/</a></p> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" styl= e=3D"background-color:#fff" bgcolor=3D"#ffffff"> <tr> <td padding=3D"4px"> <font color=3D"#333333" size=3D"1" style=3D"font-family:helvetica, sa= ns-serif;"> <a style=3D"text-decoration:none;color:#669933;border-bottom: 1px sol= id #444444" href=3D"https://www.listbox.com/member/archive/1007/=3Dnow" title=3D"Go to = archives for spf-devel">Archives</a> <a border=3D"0" style=3D"text-decoration:none;color:#669933" href=3D"https:= //www.listbox.com/member/archive/rss/1007/6959932-f3d1312d" title=3D"RSS fe= ed for spf-devel"><img border=3D0 src=3D"https://www.listbox.com/images/fee= d-icon-10x10.jpg" /></a> | <a style=3D"text-decoration:none;color:#669933;border-bottom: 1px solid = #444444" href=3D"https://www.listbox.com/member/?member_id=3D6959932&id_secret=3D695= 9932-d95100fc" title=3D"">Modify</a> Your Subscription | <a style=3D"text-decoration:none;color:#669933;border-= bottom: 1px solid #444444" href=3D"https://www.listbox.com/unsubscribe/?member_id=3D6959932&id_secret= =3D6959932-4aedb9c4&post_id=3D20140923174429:CA85C862-436A-11E4-99E0-BFBA44= 34DB42" title=3D"">Unsubscribe Now</a> <td valign=3D"top" align=3D"right"><a style=3D"border-bottom:none;" href=3D= "http://www.listbox.com"> <img src=3D"https://www.listbox.com/images/listbox-logo-small.png" title=3D"Powered by Listbox" border=3D"0" /></a></td> </font> </td> </tr> </table> </div> --e89a8f23587771a17d0503c27824--