Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
draft-schlitt-spf-classic-02

[Ballot discuss]
A quick check with some DNS experts raises concerns with the following:

>> Finding a zone cut is complicated process as zones can be
>> multiple labels deep, and have wild cards. Further making things
>> difficult is that different DNS servers return different (but valid)
>> answers when queried Q-Trinity does not exist.
>> The algorithm proposed is non existing as RFC2181 just formalizes the
>> name "zone cut".
>> On the flip size with DNSSEC it is trivial to find Zone cut, just
>> use the signers name in the RRSIG :-)


What he said.

[Ballot comment]
In my opinion, a custom IESG note is appropriate.  Some of the points
  raised by David Kessens should be captured there.
 
  It would be nice if a lessons learned document was to come along.  What
  was wrong with SPF version 1 that lead to the creation of SPF version 2?

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

His review:

This specification is about ready for publication as an
Experimental RFC. It's pretty clear, and provides good
background for its design choices (I wish all specifications
were this aware of "why").

The IANA Considerations section is very minimal.

I have some concerns about security considerations, but the
specification does explicitly call all of mine out, so they
shouldn't be news to anyone. Good luck in addressing them, in
the experiment!

I do have one suggestion - the specification is pretty casual
about this being "SPF Version 1" (the version number isn't
mentioned until the top of page 10).

Since this specification is being written specifically because
there are a variety of SPFs, and I'm assuming we expect more
SPFs (otherwise, why experimental?), so it seems like we should
have "Version 1" in the title of the document.

[Ballot comment]
I believe that this solution abuses the DNS.

The DNS was designed as a simple name to address mapping. The DNS is not
a very good general purpose database and this solution uses it as such.

I would have much preferred a solution that would be an extension to SMTP
that simply checks back with one of the official MTA machines as listed in the
'mx' records for the domain whether the sending machine can be accepted,
or just one simple DNS record with the name of the machine which is capable
of doing the verification. The
resulting protocol would be much simpler as all the configuration of the
MTA doesn't need standarization as this information would not need to be
published since it is not needed by any other than the 'mx' domain.

From an operational perspective, the DNS solution also has issues since
the DNS administrator is not necessarily the same as the mail administrator.

However, the document states:

"The goal of this document is to clearly document the protocol defined
by earlier drafts specifications of SPF as used in existing
implementations."

As such, I believe that is better to have the mechanism documented.