julian at mehnle
Dec 9, 2007, 4:34 AM
Post #19 of 47
(6357 views)
Permalink
|
-----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
|
rfc4408-tests.yml-no-redundant-unqueryable-test-but-fix-empty-label-test-description.diff
1
