"Scott Kitterman" <spf2(_at_)kitterman(_dot_)com> wrote in message
news:20060507145405(_dot_)ACEEDB4897(_at_)portent(_dot_)listbox(_dot_)com(_dot_)(_dot_)(_dot_)
For all intent and purpose it places an artificial limit on
the total domains (10) a large site may use.
No it doesn't. It says that beyond a certain level of complexity
the outbound network needs to be described in terms of IP addresses
or using exists:.
We will have to agree to disagree on the semantics because for all intent
and purposes the LOOKUP limit is 10 regardless of your complexity or
simplicity. That's a LIMIT placed on an large corporation. If that means
they need to roll up their sleeves and base thier SPF design using the
artificial 10 DNS lookup, fine. It is still a 10 limit regardless how you
wish to look at it.
Does the docs say anything like so?
"SPF operators MUST construct SPF records that do not violate
a 10 DNS Lookup limit."
If not, then it should of if you want it to be consistent. The limits are
described from a verifier standpoint only. Not from a construct standpoint
and we know that there are thousands of sites who are just publishing
records. They don't have SPF verifier support yet.
Also, do any of the SPF record Wizards check and limit the DNS lookup
construct based on what the operator defines?
Looks look at the docs, there is two 10 limits statements per MX and PTR,
but then in section 10.1, it says:
| When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
| there MUST be a limit of no more than 10 MX or PTR RRs looked up and
| checked.
| SPF implementations SHOULD limit the total amount of data obtained
| from the DNS queries.
These two are not consistent. It has a MUST in the first, and a SHOULD in
the second. Not consistent. The two sentences should be reverse with the
intro of the SHOULD limit, then moving into the example specifics.
I'd encourage you to go back and review the archives. While 10
was arrived at emperically based on list consensus, there is more
to it than a swag.
Well, I try to keep with the highlights. I recall I myself mentioning the
need to lower the recursive limit. IF the debate kept going to an overall
limit, I don't recall it, and clearly, if there was a consensus it was one
of the "small suite" of people consensus. No full thought was put into the
repercussions. How do I know that? Look at what happen. It would been
extremely clear that 10 was way too low.
There are ways to deal with this. As an example, query the a
records for relay.pair.com. That's one mechanism that covers
several physical boxes. Julian already mentioned exists:. The
limits can be worked within. Now that the RFC is out, both records
and SPF libraries need to be updated to conform to it.
Unless you want come here and answer some phone calls when they begin to
call about "Hey, why is this happening now?" I'm not going to break our
classic SPF setup for my customers. Sorry. We have other ways of
addressing DOS attacks. This was a very poor, not so well thought out,
artificial limit and clearly one that was inevitably designed to break
classic SPF setups. How do I know that? Look at what happen.
It has nothing to do with a interoperability issue but a
"human SWAG" artificial limit. Again, this is not a recursive
issue where there was a real security hole concern.
No, it was a DOS concern.
Yes, you said that. But it was a simple answer without foresight. Look at
what happen. It broke a non-threatening Microsoft SPF domain and god knows
how many other large domain sites.
What if a PASS was possible on the 11th DNS lookup for a certain segment of
transactions? the 9th on others thus given the false test bed illusion that
all is fine?
Please see the list archives.
If you can find the threads, that would be great. I'm not to look for it.
But it doesn't matter. Clearly, the decision based on a few people
consensus.
I would think, that if I was in the loop when this was being
decided, I would suggested that the end result should be the same.
If other words, if the complete exhausted result is a SOFTFAIL,
then the cut off would be a SOFTFAIL as well.
This gets into how one deals with an error (not is there an
error). That's a matter of receiver policy and a good topic for
a BCP type document.
Sure, but why wasn't the 10 a "Matter of Receiver Policy?" Clearly this 10
limit was a highly subjective concept. That was a perfect item for a
"MAY/SHOULD" and not a MUST concept and the insight should of expanded on
tracking redundancy as part of the decision making process. Not a flat out
LOOKUP limit.
Anyway, what's written is written. I would love to see what
Microsoft has to say or what they end up correcting it with.
Scott, have you contacted them yet?
No, but I will.
Keep us posted. :-0)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com