-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stuart D. Gathman wrote:
> + e14.example.com:
> + - SPF: v=spf1 a:example..com
>
> There was already a test for this: invalid-domain-empty-label.
Oh, I didn't see that one. I didn't look for something like that in the
"Record evaluation" scenario. Maybe I should have.
> It currently allows for either ignoring the empty label, or permerror.
> If there is an official errata requiring nomatch instead of permerror,
> then simply change the result set of the existing test.
AFAICT we still have to decide on that one:
http://www.openspf.org/auth/RFC_4408/Errata#permerror-invalid-domains
What are the arguments for allowing a PermError result in this case?
> Or were you concerned about 2 adjacent dots vs 3?
No.
> + e5a.example.com:
> + - SPF: v=spf1 a:museum
>
> This seems to be not redundant. However, it seems unintuitive to me
> that example..com must be ignored, but museum gets a permerr.
Well, the first part ("example..com must be ignored") is still to be
decided, but the spec is unambiguous with regard to the second part.
> How about this case:
>
> Result: pass ?
>
> e5b.example.com:
> - SPF: v=spf1 a:museum.
What would be the point? "a:museum." is still a syntax error because the
trailing dot doesn't count. The grammar doesn't allow "museum." for a
<domain-spec>, just as it doesn't allow plain "museum".
> + e11.example.com:
> + - SPF: v=spf1 exists:%{i}.%{l2r-}.user.%{d2}
> + 1.2.3.4.gladstone.philip.user.example.com:
> + - A: 127.0.0.2
>
> Good, but the actual failing example in the field used %{l1r-}.
> Shouldn't we use that?
No, because %{l2r-} is more general. An implementation could by accident
_always_ use only one "part" in the "reverse" (r) or "non-dot-separator"
(-) case, even if a higher part limit (e.g. 2) was specified. (Yes, that
would be a really weird bug, but it doesn't hurt to test for it, does
it?) Plus, I added an excess "-test" part in the mailfrom's localpart so
as to test whether the part limit is actually honored.
Maybe these two aspects are already covered by other test cases in the
suite (are they??), but I wasn't certain of that and thought it wouldn't
hurt to have them covered again.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHWFydwL7PKlBZWjsRAmAPAKDY9fEMp/OxbALluZyx3FbI2ty74gCfWfzn
90ch9427Kxcb+CDVpJSJ25I=
=q+4W
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=73306579-9946d4
Powered by Listbox: http://www.listbox.com
Hash: SHA1
Stuart D. Gathman wrote:
> + e14.example.com:
> + - SPF: v=spf1 a:example..com
>
> There was already a test for this: invalid-domain-empty-label.
Oh, I didn't see that one. I didn't look for something like that in the
"Record evaluation" scenario. Maybe I should have.
> It currently allows for either ignoring the empty label, or permerror.
> If there is an official errata requiring nomatch instead of permerror,
> then simply change the result set of the existing test.
AFAICT we still have to decide on that one:
http://www.openspf.org/auth/RFC_4408/Errata#permerror-invalid-domains
What are the arguments for allowing a PermError result in this case?
> Or were you concerned about 2 adjacent dots vs 3?
No.
> + e5a.example.com:
> + - SPF: v=spf1 a:museum
>
> This seems to be not redundant. However, it seems unintuitive to me
> that example..com must be ignored, but museum gets a permerr.
Well, the first part ("example..com must be ignored") is still to be
decided, but the spec is unambiguous with regard to the second part.
> How about this case:
>
> Result: pass ?
>
> e5b.example.com:
> - SPF: v=spf1 a:museum.
What would be the point? "a:museum." is still a syntax error because the
trailing dot doesn't count. The grammar doesn't allow "museum." for a
<domain-spec>, just as it doesn't allow plain "museum".
> + e11.example.com:
> + - SPF: v=spf1 exists:%{i}.%{l2r-}.user.%{d2}
> + 1.2.3.4.gladstone.philip.user.example.com:
> + - A: 127.0.0.2
>
> Good, but the actual failing example in the field used %{l1r-}.
> Shouldn't we use that?
No, because %{l2r-} is more general. An implementation could by accident
_always_ use only one "part" in the "reverse" (r) or "non-dot-separator"
(-) case, even if a higher part limit (e.g. 2) was specified. (Yes, that
would be a really weird bug, but it doesn't hurt to test for it, does
it?) Plus, I added an excess "-test" part in the mailfrom's localpart so
as to test whether the part limit is actually honored.
Maybe these two aspects are already covered by other test cases in the
suite (are they??), but I wasn't certain of that and thought it wouldn't
hurt to have them covered again.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHWFydwL7PKlBZWjsRAmAPAKDY9fEMp/OxbALluZyx3FbI2ty74gCfWfzn
90ch9427Kxcb+CDVpJSJ25I=
=q+4W
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=73306579-9946d4
Powered by Listbox: http://www.listbox.com
