Mailing List Archive

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/1311533-9e42a648
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311533&id_secret=1311533-d322f1f1
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311533&id_secret=1311533-d59c80a0&post_id=20140923173542:8FDFFAE4-4369-11E4-8C04-87315E4E4BEC
Powered by Listbox: http://www.listbox.com

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 <scott@kitterman.com>
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/1311533-9e42a648
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311533&id_secret=1311533-d322f1f1
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311533&id_secret=1311533-d59c80a0&post_id=20140923174429:CA85C862-436A-11E4-99E0-BFBA4434DB42
Powered by Listbox: http://www.listbox.com

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 <scott@kitterman.com>
>
> 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



-------------------------------------------
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/1311533-9e42a648
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311533&id_secret=1311533-d322f1f1
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311533&id_secret=1311533-d59c80a0&post_id=20140923181520:1A5B06E6-436F-11E4-BD6B-F3512B1750D0
Powered by Listbox: http://www.listbox.com