Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
Note: This ballot was opened for revision 02 and is now closed.
(Thomas Narten) Discuss
Discuss (2005-02-17 for -)
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 -)
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 -)
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 -)
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.