Resolution of The SPF and Sender ID Experiments
draft-ietf-spfbis-experiment-06
SPFBIS Working Group M. Kucherawy
Internet-Draft Cloudmark
Intended status: Informational April 24, 2012
Expires: October 26, 2012
Resolution of The SPF and Sender ID Experiments
draft-ietf-spfbis-experiment-06
Abstract
In 2006 the IETF published a suite of protocol documents comprising
SPF and Sender ID, two proposed email authentication protocols.
Because of possible interoperability issues, particularly but not
only those created by simultaneous use of the two protocols by a
receiver, the IESG was unable to determine technical consensus and
decided it was best to publish all of RFC4405, RFC4406, RFC4407 and
RFC4408 as Experimental documents. The IESG invited the community to
observe their deployments for a period of time, and expressed hope
for later convergence of opinion.
After six years, sufficient experience and evidence have been
collected that the experiments thus created can be considered
concluded. This document presents those findings.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Kucherawy Expires October 26, 2012 [Page 1]
Internet-Draft SPF/Sender ID Experiments April 2012
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Evidence of Deployment . . . . . . . . . . . . . . . . . . . . 3
3.1. DNS Resource Record Types . . . . . . . . . . . . . . . . 4
3.2. Implementations . . . . . . . . . . . . . . . . . . . . . 5
3.3. The SUBMITTER SMTP Extension . . . . . . . . . . . . . . . 5
4. Evidence of Differences . . . . . . . . . . . . . . . . . . . 6
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Background on the RRTYPE Issue . . . . . . . . . . . 9
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Kucherawy Expires October 26, 2012 [Page 2]
Internet-Draft SPF/Sender ID Experiments April 2012
1. Introduction
In April 2006, the IETF published the [SPF] and Sender ID email
authentication protocols, the latter consisting of three documents
([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols
enable one to publish via the Domain Name System a policy declaring
which mail servers were authorized to send email on behalf of a
specific domain name. The two protocols made use of this same policy
statement and some specific (but different) logic to evaluate whether
the email client sending or relaying a message was authorized to do
so.
Consensus did not clearly support one protocol over the other, and
there was significant concern that the two would conflict in some
significant operational situations, interfering with message
delivery. The IESG required the publication of all of these
Show full document text