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