Mailing List Archive

Re: Upcoming new test-suite release
-----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.

Oh, I didn't see that one. I didn't look for something like that in the
"Record evaluation" scenario. Maybe I should have.

> It currently allows for either ignoring the empty label, or permerror.
> If there is an official errata requiring nomatch instead of permerror,
> then simply change the result set of the existing test.

AFAICT we still have to decide on that one:

http://www.openspf.org/auth/RFC_4408/Errata#permerror-invalid-domains

What are the arguments for allowing a PermError result in this case?

> Or were you concerned about 2 adjacent dots vs 3?

No.

> + e5a.example.com:
> + - SPF: v=spf1 a:museum
>
> This seems to be not redundant. However, it seems unintuitive to me
> that example..com must be ignored, but museum gets a permerr.

Well, the first part ("example..com must be ignored") is still to be
decided, but the spec is unambiguous with regard to the second part.

> How about this case:
>
> Result: pass ?
>
> e5b.example.com:
> - SPF: v=spf1 a:museum.

What would be the point? "a:museum." is still a syntax error because the
trailing dot doesn't count. The grammar doesn't allow "museum." for a
<domain-spec>, just as it doesn't allow plain "museum".

> + e11.example.com:
> + - SPF: v=spf1 exists:%{i}.%{l2r-}.user.%{d2}
> + 1.2.3.4.gladstone.philip.user.example.com:
> + - A: 127.0.0.2
>
> Good, but the actual failing example in the field used %{l1r-}.
> Shouldn't we use that?

No, because %{l2r-} is more general. An implementation could by accident
_always_ use only one "part" in the "reverse" (r) or "non-dot-separator"
(-) case, even if a higher part limit (e.g. 2) was specified. (Yes, that
would be a really weird bug, but it doesn't hurt to test for it, does
it?) Plus, I added an excess "-test" part in the mailfrom's localpart so
as to test whether the part limit is actually honored.

Maybe these two aspects are already covered by other test cases in the
suite (are they??), but I wasn't certain of that and thought it wouldn't
hurt to have them covered again.

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

iD8DBQFHWFydwL7PKlBZWjsRAmAPAKDY9fEMp/OxbALluZyx3FbI2ty74gCfWfzn
90ch9427Kxcb+CDVpJSJ25I=
=q+4W
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=73306008-551298
Powered by Listbox: http://www.listbox.com
Re: [spf-discuss] Re: Upcoming new test-suite release [ In reply to ]
On Thu, 6 Dec 2007, Julian Mehnle wrote:

> > e5b.example.com:
> > - SPF: v=spf1 a:museum.
>
> What would be the point? "a:museum." is still a syntax error because the
> trailing dot doesn't count. The grammar doesn't allow "museum." for a
> <domain-spec>, just as it doesn't allow plain "museum".

Since this isn't obvious, there should be a test case for both (with
and without trailing dot).

--
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.

-------------------------------------------
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=1311533&id_secret=73346155-418336
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Thu, 6 Dec 2007, Julian Mehnle wrote:
> > > e5b.example.com:
> > > - SPF: v=spf1 a:museum.
> >
> > What would be the point? "a:museum." is still a syntax error because
> > the trailing dot doesn't count. The grammar doesn't allow "museum."
> > for a <domain-spec>, just as it doesn't allow plain "museum".
>
> Since this isn't obvious, there should be a test case for both (with
> and without trailing dot).

But what are the chances of an implementation throwing PermError on
"a:museum" but not on "a:museum."?

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

iD8DBQFHWHEGwL7PKlBZWjsRAgM6AKDjAJtOfT12dEGtx1AUgKtBB0IWSgCg3tCD
igT8geUkz8rMqSTIK/DV7Tk=
=2znC
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=73352186-7170f5
Powered by Listbox: http://www.listbox.com
Re: Re: Upcoming new test-suite release [ In reply to ]
On Thu, 6 Dec 2007, Julian Mehnle wrote:

> > Since this isn't obvious, there should be a test case for both (with
> > and without trailing dot).
>
> But what are the chances of an implementation throwing PermError on
> "a:museum" but not on "a:museum."?

This is a test suite. Such considerations do not apply. Ideally, all
bizarre wrong behaviour should be flagged. In practice, we can't hit it all.
But deliberately throwing out a case we actually thought of, just
because we feel no one would make that mistake, is a silly mistake. The very
act of making *that* silly mistake will cause someone else to make the other
mistake, via a quantum mechanical application of Murphy's Law.

I'll go ahead and add the trailing dot case, if you are *sure* that both
should be permerror. The inconsistency is very ugly, but I suppose it
can't be helped. At least these are corner cases.

--
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.

-------------------------------------------
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=1311533&id_secret=73357762-f00a92
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Thu, 6 Dec 2007, Julian Mehnle wrote:
> > But what are the chances of an implementation throwing PermError on
> > "a:museum" but not on "a:museum."?
>
> This is a test suite. Such considerations do not apply.

Oh, I think they do. Maintainability and leanness do matter. They're
just not top priorities.

> Ideally, all bizarre wrong behaviour should be flagged. In practice, we
> can't hit it all. But deliberately throwing out a case we actually
> thought of, just because we feel no one would make that mistake, is a
> silly mistake. The very act of making *that* silly mistake will cause
> someone else to make the other mistake, via a quantum mechanical
> application of Murphy's Law.

I don't follow entirely ;-) ...

> I'll go ahead and add the trailing dot case, if you are *sure* that
> both should be permerror. The inconsistency is very ugly, but I
> suppose it can't be helped. At least these are corner cases.

... but I don't have a problem with adding it if others think it is
useful. Please do go ahead. I am 100% certain that both "museum" and
"museum." are NOT valid <domain-spec>s per RFC 4408.

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

iD8DBQFHWH0YwL7PKlBZWjsRAgx7AKCPXz4uZ7W4YxpopesKOc4fKmGNlgCg8orw
da3+otCH6ypDcEN5xj3QsSw=
=C6ip
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=73380426-921a7c
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
Julian Mehnle wrote:

> what are the chances of an implementation throwing PermError on
> "a:museum" but not on "a:museum."?

John tried also this solution for some 2821bis drafts. It didn't
fly in the end, just checking both PERMERRORs, as Stuart proposed
it, catches this plausible "one-dot-anywhere" approach.

Frank

-------------------------------------------
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=1311533&id_secret=73758371-5494ac
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
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=1311533&id_secret=73768073-756678
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----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/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311533&id_secret=73777393-4241c9
Powered by Listbox: http://www.listbox.com
Re: Re: Upcoming new test-suite release [ In reply to ]
On Fri, 7 Dec 2007, Julian Mehnle wrote:

> What about removing my redundant test in favor of an improved description
> for the existing "invalid-domain-empty-label" test? (See attached diff.)

The "description" field is the "short" description. It is supposed to be a one
line (or maybe several when quoting ABNF from the RFC) summary. The
"comment" field is the multiline explanation. You are welcome
to make the description + comment better, but please keep the
one-line summary + explanatory paragraph format.

> 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.

See toolonglabel. You need to test both before and after macro expansion.
The "spec" field is very informative for why tests are there. The
toolonglabel test is for 4.3/1. The invalid-domain-long test is for
8.1/2 and 5/10.

--
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.

-------------------------------------------
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=1311533&id_secret=73869703-ee7ee3
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Fri, 7 Dec 2007, Julian Mehnle wrote:
> > What about removing my redundant test in favor of an improved
> > description for the existing "invalid-domain-empty-label" test? (See
> > attached diff.)
>
> The "description" field is the "short" description. It is supposed to
> be a one line (or maybe several when quoting ABNF from the RFC)
> summary. The "comment" field is the multiline explanation.

I never understood it that way. Where do you get that from?
(<http://www.openspf.org/Test_Suite/Schema> doesn't say it must be a
one-liner. It merely says it should not be longer than one or two
sentences, which my attempt isn't.)

The problem we're getting into here is that we're testing things that
aren't clearly defined in the RFC, so we have to explain precisely what
the test is about. The description should be able to stand on its own
for someone who knows the RFC well, which isn't easy if the spec itself
is fuzzy on the test subject.

> You are welcome to make the description + comment better, but please
> keep the one-line summary + explanatory paragraph format.

OK, I'll give it a shot.

> > 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.
>
> See toolonglabel. You need to test both before and after macro
> expansion. The "spec" field is very informative for why tests are
> there. The toolonglabel test is for 4.3/1. The invalid-domain-long
> test is for 8.1/2 and 5/10.

"toolonglabel" tests 4.3/1, whereas "invalid-domain-long" only tests 4.3/1
by analogy at best. 8.1/2 doesn't apply because "invalid-domain-long"
isn't about a regular syntax error (not even if we change the target-name
to "<64chars>.bar", which is a valid <domain-spec>). 5/10 doesn't apply
either, at least not 5/10/2 (the "TempError" case) -- perhaps 5/10/3
(the "domain does not exist" case), though.

I agree that in the absence of an explicit statement about malformed
labels, 4.3/1 is a valid analogy. However, can we please drop the
reference to 8.1/2, and change the one to 5/10 into 5/10/3?

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?

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

iD8DBQFHWfkpwL7PKlBZWjsRAgOGAKCK2iB6TFme+qfrLnLNwqC5Bv3iWACcDQSZ
RNXkuRIctb+rTNmgESebT40=
=G+59
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=73900887-b15176
Powered by Listbox: http://www.listbox.com
Re: [spf-discuss] Re: Upcoming new test-suite release [ In reply to ]
On Sat, 8 Dec 2007, Julian Mehnle wrote:

