-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stuart D. Gathman wrote:
Julian Mehnle wrote:
Then, given that "<64chars>.bar" is a valid <domain-spec>, what's the
point in having the indirection via some macro, if what we want to
test is just the handling of malformed (but syntax-valid) domain
names?
Because the behaviour may be different? It could easily be a different
code path in an implementation.
OK, but where is the "a:<64chars>.bar" case being tested then?
No, "toolonglabel" is not it.
The "a:<64chars>.bar" case seems way more fundamental than "a:%{macro-
that-expands-to-64+chars}.bar", yet you seem to think that testing only
the latter is sufficient.
I have thought long about how a PermError (let alone TempError) could be
justified for those cases, but I couldn't find a reasonable rationale, so
I took the liberty of narrowing it down to "no-match". Is there any
dissent? If not, then do we really need an erratum (currently noted as
<http://www.openspf.org/RFC_4408/Errata#permerror-invalid-domains>)
codifying the "no-match" behavior, or can we just drop the draft erratum
entry?
What about the attached diff? It hopefully resolves all open concerns.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHWq4FwL7PKlBZWjsRAjiCAKDiuSD110wTsCaXe4JTmQ6vIPPZjwCdGhUG
cKDZJUJgE06LPFmBaiiv3jQ=
=tmb6
-----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=73936645-5235a4
Powered by Listbox: http://www.listbox.com
Index: rfc4408-tests.yml
===================================================================
--- rfc4408-tests.yml (revision 94)
+++ rfc4408-tests.yml (working copy)
@@ -360,31 +360,47 @@
result: permerror
invalid-domain-empty-label:
description: >-
- Domain-spec must end in macro-expand or valid toplabel.
+ target-name that is a valid domain-spec per RFC 4408 but an invalid
+ domain name per RFC 1035 (empty label) must be treated as non-existent.
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.
- spec: [8.1/2, 5/10]
+ An empty domain label, i.e. two successive dots, in a mechanism
+ target-name is valid domain-spec syntax, even though a DNS query cannot
+ be composed from it. In analogy to 4.3/1 and 5/10/3, the mechanism
+ should then be treated as a no-match.
+ spec: [4.3/1, 5/10/3]
helo: mail.example.com
host: 1.2.3.4
mailfrom: foo(_at_)t10(_dot_)example(_dot_)com
- result: [fail, temperror]
+ result: fail
invalid-domain-long:
description: >-
- Domain-spec must end in macro-expand or valid toplabel.
+ target-name that is a valid domain-spec per RFC 4408 but an invalid
+ domain name per RFC 1035 (long label) must be treated as non-existent.
comment: >-
- But anything goes before the toplabel. Upper case H macro
- url escapes the HELO string, the result is longer than 63 chars.
- Long labels cannot be coded in a DNS query packet, so resolver must
- give error or empty result. Empty result is analogous to 4.3/1,
- and so is preferred.
- spec: [8.1/2, 5/10]
+ A domain label longer than 63 characters in a mechanism target-name is
+ valid domain-spec syntax, even though a DNS query cannot be composed
+ from it. In analogy to 4.3/1 and 5/10/3, the mechanism should then be
+ treated as a no-match.
+ spec: [4.3/1, 5/10/3]
+ helo: mail.example.com
+ host: 1.2.3.4
+ mailfrom: foo(_at_)t11(_dot_)example(_dot_)com
+ result: fail
+ invalid-domain-long-via-macro:
+ description: >-
+ target-name that is a valid domain-spec per RFC 4408 but an invalid
+ domain name per RFC 1035 (long label) must be treated as non-existent.
+ comment: >-
+ A domain label longer than 63 characters that results from macro
+ expansion in a mechanism target-name is valid domain-spec syntax (and is
+ not even subject to syntax checking after macro expansion), even though
+ a DNS query cannot be composed from it. In analogy to 4.3/1 and 5/10/3,
+ the mechanism should then be treated as a no-match.
+ spec: [4.3/1, 5/10/3]
helo: "%%%%%%%%%%%%%%%%%%%%%%"
host: 1.2.3.4
- mailfrom: foo(_at_)t11(_dot_)example(_dot_)com
- result: [fail, temperror]
+ mailfrom: foo(_at_)t12(_dot_)example(_dot_)com
+ result: fail
zonedata:
mail.example.com:
- A: 1.2.3.4
@@ -409,6 +425,8 @@
t10.example.com:
- SPF: v=spf1 a:mail.example...com -all
t11.example.com:
+ - SPF: v=spf1
a:a123456789012345678901234567890123456789012345678901234567890123.example.com
-all
+ t12.example.com:
- SPF: v=spf1 a:%{H}.bar -all
---
description: ALL mechanism syntax
@@ -729,20 +747,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 +791,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: