-----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.
The reason I missed the "invalid-domain-empty-label" test is that its
description isn't very expressive, and I hadn't read the comment.
What about removing my redundant test in favor of an improved description
for the existing "invalid-domain-empty-label" test? (See attached diff.)
The "invalid-domain-long" test's description has the same problem.
However, I did not want to edit that one before having discussed the
following: This test tests the "overlong label" case. But why is it
using macro expansion to that end? It could just as well say
"a:<64chars>.bar". That would allow to simplify the description even
further.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHWZrEwL7PKlBZWjsRAtseAKD2sLWNVl8mqlEzGXAXAP1uRpeosQCeI3l3
uRF7Ej4giyV4MNZm6rW3yx0=
=5LZs
-----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=2183229&id_secret=73774808-c50ee2
Powered by Listbox: http://www.listbox.com
Index: rfc4408-tests.yml
===================================================================
--- rfc4408-tests.yml (revision 94)
+++ rfc4408-tests.yml (working copy)
@@ -360,17 +360,18 @@
result: permerror
invalid-domain-empty-label:
description: >-
- Domain-spec must end in macro-expand or valid toplabel.
- comment: >-
- But anything goes before the toplabel. Empty labels cannot be
- encoded for sending to a name server, so resolver must give error
- or empty result. Empty result is analogous to 4.3/1, and so
- is preferred.
+ If a DNS-interactive mechanism has valid syntax according to the SPF
+ specification, but a DNS query cannot be composed from its target-name
+ (e.g. due to empty labels, i.e. two or more successive dots), then the
+ mechanism should be treated as a no-match in analogy to 4.3/1.
+ However, the spec is not entirely clear on this, so such a malformed
+ target-name could as well be considered a DNS error (TempError, not
+ useful) or a syntax error (PermError).
spec: [8.1/2, 5/10]
helo: mail.example.com
host: 1.2.3.4
mailfrom: foo(_at_)t10(_dot_)example(_dot_)com
- result: [fail, temperror]
+ result: [fail, temperror, permerror]
invalid-domain-long:
description: >-
Domain-spec must end in macro-expand or valid toplabel.
@@ -729,20 +730,6 @@
host: 1.2.3.4
mailfrom: foo(_at_)e13(_dot_)example(_dot_)com
result: permerror
- a-valid-syntax-but-unqueryable:
- description: >-
- If a DNS-interactive mechanism has valid syntax according to the SPF
- specification, but a DNS query cannot be composed from its target-name
- (e.g. due to empty labels, i.e. two or more successive dots), then the
- mechanism should be treated as a no-match.
- comment: >-
- The rationale is that, technically, the mechanism is not a syntax error,
- and the odd target-name obviously cannot exist in DNS.
- spec: 8.1/2
- helo: mail.example.com
- host: 1.2.3.4
- mailfrom: foo(_at_)e14(_dot_)example(_dot_)com
- result: neutral
zonedata:
mail.example.com:
- A: 1.2.3.4
@@ -787,8 +774,6 @@
- SPF: v=spf1 a:example.-com
e13.example.com:
- SPF: "v=spf1 a:"
- e14.example.com:
- - SPF: v=spf1 a:example..com
---
description: Include mechanism semantics and syntax
tests: