The IESG has approved the following document: - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1' (draft-ietf-spfbis-4408bis-21.txt) as Proposed Standard This document is the product of the SPF Update Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ Technical Summary draft-ietf-spfbis-4408bis describes version 1 of the Sender Policy Framework (SPF) protocol, whereby Administrative Management Domains can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. The working group was chartered to produce a document as a Proposed Standard defining the SPF protocol based upon RFC 4408 (Experimental). Working Group Summary This document is a product of the SPFBIS working group, and has been through a large number of revisions including a complete reorganization of the document. The working group dealt with a number of controversial topics. The following outlines how those were resolved: There was an intermediate conclusion about the topic of whether the SPF protocol should use the SPF RRTYPE or the TXT resource record. It was followed by an objection. After discussion of the topic at the IETF 83 SPFBIS WG session the conclusion reached was that the decision would be not to publish RRTYPE 99 and and not to query RRTYPE 99. The WG consensus about the RRTYPE can be described as particularly rough. The topic of obsoleting the SPF RRTYPE generated a lot of controversy near the end of the WGLC. There were a very high number of messages about the topic on the SPFBIS mailing list and the DNSEXT mailing list as some DNSEXT WG participants were not aware of RFC 6686. The topic of whether the SPF protocol has to reject mail or not when the result of the evaluation is "Fail" was actively discussed. It was determined that it was a matter of local policy. There was discussion about standardizing the "best guess" heuristics to guess possible SPF policies for domains that do not publish an SPF record. The WG consensus was not to standardize the heuristics. The topic of mail forwarding and mailing lists in respect to the SPF protocol was not too controversial in comparison with the other controversies. The WG consensus was to have the document discuss about the topic in a non-normative manner. There was some controversy about whether the use of macros was a security risk and whether to deprecate the PTR feature. There was a formal appeal of the SPFBIS WG chair' interpretation of the charter, specifically regarding the removal of "unused" features. The two features in particular which drove the appeal were the PTR feature and the local-part macro feature. These features were not removed from the document given that the appeal was denied by the Responsible Area Director. There was significant discussion about whether to use the "Received-SPF:" header field or whether to use the "Authentication-Results" header field to record the results of a SPF evaluation. The working group decided to add both header fields in the document as they are in common use. There was a suggestion to reorganize the document. It was argued that the document had become somewhat bloated with documentation of nuance and other text that has nothing to do with defining a protocol and enabling interoperability. This led to a stalemate. Based on the discussion during the SFPBIS WG session at IETF 85 the WG decided to proceed with a reorganization of the document while ensuring that the reorganization did not create any text changes apart from moving text around. There is rough consensus within the SPFBIS WG to publish the document. Some WG participants have mentioned that they may express extreme discontent about the decision to obsolete the SPF RRTYPE during the Last Call. Document Quality There are multiple existing implementations of the SPF protocol. The document was reviewed by the SPFBIS working group. Dave Crocker, Stuart Gathman, Murray Kucherawy, John Levine, Hector Santos, Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the document. Simon Perreault helped to clarify the meaning of IPv4 mapped IPv6 addresses. Murray Kucherawy deserves a special mention for his contributions. The document was reviewed by Cyrus Daboo on behalf of the Applications Area Directorate. Meral Shirazipour reviewed the document for Gen-ART and Phillip Hallam-Baker performed the Security Directorate review. Personnel S. Moonesamy is the Document Shepherd for this document. Pete Resnick is the Responsible Area Director. RFC Editor Note Please note that the charter of this WG was to produce a document that minimizes changes from RFC 4408. When copy editing is done, please compare to RFC 4408 and try to minimize copy edits that might accidentally change the meaning from there. Also note that I have added citations for each of the "Works in Progress". I don't know if the RFC Editor needs those; strike them if they aren't needed. Please change the following, as agreed by the WG: Section 4.6: OLD The check_host() function parses and interprets the SPF record to find a result for the current test. If there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation. END NEW The check_host() function parses and interprets the SPF record to find a result for the current test. The syntax of the record is validated first, and if there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation or evaluation. END Section 5.5: OLD Pseudocode: sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 sending-domain_names are found, use at most 10. for each name in (sending-domain_names) { IP_addresses := a_lookup(name); if the sending-domain_IP is one of the IP_addresses { validated-sending-domain_names += name; } } for each name in (validated-sending-domain_names) { if name ends in <target-name>, return match. if name is <target-name>, return match. } return no-match. END NEW END (That is, delete the above bit.) Section 15.2: OLD [DMP] Fecyk, G., "Designated Mailers Protocol". Work In Progress [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. NEW [BATV] Levine, J., "Bounce Address Tag Validation (BATV)", 2008. Work In Progress (draft-levine-smtp-batv-01.txt) [DMP] Fecyk, G., "Designated Mailers Protocol". Work In Progress (draft-fecyk-dmp-02) [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. Work In Progress (http://www.mhonarc.org/archive/html/ietf-asrg/2003-03/msg01525.html) END OLD [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender authentication". Work In Progress NEW [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender authentication". Work In Progress (draft-danisch-dns-rr-smtp) END Appendix D.1: OLD Note that due to the 63-character limit for domain labels, this approach only works reliably if the local-part signature scheme is guaranteed either to only produce local-parts with a maximum of 63 characters or to gracefully handle truncated local-parts. NEW Note that due to the 63-character limit for domain labels, this approach only works reliably if the local-part signature scheme is guaranteed either to only produce local-parts with a maximum of 63 characters or to gracefully handle truncated local-parts. The method used to secure the localpart is a local implementation issue, it need not be standard. An example of one way to do it can be found in [BATV].
