Re: Upcoming new test-suite release

-----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/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959932&id_secret=73306251-ec2976
Powered by Listbox: http://www.listbox.com