Mailing List Archive: test deficiency

Our test framework can't handle this test:

---
description: |
Explanation
tests:
redirect-cancels-exp:
description: |
exp= from the original domain MUST NOT be used after redirect=
spec: 6.2/13
helo: mail.example.com
host: 1.2.3.4
mailfrom: foo@e1.example.com
result: fail
explanation: Anything but No-see-um
zonedata:
mail.example.com:
- A: 1.2.3.4
e1.example.com:
- SPF: v=spf1 exp=exp1.example.com redirect=e2.example.com
e2.example.com:
- SPF: v=spf1 -all
exp1.example.com:
- TXT: No-see-um

We need to specify that the result is *not* "No-see-um". This could
be done by specifying a default explanation like Wayne did - but libraries
should not be required to support that. It could be done by allowing
negation somehow. Any suggestions?

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> Our test framework can't handle this test:
>
> ---
> description: |
> Explanation
> tests:
> redirect-cancels-exp:
> description: |
> exp= from the original domain MUST NOT be used after redirect=
> spec: 6.2/13
> helo: mail.example.com
> host: 1.2.3.4
> mailfrom: foo@e1.example.com
> result: fail
> explanation: Anything but No-see-um
> zonedata:
> mail.example.com:
> - A: 1.2.3.4
> e1.example.com:
> - SPF: v=spf1 exp=exp1.example.com redirect=e2.example.com
> e2.example.com:
> - SPF: v=spf1 -all
> exp1.example.com:
> - TXT: No-see-um
>
> We need to specify that the result is *not* "No-see-um". This could
> be done by specifying a default explanation like Wayne did - but
> libraries should not be required to support that. It could be done by
> allowing negation somehow. Any suggestions?

Maybe we could allow /regexp/ and !/regexp/ syntaxes for text-matching test
case fields (specifically including "explanation")?

But I don't think this special case justifies yet another bit of complexity
in the test suite schema. We should probably leave 6.2/13 uncovered by
the test-suite.

What do others think?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFE34aewL7PKlBZWjsRAqWBAKDdlAPjK3MhoIeq1UZ33j8BPYRzgACfUmp0
0qq/GFxiflmOKdITT2A+z+U=
=QJxw
-----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