spf-discuss
[Top] [All Lists]

[spf-discuss] Re: Upcoming new test-suite release

2007-12-09 05:35:39
-----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/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=74030954-467c1c
Powered by Listbox: http://www.listbox.com