On Thursday 24 July 2008 16:35, Frank Ellermann wrote:
Scott Kitterman wrote:
[not only new]
SPF applications are free to honour or ignore SPF policies
using this feature. They could abort SPF checks with result
NONE when they see a localpart macro outside of explanations,
for example.
I would be against this. I'm not aware of any library that
currently has trouble with macros.
Doug's "SPF scripts take DNS down" nightmares were certainly
exaggerated. But he had a point wrt abuse obscured by local-
part macros. Most SPF macros are harmless, but %{l} is not.
I fear that no SPF implementations gets some weirder macro
cases right. For "\"take\\that\""@example.com RFC 2821bis
(until yesterday RFC 2821) said that the "semantic content"
is "take\that" (including the quotes).
Yes, but that doesn't change RFC 4408.
IIRC Julian or you said that you remove outer quotes, after
that step you are at \"take\\that\". Do you also trim the
odd backslashes in a <target-name> macro expansion of %{l} ?
You don't support embedded dots as in "take.that", i.e. you
treat that as two labels take.that instead of only one label
take\.that.
Consequently "do..ts" won't work, now covered by an erratum.
My confidence that similar strange local parts (without the
known dots cases) work consistently is limited. DNS can do,
in theory, but can existing SPF implementations ?
What about "space me"@example.com with two spaces ? That's
where even RFC 2821bis and I-D 2822upd gave up, it is legal
(syntactically), but might not work as expected. At least
RFC 2821bis killed control characters including TAB for this
madness. I-D 2822upd didn't, nobody had the energy to fix
this discrepancy.
With your logic (as implemented, this is unspecified) you'd
strip the quotes and arrive at space me (with two embedded
spaces). No problem for DNS, but does this really work, are
there test cases for it ?
Of course not only %{l} can have this effect, strange HELOs
- actually syntactically invalid HELOs for RFC 2821bis - can
also result in tricky %{h} cases. Ditto %{s}, that is worse
than %{l} if policies use it in a <domain-spec> expanded into
<target-name>.
If these three macros (or rather six, h+l+s+H+L+S) would be
limited to explanations they'd be fine. But this is not the
case.
Philip Gladstone's SPF record drove a lot of bug fixes into pyspf when I first
pubilshed my validator in July 2005. If we're missing stuff in the test
suite, let's add it, but AFAIK all the major libraries that are maintained,
get the test cases we have correct.
4408 says what it says and we need to make sure we've done the best we can
with it.
Scott K
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com