Re: Upcoming new test-suite release
Julian Mehnle <[email protected]> Fri, 7 Dec 2007 19:02:30 +0000
| Newsgroups | gmane.mail.spam.spf.devel |
|---|---|
| Message-ID | <[email protected]> |
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. ------------------------------------------- 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=73769225-73ace5 Powered by Listbox: http://www.listbox.com
rfc4408-tests.yml-no-redundant-unqueryable-test-but-fix-empty-label-test-description.diff
(text/x-diff, 2.3 KB)
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: [email protected]
- 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: [email protected]
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: [email protected]
- 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: