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).
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.
Their use may be limited, but they are important to support
certain use cases.
For Doug's DDoS theories. In practice see subject, less than
0.5 permille use *any* macros, if this statistics is correct.
I've serious doubts wrt the interoperability for quoted pairs
and quoted strings - confirmed by 2821bis and its predecessor.
I'd be a lot more excited about deprecating ip4 and ip6 and
making a apply to IP addresses too.
That would get you in a syntactical mess. a: supports macros,
it comes with a <domain-spec>. But ip4/ip6 don't. So you'd
get a first special case "if it contains macros it is no IP".
After that IPv6 and IPv4 can or must have a dot. Currently
the syntax insists on at least one dot to figure out where
the <toplabel> is. So you'd need a clear rule what is and
what is not a <toplabel>. The IETF has so far no consensus
about this. IOW I thought John got it right in RFC 3696, but
John says he got this wrong, and lots of other folks starting
with ICANN have lots of other ideas not necessarily related
to technical questions.
[If you're interested in the bloody details, RFC 4408 allows
0xFF as <toplabel>. Some applications including Firefox
treat that as 255 in an IPv4 if they can. So John is right,
his RFC 3696 and our RFC 4408 were wrong. Shit happens.]
What is worse, ICANN intends to introduce hundreds, thousands,
or more TLDs. Possibly some of these TLDs will be hosts, but
SPF insists on at least one dot like the old RFC 2821. The
new RFC 2821bis still says (in prose) that "no dot" might not
work as expected, but in theory it allows this. But RFC 4408
doesn't. IMO no practical problem yet, and maybe irrelevant
forever, but not a situation where we should try to make this
worse wrt future developments.
IMNSHO, if the publisher of a sender policy does not know the
difference between "name" (a) and "address" (ip4 or ip6), then
he has no business to publish a policy, because he is clueless
and should find someone who knows the basics. Even our wizard
gets this right, and that is a script.
SPF has the potential to delete legit mails, it is a dangerous
tool. Folks confusing "a" and "ip4" should buy a product or
get professional help. You've written a validator. Folks not
willing or unable to check their policy before going live with
an SPF FAIL are a public danger.
Frank
-------------------------------------------
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