[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Engineering SPF

Let's assume, for the sake of argument, that

   (1) we want the information communicated by the deployed SPF
       protocol---does the administrator of X want IP address Y to be
       able to send mail with return addresses @X?---but

   (2) we've decided that we'll have to change how this information is
       retrieved through DNS---leaving the current software alone would
       be nice but the protocol design is simply too painful.

How, then, should the administrator of X use DNS to publish information
about various IP addresses Y? How can we handle the problems of large
packets, subdomains, etc.? I'd like to see this how-to-use-DNS question
discussed separately from questioning assumption #1 (and #2).

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. The hotmail administrator, for example, would have records such as

   *.spf63784604719468285133.hotmail.com. TXT "n"
   *.137.2.199.spf63784604719468285133.hotmail.com. TXT "y"
   ...

rather than the current multiple-level spf-*.hotmail.com structure. The
63784604719468285133 tag serves the same function as an underscore and a
new record type, without the interoperability problems of an underscore
and without the interoperability problems of a new record type.

This initial spreading of queries appears to remove the need for other
forms of indirection, so clients become much simpler and the efficiency
problems of the current SPF protocol go away.

Comments?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

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