Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
RFC 4408

Note: This ballot was opened for revision 02 and is now closed.

(Thomas Narten) Discuss

Discuss (2005-02-17 for -** No value found for 'p.get_dochistory.rev' **)
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.

(Ted Hardie) (was Discuss, Yes) Yes

(Harald Alvestrand) No Objection

Comment (2005-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Brian Carpenter) No Objection

Comment (2005-05-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I have followed Harald's lead = no objection

(Margaret Cullen) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

(Allison Mankin) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(David Kessens) Abstain

Comment (2005-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.