> I never understood it that way. Where do you get that from?
> (<http://www.openspf.org/Test_Suite/Schema> doesn't say it must be a
> one-liner. It merely says it should not be longer than one or two
> sentences, which my attempt isn't.)

Literally, you are correct. In George MacDonalds "The Lost Princess",
there is a single sentence in the first paragraph that goes on for
the rest of the page. That would pass literal muster also.
If it will help to say "lines" instead of "sentences", I'll change
the informal Schema.

> 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. You are very good with improving the
explanations, but you really don't seem to get the value of testing
for all the stupid things we can think of. It is a big help to someone
creating an implementation.

--
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.

-------------------------------------------
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=1311533&id_secret=73906032-4ef412
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----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/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311533&id_secret=73935672-dbba29
Powered by Listbox: http://www.listbox.com
Re: Re: Upcoming new test-suite release [ In reply to ]
Mail kutumuzun yogunluguna gore size yanit verme surecimiz degisebilir. Gec kalinmis cevaplar icin bizi madur gorun.!

Sercan TAPSIN
GSM:
05447727177
05358583410
05558295252
ICQ : 706886
MSN : sercantapsin@hotmail.com
Yahoo : sercantapsin@yahoo.com
Google : sercantapsin@gmail.com
Mail : tapsin@hostunuz.com

-------------------------------------------
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=1311533&id_secret=73936469-d28827
Powered by Listbox: http://www.listbox.com
Re: Re: Re: Upcoming new test-suite release [ In reply to ]
Mail kutumuzun yogunluguna gore size yanit verme surecimiz degisebilir. Gec kalinmis cevaplar icin bizi madur gorun.!

Sercan TAPSIN
GSM:
05447727177
05358583410
05558295252
ICQ : 706886
MSN : sercantapsin@hotmail.com
Yahoo : sercantapsin@yahoo.com
Google : sercantapsin@gmail.com
Mail : tapsin@hostunuz.com

-------------------------------------------
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=1311533&id_secret=73937146-266597
Powered by Listbox: http://www.listbox.com
Re: Re: Re: Re: Upcoming new test-suite release [ In reply to ]
Mail kutumuzun yogunluguna gore size yanit verme surecimiz degisebilir. Gec kalinmis cevaplar icin bizi madur gorun.!

Sercan TAPSIN
GSM:
05447727177
05358583410
05558295252
ICQ : 706886
MSN : sercantapsin@hotmail.com
Yahoo : sercantapsin@yahoo.com
Google : sercantapsin@gmail.com
Mail : tapsin@hostunuz.com

-------------------------------------------
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=1311533&id_secret=73937461-7558f9
Powered by Listbox: http://www.listbox.com
Re: Re: Re: Re: Re: Upcoming new test-suite release [ In reply to ]
Mail kutumuzun yogunluguna gore size yanit verme surecimiz degisebilir. Gec kalinmis cevaplar icin bizi madur gorun.!

Sercan TAPSIN
GSM:
05447727177
05358583410
05558295252
ICQ : 706886
MSN : sercantapsin@hotmail.com
Yahoo : sercantapsin@yahoo.com
Google : sercantapsin@gmail.com
Mail : tapsin@hostunuz.com

-------------------------------------------
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=1311533&id_secret=73937819-7c98d2
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tapsin@hostunuz.com wrote:
> Mail kutumuzun yogunluguna gore size yanit verme surecimiz degisebilir.
> Gec kalinmis cevaplar icin bizi madur gorun.!
>
> Sercan TAPSIN

*sigh*

I unsubscribed the guy.

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

iD8DBQFHWt1DwL7PKlBZWjsRAjG9AJ99ZuJJesizmbKRsWD0xMV7QCyGXgCg8hWz
GmYXiowyKf1tYIcNfFQmSHk=
=YWzH
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=73959487-4b9a3f
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
Julian Mehnle wrote:

> 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.

IMO test both, it's in the spirit of Stuart's proposal to
cover all plausible code paths in a buggy implementation.

> 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".

Does that agree with your proposal of a new erratum wrt
"Permerror after macro expansion" ? I haven't checked
this yet (later: now I did, see below).

> 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?

That wannabe-erratum doesn't propose a fix, I guess what
I meant is "whatever you do, this is no TempError", or
"better let's say what it is" (no match or PermError).

But you found something about a PermError in the spec.,
http://permalink.gmane.org/gmane.mail.spam.spf.devel/1804
about http://www.openspf.org/RFC_4408#op-result-permerror
(= http://tools.ietf.org/html/rfc4408#section-2.5.7 )

What's a "checked identity having an unexpected format",
and where's Wayne when I want to kick his [guess]... ;-)

Have all syntatically valid identities expected formats ?
"good..dots"@example is syntactically valid, but simple
good..dots.example queries won't work for %{l}.example,
while good\.\.dots.example should work.

OTOH bad..dots.example is a syntactically invalid HELO,
does 2.5.7 mean that a:%{h} should throw a PermError ?

Likewise bad..dots@example is syntactically invalid,
implementations MUST NOT try to fix it for a possible
bad\.\.dots.example query.

We could say 2.5.7 got it wrong, and it should be "no
match", not PermError. Or we could remove the wannabe-
erratum keeping 2.5.7 and its obscure PermError as is.

In both cases I think that interpreting dots within a
quoted string (LHS) as "embedded dots" makes sense, it
is almost the same as "back\\slash"@example or other
odd creatures you might find in a local part for %{l}.

No erratum for the latter, but some ugly new test cases
where it would be a surprise if SPF implementations got
it right... :-( 2822upd will be somewhat simpler, no
more NO-WS-CTL. But still quoted dots and backslashes.

Frank

-------------------------------------------
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=1311533&id_secret=74004467-3c1b06
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > 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.
>
> IMO test both, it's in the spirit of Stuart's proposal to cover all
> plausible code paths in a buggy implementation.

Fine, that's what my last proposed patch does.

> > 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".
>
> Does that agree with your proposal of a new erratum wrt "Permerror after
> macro expansion" ?

Well, it doesn't agree, but I think 2.5.7/1/3 (the third sentence, which I
quoted in the message you are referring below) is actually a mistake.
After all, the entirety of RFC 4408 doesn't spell out the concept of
doing any syntax checking _after_ macro expansion, except for this one
sentence. Even if we think it would have been a good idea, it simply
isn't in the spec.

> > 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?
>
> That wannabe-erratum doesn't propose a fix, I guess what I meant is
> "whatever you do, this is no TempError", or "better let's say what it
> is" (no match or PermError).

Good. Can you think of a possible wording (and place in the RFC to put
it)?

> But you found something about a PermError in the spec.,
> http://permalink.gmane.org/gmane.mail.spam.spf.devel/1804
> about http://www.openspf.org/RFC_4408#op-result-permerror

See above.

> Have all syntatically valid identities expected formats ?
> "good..dots"@example is syntactically valid, but simple
> good..dots.example queries won't work for %{l}.example, while
> good\.\.dots.example should work.

I think that's exactly the case that 2.5.7/1/3 is referring to (even
though SPF doesn't know any concept of \-escaping, so your second example
would consist of four (4) labels, not two).

> OTOH bad..dots.example is a syntactically invalid HELO, does 2.5.7 mean
> that a:%{h} should throw a PermError ?

Yes, I think that's the intent. However, as I said, this is inconsistent
with the overall tune of the spec. I think it should be dropped for
consistency's sake. We can always revive the idea for SPFv3.

> We could say 2.5.7 got it wrong, and it should be "no match", not
> PermError. Or we could remove the wannabe-erratum keeping 2.5.7 and its
> obscure PermError as is.

I'd strongly prefer the former and would refrain from doing the latter.
What do others think?

> In both cases I think that interpreting dots within a quoted string
> (LHS) as "embedded dots" makes sense, it is almost the same as
> "back\\slash"@example or other odd creatures you might find in a local
> part for %{l}.

It might make sense, but the concept would be completely novel to RFC
4408, so I don't think we can do that.

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

iD8DBQFHW+DBwL7PKlBZWjsRApBvAKCxx7RC0VfVLSCRpnVZuGKQ71jnPQCgm2F5
PBj/Re7WCtkEjNuKupiUtI4=
=Ztq4
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=74030371-267a80
Powered by Listbox: http://www.listbox.com
Re: [spf-discuss] Re: Upcoming new test-suite release [ In reply to ]
On Sat, 8 Dec 2007, Julian Mehnle wrote:

> OK, but where is the "a:<64chars>.bar" case being tested then?
> No, "toolonglabel" is not it.

Yes, that tests long label in mailfrom. You are right, we need a
too long label test for A: (and maybe MX and include) as well.

--
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.

-------------------------------------------
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=1311533&id_secret=74100955-7cc353
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Sat, 8 Dec 2007, Julian Mehnle wrote:
> > OK, but where is the "a:<64chars>.bar" case being tested then?
> > No, "toolonglabel" is not it.
>
> Yes, that tests long label in mailfrom. You are right, we need a
> too long label test for A: (and maybe MX and include) as well.

OK, but I don't think we need separate tests for "mx:" and "include:".
It can be reasonably expected that an SPF implementation uses the same
<domain-spec> validation code for all of them.

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

iD8DBQFHXHm8wL7PKlBZWjsRAkKZAJ9+uo1hpgqQgyZIkdqhSNzpLGHWSgCg6Zba
TP1wBgHUkJcTWPkCdUJdyog=
=C2wG
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=74118508-264e34
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Sat, 8 Dec 2007, Julian Mehnle wrote:
> > OK, but where is the "a:<64chars>.bar" case being tested then?
> > No, "toolonglabel" is not it.
>
> Yes, that tests long label in mailfrom. You are right, we need a
> too long label test for A: (and maybe MX and include) as well.

OK, but I don't think we need separate tests for "mx:" and "include:".
It can be reasonably expected that an SPF implementation uses the same
<domain-spec> validation code for all of them.

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

iD8DBQFHXHoxwL7PKlBZWjsRArIEAKCmGz1aslt3IvAYpzCxE1L73cWWCgCaAtvb
bnT/XUpxsZeLdUbS5z1gQEI=
=GJsC
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=74118938-005d13
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guy wrote:
> Does the test-suite test for extra TXT records? My domain has an extra
> TXT record from a test I did years ago. I left it in, but it has
> caused some SPF checkers to report invalid spf record errors. I
> reported such errors at least twice in the past 2 years. But it still
> comes up as an issue from time to time.
>
> To see my 2 records:
> dig watkins-home.com txt
>
> watkins-home.com. 360000 IN TXT "line1" "line2" "line3" "line4" "line5" "Line n"
> watkins-home.com. 360000 IN TXT "v=spf1 mx " "ip4:63.240.76.0/17 " "ip4:204.127.192.0/18 " "ip4:206.18.177.0/24 " "ip4:216.148.227.0/24 " "+exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d}.spf-tracker.watkins-home. com " "?all"

I am interpreting your question as follows:

Does the test suite test whether an SPF implementation correctly selects a
singular "v=spf1 ..." record in the presence of other, non-"v=spf1" TXT
records?

Answer:

Yes, it does, via the "nospace2" test case, assuming the test suite is
being interpreted correctly. (The test suite is merely a specification of
scenarios and expected results. For it to "work" correctly, it depends on
a test suite "driver" feeding the data to an SPF implementation and
checking the results returned.)

A correct test suite driver will find the SPF-type records in the
"nospace2" test's zonedata and synthesize identical TXT-type records from
them (see <http://www.openspf.org/Test_Suite/Schema>). The "v=spf10"
record (SPF-type or TXT-type) must then be treated as any random non-
"v=spf1" record (just like your "line1" ... "line n" record) by the
implementation and ignored in favor of the other record, which starts
with "v=spf1".

An implementation that croaks on a non-"v=spf1" record even though another
record exists that starts with "v=spf1", will fail the test suite,
provided the test suite driver works correctly.

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

iD8DBQFHXdQ9wL7PKlBZWjsRAhILAJ98rIq9GB2yTgZpcA1KJ3GUH2RrrwCgwCKO
zXc1J1oUOcmVqo/es/yu+ug=
=mXwV
-----END PGP SIGNATURE-----

-------------------------------------------
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=1311533&id_secret=74434754-f5d56d
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Julian Mehnle wrote:
> [ "a:<64chars>.bar" / "a:%{macro-that-expands-to-64+chars}.bar" ]
>
> 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?
> [...]
> What about the attached diff? It hopefully resolves all open concerns.

No opposition to that patch was raised, so I now committed exactly that,
as r95 of the test suite:

http://www.openspf.org/source/project/test-suite/rfc4408-tests.yml?view=log
http://www.openspf.org/source/project/test-suite/rfc4408-tests.yml?r1=94&r2=95

Can we now make a new test suite release?

> 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?

Any comments on that?

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

iD8DBQFH6ss/wL7PKlBZWjsRAkQqAKCt0wzlX9w9h9h3qVbw7hxLmFejswCg2gns
oGmCozTB7DJTcmQ/jZ90QTo=
=Uprt
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/1007/=now
RSS Feed: http://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com
Re: Upcoming new test-suite release [ In reply to ]
Julian Mehnle wrote:

> Any comments on that?

Yeah, in
<http://article.gmane.org/gmane.mail.spam.spf.devel/1831>
<http://article.gmane.org/gmane.mail.spam.spf.discuss/23632>
<http://article.gmane.org/gmane.mail.spam.spf.discuss/24048>
<http://article.gmane.org/gmane.mail.spam.spf.discuss/24052>

Inconclusive, two for "no match", two for "PermError", the
latter based on 2.5.7.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/1007/=now
RSS Feed: http://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com

1 2  View All