Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org> Subject: Document Action: 'Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, version 1' to Experimental RFC The IESG has approved the following document: - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, version 1 ' <draft-schlitt-spf-classic-03.txt> as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-03.txt
Technical Summary Please see the IESG note. Working Group Summary This was originally part of the work of MARID, which was unable to come to consensus on the appropriate set of scopes and facilities for DNS-based email authentication. Because of that lack of consensus, this work is targeted at Experimental, rather than standards track status. It is hoped that additional deployment will help demonstrate which among the proposed scopes and facilities is useful, and that those can later proceed to standards track status. Protocol Quality This document was reviewed for the IESG by Ted Hardie and by the DEA Directorate for the Applications Area Directors. RFC Editor Note Please update the IESG Note with the RFC Numbers when available. IESG Note "The following documents (draft-schlitt-spf-classic, draft-katz-submitter, draft-lyon-senderid-core, draft-lyon-senderid-pra) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group. The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them. Note that the Sender ID experiment may use DNS records which may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt. Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC XXXX (draft-lyon-senderid-core) and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict. Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem. The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future."