Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
draft-schlitt-spf-classic-02
Discuss
Yes
(Ted Hardie)
No Objection
(Allison Mankin)
(Bert Wijnen)
(Margaret Cullen)
(Mark Townsley)
(Russ Housley)
(Scott Hollenbeck)
Abstain
Note: This ballot was opened for revision 02 and is now closed.
Thomas Narten Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2005-02-17)
Unknown
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 Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-05-26)
Unknown
I have followed Harald's lead = no objection
Harald Alvestrand Former IESG member
No Objection
No Objection
(2005-02-03)
Unknown
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.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2005-06-20)
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
Abstain
Abstain
(2005-02-03)
Unknown
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.