Resolution of The SPF/Sender-ID Experiment
draft-ietf-spfbis-experiment-05
SPFBIS Working Group M. Kucherawy
Internet-Draft Cloudmark
Intended status: Informational April 19, 2012
Expires: October 21, 2012
Resolution of The SPF/Sender-ID Experiment
draft-ietf-spfbis-experiment-05
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 experiment thus created can be considered
concluded, and a single protocol can be advanced. 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 21, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kucherawy Expires October 21, 2012 [Page 1]
Internet-Draft SPF/Sender-ID Experiment April 2012
This document is subject to BCP 78 and the IETF Trust's Legal
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 . . . . . . . . . . . . . . . . . . . . 4
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. Informative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Experiences Developing SPF . . . . . . . . . . . . . 9
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Kucherawy Expires October 21, 2012 [Page 2]
Internet-Draft SPF/Sender-ID Experiment 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 policy
statement and some specific (but different) logic to evaluate whether
the email client sending or relaying a message was authorized to do
so.
Due to the absence of consensus behind one or the other, and because
Sender-ID supported use of the same policy statement defined by SPF,
the IESG at the time was concerned that an implementation of
Sender-ID might erroneously apply that statement to a message and,
depending on selected recipient actions, could improperly interfere
with message delivery. As a result, the IESG required the
Show full document text