Frank Ellermann wrote:
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.
The localpart may require different encodings if it is used for DNS
lookups, as a CGI parameter in a URL, or for internally looking up the
user db. The third case is not interesting for SPF, but it may be so
for an MTA if it does other funny things with a user's ID, e.g. digest
auth. Unfortunately, the alphabet we use doesn't allow a third case
beyond %{l} and %{L}. Does that call for additional macro transformers?
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.
When spf-eai says "The local part MUST NOT be transformed" it implies
that %{l} cannot be used for DNS lookups if internationalized local
parts are present. I would tend to agree, as I think people sharing
the same domain name should agree on a common policy. However, that
might be an issue for larger organizations whose users disagree about
what SPF policy they want.
To simplify, consider the case of 50% users prising "v=spf1 +all",
while the other 50% insist on "v=spf1 +mx -all". What should the
postmaster do?
[...]
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.
OTOH the attackers will have a hard time explaining to a court why
exactly they did publish that policy.
What is unfair in that scenario is that the risk is not burdening the
server that publishes the risky policy.
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.
The term "problematic" doesn't appear in spf-eai either.
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.
Fair enough! An implementation should accept a list of DNSBLs that it
is allowed to query. As a special case, it can safely be allowed to
query the domain where the spf record itself is coming from, i.e.
given MFROM is someone(_at_)example(_dot_)com it is possible for postmasters
there to publish, say, "include:%{l}.users.example.com". They do it at
their own risk. (Part of this consideration is independent of whether
the local part is involved in the query.)
Conversely, it seems quite unlikely that an external domain knows so
much about local parts at example.com that querying it makes sense.
The only case I can think of is organizations supplying such
particular service. Relevant organizations can then be included in the
fixed list of domains that can always be queried. (Or should queries
involving the local part require an additional authorization bit?)
That implies amending RFC4408.
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.
I can log a query, but I won't know if it passed or failed.
OTOH why should receivers interested in PASS or FAIL spend
parts of their time and bandwidth to support your logging
efforts ?
For the same reason they bother sending DSNs: cooperation.
That has the decent charme of tracking cookies
and "Web bugs"... :-(
Huh... what was that?
-------------------------------------------
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