Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 10 Jan 2005 09:19:13 +0100

On Mon, Jan 03, 2005 at 08:41:36PM -0600,
 wayne <[email-masked]> wrote 
 a message of 47 lines which said:

> There is a new I-D for the SPF email anti-forgery system available
> for review.
...
> While SPF mostly deals with the [2]821 SMTP level, it also relies
> heavily on DNS to communicate between the domain owner, and the
> email receiver.  This I-D also makes provisions to create a new RR
> that is just a clone of the TXT RR type.  While I did not make it to
> IETF-61, it is my understanding that Stephane Bortzmeyer made a
> presentation on this subject during the DNSEXT session.

There have been apparently no reply. Does it mean that nobody see
solid problems and that there is a silent and rough consensus that
the I-D can move forward :-)

--
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/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Jan 2005 18:18:06 -0000

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

---

From: wayne <[email-masked]>
Date: Fri, 14 Jan 2005 13:54:24 -0600

In <[email-masked]> "D. J. Bernstein" <[email-masked]> writes:

> Let's assume, for the sake of argument, that [snip]
>

Hi Dan.

Yes, the "how to use DNS?" question has been asked in relation to this
subject many times.  I found the discussion quite interesting, but I'm
not sure that it would be a good idea to rehash it here.  The answer
is one in which I believe that reasonable people can disagree on.
There are a lot of trade-offs involved and depending on how you
consider the various costs, you can end up with very different
answers.

A good overview of this subject was written up by the IRTF's ASRG WG.
See:
http://asrg.kavi.com/apps/group_public/download.php/31/draft-irtf-asrg-lmap-discussion-00.txt

In particular, look at section 4.

>    *.spf63784604719468285133.hotmail.com. TXT "n"

Minor nit, but unless I'm very much mistaken, you also need:

     *.199.spf63784604719468285133.hotmail.com. TXT "n"
     *.2.199.spf63784604719468285133.hotmail.com. TXT "n"

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

This arrangement has a lower cost when you only want to find the
answer once, but has a higher cost if you get a lot of email claiming
to be from hotmail.com.  Spoofed email claiming to be from hotmail.com
gets sent by hundreds of thousands of zombied boxes.

If you like this form, however, you can do it right now with SPF via:

hotmail.com.  TXT  "v=spf1 exists:%{ir}.spf63784604719468285133.%{d} -all"
*.137.2.199.spf63784604719468285133.hotmail.com. A 127.0.0.2

-wayne

---

From: Florian Weimer <[email-masked]>
Date: Fri, 14 Jan 2005 22:46:53 +0100

> problems of the current SPF protocol go away.

I think the indirection/macro expansion capability is actually needed
in practice.  For example, T-Online might want to use DARTmail's bulk
mailing capabilities, and want them to use a @t-online.de addresses
(in order to avoid customer confusion).  With SPF, DARTmail publishes
an SPF record, which T-Online includes (by reference) in its SPF
record for t-online.de.  The effect is that DARTmail can send mail
under the t-online.de domain, and T-Online doesn't have to maintain a
list of DARTmail's mail relays.

I don't think this property is preserved in your proposal.  T-Online
would have to generate responses dynamically, or keep a list of IP
addresses DARTmail's server.

(This message should not be read an endorsement of SPF or similar
technologies.)