Subject: Re: Engineering SPF

From: John Levine <[email-masked]>
Date: 15 Jan 2005 04:34:26 -0000

>Most of the problems of the current protocol design appear to be caused
>by crunching information about all the Y's into a single DNS record for
>X. The client is actually interested in a particular Y, and can simply
>ask about, say, Ztruncto63.reverse(Y).spfidentifier.X for return address
>Z@X.

Back when the ASRG LMAP group was active, this question was argued at
length.  I characterized the two approaches as block data, where all
of the valid IPs for a domain are retrieved as a group, and factored
data where the info for each (domain,IP) pair is stored under a
separate name.  SPF and Hadmut Danisch's RMX are the best known block
schemes, and Gordon Fecyk's DMP the best known factored.  I offered
a strawman called FSV that "panders to both factions" and provided both.

RMX basically published lists of CIDR ranges per domain using proposed
RMX and APL (CIDR range set) records.  DMP used names like
1.2.0.192.in-addr._smtp-client.example.com to identify valid and
invalid hosts, putting the reversed IP at the front so you could use
wildcards to help publish info for large IP ranges with the same data,

I think I can summarize the arguments for of each side, even
though I don't necessarily believe them.

For factored records: 

Good: They're easy to check, possibly using a variation of the code
used now to check DNSBLs.  Since you make exactly one query per
message, performance is predictable and fast.

Bad: A large domain may need a whole lot of records, e.g., AOL's SPF
record factors out to more than 2300 IP addresses and Hotmail's, if
you believe it, factors out to over 500,000.  If you send mail through
your ISP, you're at the mercy of the ISP to find out what their
sending hosts are. For DMP you could probably use a CNAME to alias
_smtp-client.littledomain.org to _smtp-client.bigisp.net (or would
that need a DNAME?)

For the common case where a small set of IPs are marked "yes" and the
rest of them should be marked "no", it can be challenging to publish all
the wildcards needed to cover all of the "no" values.  In FSV I just
published records for "yes" and had a distinguished name you could check
to tell whether the domain published FSV and hence whether to interpret
the lack of of a "yes" as a "no" or unknown.  

For block records: 

Good: Microsoft argued quite vehemently that the DNS cost of checking
block records was vastly lower than factored records.  Some mail
servers use a process per SMTP session (qmail), and others have one
big long-running process with threads (Exchange).  If your MTA is of
the latter variety, the MTA can slurp up block records and cache their
data internally which they said is a lot faster.  I think this says
more about lousy DNS caches than about DNS performance, but what do I
know?

SPF is intended to be easy to publish even if hard to decode, on the
theory that every domain owner that sends mail needs to be able to
publish SPF records, but only the 12 people in the world who maintain
MTAs need to know how to decode them.  That's why it has the zillion
features to provide indirect references of various sorts.

Bad: 

Records for large domains can potentially be big, causing various big DNS
record problems.

For SPF in particular, interpreting the records can take arbitrarily
long and arbitrarily many DNS references (give or take the indirection
limits which give you predictable worst case performance at the cost
of unpredictable results.)  RMX has one level of indirection, from RMX
records to APL CIDR range records, with the expectation that the
little domain can refer to its ISP's APL record.

I need hardly remind people that SPF's victory over competing path
authorization proposals had nothing to do with their relative
technical merits, but if you care about those merits, that what we
thought they are.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>