Frank Ellermann wrote:
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.
I have received some mail from t-online.de, from my German
friends. It looks to me that t-online does not use their MX
servers for outgoing mail. All the mail I received from
t-online.de is from servers like:
mailout09.sul.t-online.com (194.25.134.84)
I've seen servers as high as mailout11.sul.t-online.com
(194.25.134.85)
So anyone who uses t-online and publishes mx:t-online.de is
dreaming, and will have their mail bounced, as *NO OUTGOING MAIL
goes through mx:t-online.de*
I even have some DSN's from t-online, and even their bounces go
through the mailout servers, as shown by the headers below:
Return-Path: <>
Received: from sun.ohmi.org ([unix socket])
by sun (Cyrus v2.2.10-Invoca-RPM-2.2.10-3.fc3) with LMTPA;
Sat, 19 Mar 2005 10:16:03 -0500
X-Sieve: CMU Sieve 2.2
Received: from mailout03.sul.t-online.com
(mailout03.sul.t-online.com [194.25.134.81]) by
sun.ohmi.org (8.13.1/8.13.1) with ESMTP id j2JFG37m031979
for <root(_at_)sun(_dot_)ohmi(_dot_)org>; Sat, 19 Mar 2005 10:16:03
-0500
Received: from mailin19.aul.t-online.de
by mailout03.sul.t-online.com with smtp
id 1DCfgI-0006sV-03; Sat, 19 Mar 2005 16:16:02 +0100
X-Failed-Recipients: bounceme_opsdiso(_at_)t-online(_dot_)de
From: Mail Delivery System <Mailer-Daemon(_at_)t-online(_dot_)de>
To: root(_at_)sun(_dot_)ohmi(_dot_)org
Subject: Mail delivery failed: returning message to sender
Message-Id: <1DCffV-000ogD0(_at_)mailin19(_dot_)aul(_dot_)t-online(_dot_)de>
Date: Sat, 19 Mar 2005 16:15:13 +0100
X-TOI-MSGID: 472d4398-2f1a-457b-9bad-8d78caa175dd
It looks to me like if anyone is using t-online.de for their
vanity domain *cannot publish a good SPF record* until T-Online
publishes an SPF record. If you still insist on publishing one,
you are only guessing at T-online's configuration.
Have you ever sent mail through t-online have it was delivered
after being checked for SPF records?
Because of the evidence I have shown, t-online.de is not a valid
study case. By extension, ISPs who refuse to publish SPF records
cannot be relied upon for building SPF records of vanity domains,
because outgoing mail rarely goes through MX servers in large
installations. Look at groups.yahoo.com. That's why the
trusted-forwarder.org map was invented, for all the bozo domains
that don't publish their own records. At best, even
trusted-forwarder.org is a wild guess, a stab in the dark.
Please base your arguments on ISPs other than t-online.de.
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.
I don't think so. If a client implements SPF, and makes decisions
based on SPF results, it should never return 'none' when a record
is indeed published. If it does not check SPF, it should not give
an SPF result.
So _if_ it checks SPF, it MUST do {limit} queries. Otherwise it
is not SPF compliant. If it does not check SPF, it's not governed
by the SPF spec.
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.
I think I do understand MUST. It means non-optional, non-negotiable, right?
Hundreds of patent holders and FUSSP iventors only wait
for a stunt like this, and then kill SPF with a reason.
Explain why please?
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.
You will find that I subscribe to the same theory that all clients
must behave the same. All clients compliant to the same specification.
If you're afraid of differences in behaviour of clients compliant
to different specs, or different revisions of the same spec, your
fears are justified, there will be differences. That's why what
we have now is a *DRAFT*, not a standard. When it becomes a
standard, then I expect all clients to behave the same. Until
then, they can pick which draft they choose to implement. That's
how drafts work, (un)fortunately.
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.
I agree. An implementation guide of some sort is needed. Most of the DOS
-related recommendations belongs there.
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.
See above.
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.
It think it handles the "iburnu.com" worm quite poorly, to my
understanding. No-one has ever denied it, or had any arguments against it.
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.
The limit of 10 I'm not hard set on, but I believe 40 too high.
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)
I will look at pobox.com, but not with t-online.com, due to the evidence
I presented above:
v=spf1
mx
mx:fallback-relay.%{d}
a:webmail.%{d}
a:smtp.%{d}
a:outgoing.smtp.%{d}
a:discard-reports.%{d}
a:discards.%{d}
mx:store.discard.%{d}
a:emerald.%{d}
redirect=%{l1r+}._at_.%{o}._spf.%{d}
The %d can only expand to pobox.com. it is used to save a few
bytes smtp.%{d} is 9 bytes, smtp.pobox.com is 14 bytes.
So all the hostnames that end in %{d} are under the administrative
domain of pobox.com. As such, they are under the control of pobox.com.
As such, they should be replaced with their corresponding IP addresses:
v=spf1 ip4:208.210.124.70 ip4:207.8.226.2 ip4:208.210.124.73
ip4:207.8.226.3 ip4:208.58.1.193 ip4:208.58.1.194
ip4:208.58.1.198 ip4:208.58.1.197 ip4:207.106.36.222
ip4:207.8.226.9 ip4:207.8.226.5 ip4:208.210.124.98
ip4:207.8.226.6 ip4:208.58.1.199 ip4:207.8.214.2
ip4:208.210.124.83 ip4:208.58.1.200 ip4:207.8.226.12
redirect:%{l1r+}._at_.%{o}._spf.%{d} -all
By the time the redirect is expanded, 2 DNS queries have been used up.
That leaves {limit}-2 available for the customer's use. I think 8 is
plenty, thus the proposed limit of 10.
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
So there are a few policies published. I'd love to have a
complete list, so I can run some statistics on how many of them
would have to change (ie, how many are more expensive of 10
queries). Perhaps its not as many as you think. I would also look
at how many of those are more expensive than they need to be. We
have some time until the draft will become a standard.
I would think that if fewer than 1/10th have to change, it's
worthwhile getting them to change.
Is this list available anywhere?
These domains believe in SPF, and they believe it is POSSIBLE for it to
work. they are willing to publish some DNS records, and do at least a
little bit of thinking about this SPF. What makes you think it's
impossible to get the existing, early-adopter publishers to change their
record ?
Regards,
Radu.