-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I do have a few concerns about the test suite schema[1]:
* Let's use descriptive test names, i.e. "trailing-dot-is-acceptable"
instead of "traildot1". Even if we're conservative, we'll have a lot
of tests. Let's be precise (not overly, though) when making spec
references ("8.1/16" vs "8.1"). And let's not be overly redundant when
wording test descriptions, i.e. avoid saying "Check that..." every
time.
* There's usually no reason to use _literal_ YAML blocks[2] for comments.
Instead, one would usually use _folded_ blocks[3], and thus the > (or
>-) style indicator instead of the | (or |-) indicator. I fixed that
in the informal schema sample already.
* Let's call the comment field "description" instead of "comment", and
use "comment" only for non-essential comments about the item in
question. I.e.:
tests:
domain-spec-trailing-dot-is-acceptable:
spec: 8.1/16
comment: a trailing dot in a domain-spec must be accepted
...
explanation-trailing-dot-is-preserved:
spec: 8.1
comment: >-
a trailing dot in an explanation string must be preserved
...
explanation: This is a test.
* I have been thinking about the various identities that can be checked
by SPF and S-ID (and possibly later SPF revisions). Currently, there
are at least HELO, MAIL FROM, and PRA. I think we should allow each
test to check any one of those identities. What I did in Mail::SPF is
allow two basic parameters to be specified: the scope and the identity
value. The scopes would be named after the scope tags they would use
in a real SPF record, i.e. "helo", "mfrom", "pra", etc. If the scope
is omitted, it would default to "mfrom" In addition to that, any
parameters relevant to the given scope should be specified ("host" for
all the currently defined scopes). I.e.:
tests:
helo-test:
scope: helo
helo: mta.example.com
host: 10.0.0.1
result: ...
...
mfrom-test:
scope: mfrom # optional, as "mfrom" is the default
mfrom: joe@example.com
host: 10.0.0.1
result: ...
...
I think this scheme is still very simple but significantly more
versatile.
References:
1. http://new.openspf.org/Test_Suite/Schema
2. http://yaml.org/spec/current.html#id2540046
3. http://yaml.org/spec/current.html#id2540863
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEyl36wL7PKlBZWjsRAgXtAKCz+FJ82LZScPrBhT6gtV6lbaLmRgCdFNbs
ZMoHgaeuLYYFeGfF3KsxX6w=
=HTb4
-----END PGP SIGNATURE-----
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Hash: SHA1
I do have a few concerns about the test suite schema[1]:
* Let's use descriptive test names, i.e. "trailing-dot-is-acceptable"
instead of "traildot1". Even if we're conservative, we'll have a lot
of tests. Let's be precise (not overly, though) when making spec
references ("8.1/16" vs "8.1"). And let's not be overly redundant when
wording test descriptions, i.e. avoid saying "Check that..." every
time.
* There's usually no reason to use _literal_ YAML blocks[2] for comments.
Instead, one would usually use _folded_ blocks[3], and thus the > (or
>-) style indicator instead of the | (or |-) indicator. I fixed that
in the informal schema sample already.
* Let's call the comment field "description" instead of "comment", and
use "comment" only for non-essential comments about the item in
question. I.e.:
tests:
domain-spec-trailing-dot-is-acceptable:
spec: 8.1/16
comment: a trailing dot in a domain-spec must be accepted
...
explanation-trailing-dot-is-preserved:
spec: 8.1
comment: >-
a trailing dot in an explanation string must be preserved
...
explanation: This is a test.
* I have been thinking about the various identities that can be checked
by SPF and S-ID (and possibly later SPF revisions). Currently, there
are at least HELO, MAIL FROM, and PRA. I think we should allow each
test to check any one of those identities. What I did in Mail::SPF is
allow two basic parameters to be specified: the scope and the identity
value. The scopes would be named after the scope tags they would use
in a real SPF record, i.e. "helo", "mfrom", "pra", etc. If the scope
is omitted, it would default to "mfrom" In addition to that, any
parameters relevant to the given scope should be specified ("host" for
all the currently defined scopes). I.e.:
tests:
helo-test:
scope: helo
helo: mta.example.com
host: 10.0.0.1
result: ...
...
mfrom-test:
scope: mfrom # optional, as "mfrom" is the default
mfrom: joe@example.com
host: 10.0.0.1
result: ...
...
I think this scheme is still very simple but significantly more
versatile.
References:
1. http://new.openspf.org/Test_Suite/Schema
2. http://yaml.org/spec/current.html#id2540046
3. http://yaml.org/spec/current.html#id2540863
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEyl36wL7PKlBZWjsRAgXtAKCz+FJ82LZScPrBhT6gtV6lbaLmRgCdFNbs
ZMoHgaeuLYYFeGfF3KsxX6w=
=HTb4
-----END PGP SIGNATURE-----
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com