Re: Upcoming new test-suite release

-----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=6959932&id_secret=74030611-318b63
Powered by Listbox: http://www.listbox.com