Radu Hociung wrote:
I picked 10 because I cannot justify requiring a higher
number
Then abort the evaluation and pretend that you never tried.
Or demonstrate that your limit does not break one of all
existing v=spf1 policies.
Otherwise note this idea for a future spf2.0 or v=spf2.
If you can justify a higher limit, please explain the
configuration you have in mind.
Try a nslookup -q=mx t-online.de and count the 9 queries.
They are not interested in SPF, so that's something a
user of their smtp-relay might do in his sender policy.
Of course irrelevant, you have to show that your limit
cannot cause havoc for existing policies, not vice versa.
You _could_ argue that an overall limit of 40 should be
good enough for any valid policy under spf-classic-00,
and better than the worst case 10+10*10 for attacks.
But anything below 40 is completely out of line, that's
what Scott (IIRC) found for the old RR policy with the
spf-classic-00 limits. He had 78 without these limits,
and 39 with Wayne's limits.
In other words, the client must do 10 queries.
The client "must" not check SPF at all. It can always
say "enough already" and handle it as NONE, maybe with
a local "never try SPF again with this weirdo" list.
But if it does SPF with any other result it MUST follow
the spec without private limits. Love it or leave it.
Anything else is non-conforming, broken, and abuse, all
at the same time, not better than doing PRA on a v=spf1.
Do you understand MUST in an RfC ? This is not the part
about "nice to have" fun stuff. Any serious nitpicker
would shoot me on sight when he sees that I dare propose
to replace 3*10 by 40, but your idea to replace it by 10
is madness.
Hundreds of patent holders and FUSSP iventors only wait
for a stunt like this, and then kill SPF with a reason.
By "authoritative SPF policy" I mean "matching mechanism"
Okay, please say so, "authoritative" has a meaning for DNS.
The SPF terminology with all its directives, mechanisms,
modifiers, matches, redirections, and (the worst) includes
is confusing, but let's stick to it here.
This recommendation means that after you've done the 10th,
you've satisfied the standard, and you may stop and return
PermError. Or you may continue
Wayne needed months if not a year to convince all, that it's
a fundamentally bad idea if every client does what it wants.
A Permerror MUST be identical with all clients for the same
identity, IP, and policy. If a "wizard" or "validator" says
good (bad) policy, it MUST be good (bad) everywhere. Unless
it's a DNS timeout resulting in a TempError, but that's not
in the SPF layer, it's in the DNS layer.
If DNS works without problem and there's no local failure on
the side of the client SPF results MUST be always the same.
That's an essential idea in Wayne's draft, you change it over
my dead body. All Wayne has to do is to remove the hilarious
overall timeout for the SPF layer, which is as irrelevant as
a malloc() returning NULL or a sigterm => TempError or None.
This upper limit is meant for detecting DOS.
You already know that it's a PermError at this moment, and no
conforming SPF implementation would accept this policy after
this point.
Of course you're free to identify an "evil" PermError somehow,
instead of a "normal" PermError, but that's an implementation
detail which should go into a different document like a manual,
not into the SPF spec.
If I'd implement it, maybe I'd note the PermErrors for some
time, and blacklist any broken policy which I've see once too
often. "Receiver policy" => IMHO irrelevant for the SPF draft.
Maybe later a separate BCP if there is a best common practice.
As I have pointed out before, t-online, as an ISP, should
publish
[...]
T-Online may have reasons to ignore whatever we think what is
good for them. Another essential point in SPF, participation
is voluntary, nobody is forced to publish a policy, unless he
really wants it. As long as T-Online has no SPF policy users
better say mx:t-online.de instead of hardwiring IP numbers of
a 3rd party in their policy.
What you really want is RMX without this funny macro language
and the crazy mechanisms. My sympathy, I also think that SPF
is "baroque", but it's what made it in the real world, unlike
RMX. So now let's try to make the best out of what we have.
Can we put t-online.de's case to rest yet?
Sure, users should use mx:t-online.de resulting in 9 queries.
Black-listing is only one of the possible "evasive measures".
Another possibility is to block the incoming IP at the
switch. Another possibility is to also block the domain at
the SMTP server MAIL-FROM/EHLO stage. It really should be up
to the postmaster to decide how to deal with DoS.
Yes, so this is obviously nothing to be discussed in a text
about a "sender policy framework", maybe it's an "SMTP how-to".
That is simply out of the scope of SPF
ACK, it's interesting, and a separate text about it would be
nice. But SPF with something like Wayne's limits stays within
the well-known threats of dictionary attacks etc.
Your table is clear, but I don't agree with 10 (should be 40).
And x+10 (e.g. 50) is only one of several strategies to handle
malicious PermErrors caused by too complex policies.
A real configuration using existing domain names, or a
detailed fictitious configurations will do.
Look at the per-user policies of Pobox. Consider a user with
three ISPs, a DynDNS domain, and a harmless sender policy like
"v=spf1 a mx include:ISP1 include:ISP2 include:ISP3 -all"
Replace include:ISP3 by mx:t-online.de plus 10 (?) As of their
mailouts if the example isn't clear. Using IPs of a 3rd party
is too hot for a normal user, he won't check this daily, and
he would be mad with whoever created the SPF record it it
FAILs as soon as e.g. t-online.de changes one of its IPs.
(I'm a t-online user, you never really know what they do, and
they don't inform their 10 million customers about IP changes
in their mail setup, let alone weeks before the fact)
What's more important, MicroSoft said that there are 750,000
domains with a policy, minus a few with spf2.0 that is v=spf1.
It's impossible to change the rules for these policies. Wayne
with his 3*10 was already at the limit, my 40 is something I'm
not proud of, but your 10 is not more v=spf1, it's wrong. Bye