On Tue, 2005-04-05 at 15:53 -0700, David MacQuigg wrote:
At 08:19 AM 4/5/2005 -0700, Douglas Otis wrote:
The current draft-schlitt-spf-classic-00, Dec 2004, sets a maximum of 10
lookups. There is still a risk of abuse, even with 10. See my previous
response to John Leslie on the DNS load question.
The rr.com record was initially in spec at 78 DNS lookups. You have
misread this poorly phrased limit in Schlitt's draft. This is a limit
of 10 mechanisms that perform DNS lookups. Each mechanism may employ 10
elements that require a lookup. That would be 10 x 10 or 100 plus the
initial record. There is also a reverse DNS mechanism requiring
comparison to a forward DNS lookup against any number of items returned
by each element. It would be hard to put a limit on such a
forward/reverse comparison process, but it could easily exceed several
hundred lookups.
You are not describing SPF, this is a special case. SPF requires a
minimum of hundreds of DNS lookups. You may hope that someone like
rr.com has taken the time to compress their lists. You are still left
with SPF baggage that dominates the spectrum.
Stats show that the vast majority of current SPF records fit within the
limit of 10 lookups.
DNS is running over UDP. Each lookup may average 5 queries. Each query
may have an initial 5 second timeout and retry 3 times. To ensure UDP
traffic does not cause network congestion, each timeout doubles the
period before a subsequent retry. Even running without a timeout, this
process may already exceed 4 minutes for these 10 lookups. You may also
notice SPF violates an exponential UDP back-off requirement by
timing-out the SPF process at 20 seconds. CSV does not recommend
violating network congestion algorithms, nor does it have such need.
With the 100 or more lookups required by SPF, this process could take
hours to resolve, when done properly.
As for the "baggage" in SPF, I think that will eventually disappear. SPF
made a mistake (in my opinion) by adding some sophisticated features with
potential for abuse. They may have had to do this to gain acceptance from
mail system admins who would refuse to adopt SPF if even the smallest
change was required in their bizarre mail setups. Whatever the reason, SPF
is now having to backpedal and discourage the use of these features.
There is no ability to back pedal without publishing a different record
with a different algorithm. May I suggest CSV would be a good start.
Another real danger is created by Microsoft promoting a different
algorithm for the same record. You may attempt to assure the
bounce-address, but they then dock the PRA. Understand that neither SPF
or Sender-ID provides mailbox-domain authentication.
This has to be done in a way that doesn't break existing setups. The new
"mask" feature, if designed properly, should allow most authentications to
be done in one query, and still keep the old SPF mechanisms if more queries
are necessary. This should provide a smooth migration path from the
current complex syntax to a much simpler list of IP blocks. Eventually the
old syntax can be deprecated.
Eventually signatures should remove the need to categorize all the
addresses for an entire mailbox-domain. There remains the problem seen
with forwarding and some list servers. Signatures and CSV can keep the
number of lookups to a minimum, while conquering many problems still
ignored by SPF/Sender-ID. CSV and signatures provide authentication,
while not assuming universal adoption or intervening security.
And how does this overcome the forwarding problem? How does this
utilize the advantages gained by a signature? CSV still provides the
most expedient means to obtain an authenticated domain at each hop.
Reputation based upon an authenticated entity is the only safe means to
abate abuse. No mailbox-domain is authenticated using SPF. SPF only
indicates the client has been authorized. Authorization is useless from
a reputation standpoint. SPF does not prevent forgery.
I agree with you that SPF has a problem with forwarders. The faulty
assumption is that the sender will always have a prior arrangement with the
forwarder, or at least be able to count on the forwarder not moving things
around too much. There is lots of wailing when this just doesn't
happen. The latest culprit is blockbuster.com. I think the SPF folks will
eventually realize they have to authenticate each hop independently.
CSV got it right on how to handle forwarders. I think there is still a
ways to go on reducing the DNS load. ( See my reply to John Leslie.) I
don't like having to set up DNS records for every server, but that is just
an inconvenience. If I had to do it for a hundred servers, I would
probably write a little script.
The real trouble for SPF happens when Microsoft et al applies reputation
to the mailbox-domain. False assumptions of authentication will become
apparent, by injuring typical email consumers. One must also hope SPF
exploits do not become endemic as well.
-Doug