Alessandro Vesely wrote:
>>> I would be against this. I'm not aware of any library
>>> that currently has trouble with macros.
> +1, I don't think it's smart to abjure released features.
As operator I'd use a feature to disable localpart macros
if available, and as implementor I'd consider to add this
feature. I'm biassed after about a dozen flamewars with
Doug Otis on various lists with topic "SPF scripts".
It's also no fun to work on the SPF-EAI draft when half
of it is about localpart issues, they get worse for EAI.
Anything else in SPF works like a charme - also for EAI.
Okay, impementations need the IDNAbis U-label to A-label
(punycode) magic "somewhere", and it would be a pain to
implement this from scratch. But in practice this boils
down to "find libidn", or use ICU, or whatever supports
IDNA(bis) on your platform.
Joke, one thing SPF should not say is that "EAI is only
an obscure IETF experiment" ;-) DKIM cannot support EAI
so far, as usual SPF is the only thing that really works.
At least in theory, excluding localpart macro oddities.
> Being local, it shouldn't harm DNSs. Correct?
NAK. It's hard to extract what Doug really means buried
under tons of *FUD* and a peculiar terminology. Julian
tried to translate this into plain English, check out:
http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis Doug's concern wrt SPF localpart macros is that once a
receiver has a policy with this feature in the DNS cache,
that the cached record can cause various DNS queries to
a victim triggered by varying local parts in an attack.
In an attack the SPF policy doesn't need to make sense.
It can be v=spf1 a:%{l}.a0.victim.example etc. up to a9,
ten queries per unique local part. The attacker owns a
botnet and sends 100,000 mails with unique local parts,
resulting in a million (bogus) queries to the victim.
Modify "100,000" until this starts to cause real harm.
Make sure to use long local parts for longer queries,
or use longer labels than "a0" to "a9". Doug's idea is
to cause as much DNS traffic as possible to the victim.
From various receivers checking SPF for the DDoS effect,
blocking a DoS attack amplified by only one receiver is
too simple.
The localpart macro is required. The queries need to be
different for each mail, otherwise the NXDOMAIN answers
could be cached for some time, resulting in only ten DNS
queries per receiver instead of a million (for 100,000).
Doug's proposal is far more complex involving MX queries
to the attacker, but that is only because he wanted more
*FUD* about an SPF amplification factor greater than 10.
But the factor 10 is no nonsense, it is pure RFC 4408.
>> [...] nobody had the energy to fix this discrepancy.
> Then, we shouldn't be more royalist than the king.
Blasphemy, there are no kings in the IETF... ;-) SPF is
anyway not interested in 2822upd syntax. Otherwise we'd
intervene to get "white space in quoted string" questions
answered. No HTABs as far as RFC 2821bis is concerned,
good enough also for SPF.
> I'd classify those as problematic local parts rather
> than reproach %{l}...
Your classification is certainly confirmed by 2821(bis),
but there's no clear "don't use problematic local parts
if you use %{l}" rule in RFC 4408.
Besides spammers would ignore such a rule if this offers
them a way to bypass SPF policies relying on %{l} macros.
>> 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.
> Do you mean they should not affect the result?
In this statement I meant that these macros are harmless
if used in SPF FAIL explanations behind exp= modifiers.
Elsewhere, "get rid of them" boils down to "abort your
SPF check with a special NONE result whenever a policy
does something you don't like".
E.g. if a sender uses the exists: mechanism to enforce
checks of specific DNSBLs the receivers are free to say:
"Gee, thanks, but *I* decide which DNSBLs I use. That
your SPF policy is syntactically valid does not mean
that I'm *forced* to support your DNSBL choices."
BTW, it also doesn't mean that the receiver is *allowed*
to use a specific DNSBL used in an exists:. Many DNSBL
operators have their own policies wrt DNS query traffic.
>> In practice see subject, less than 0.5 permille use
>> *any* macros, if this statistics is correct.
> I don't think that's correct. One should count the number
> of times a record has been used. However, there's no
> practical way to trace those calls: SPF lacks support for
> statistics, as well as for debugging.
You can certainly log and analyze DNS queries to your own
name servers, and one of the proposed uses of SPF macros
is to get precisely this logging affect. For an example
see the policy of schlitt.net, also explained in RFC 4408.
OTOH why should recivers interested in PASS or FAIL spend
parts of their time and bandwidth to support your logging
efforts ? That has the decent charme of tracking cookies
and "Web bugs"... :-(
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
