Internet DRAFT - draft-moonesamy-senderid-spf-conclusion
draft-moonesamy-senderid-spf-conclusion
Individual Submission S. Moonesamy
Internet-Draft February 15, 2012
Obsoletes: 4405, 4406, 4407
(if approved)
Intended status: Informational
Expires: August 18, 2012
Conclusion of SenderID and SPF experiments
draft-moonesamy-senderid-spf-conclusion-00
Abstract
This memo concludes the SMTP Service Extension for Indicating the
Responsible Submitter of an E-Mail Message (RFC4405), Sender ID:
Authenticating E-Mail (RFC4406), Purported Responsible Address in
E-Mail Messages (RFC4407) and Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail, Version 1 (RFC4408),
experiments.
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 August 18, 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
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
Moonesamy Expires August 18, 2012 [Page 1]
Internet-Draft SenderID and SPF conclusion February 2012
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
1.1. Strawman proposal . . . . . . . . . . . . . . . . . . . . . 3
2. Issues identified by the IESG . . . . . . . . . . . . . . . . . 3
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. DNS Records for SenderID and SPF . . . . . . . . . . . . . 4
3.2. Resent header fields . . . . . . . . . . . . . . . . . . . 4
3.3. Implementation of SUBMITTER SMTP service extension . . . . 5
4. Outstanding issues . . . . . . . . . . . . . . . . . . . . . . 5
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. Informative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Moonesamy Expires August 18, 2012 [Page 2]
Internet-Draft SenderID and SPF conclusion February 2012
1. Introduction
In April 2006, RFC 4405 [RFC4405], SMTP Service Extension for
Indicating the Responsible Submitter of an E-Mail Message, RFC 4406
[RFC4406], Sender ID: Authenticating E-Mail, RFC 4407 [RFC4407],
Purported Responsible Address in E-Mail Messages and RFC 4408
[RFC4408], Sender Policy Framework (SPF) were published
simultaneously as Experimental RFCs. There was no general technical
consensus about how to reconcile the two approaches known as Sender
ID [RFC4406] and SPF [RFC4408].
This memo concludes the Sender ID and SPF experiments by obsoleting
the following RFCs: the SMTP Service Extension for Indicating the
Responsible Submitter of an E-Mail Message [RFC4405], the SMTP
Service Extension for Indicating the Responsible Submitter of an
E-Mail Message [RFC4406], and Purported Responsible Address in E-Mail
Messages [RFC4407].
1.1. Strawman proposal
This memo offers a "strawman" proposal to conclude the SenderID and
SPF experiments.
2. Issues identified by the IESG
The following issues were identified in IESG Note attached to the
Experimental RFCs:
o The Sender ID experiment may use DNS records that 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.
o 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).
In addition, the IESG advised participants publishing SPF experiment
DNS records to follow section 3.4 of RFC 4406 and publish both v=spf1
and spf2.0 records to avoid the conflict.
Moonesamy Expires August 18, 2012 [Page 3]
Internet-Draft SenderID and SPF conclusion February 2012
3. Discussion
3.1. DNS Records for SenderID and SPF
The Alexa top one million web hosts were used as a sample of domains.
287000 of the domains in the sample published SPF records.
+------------+--------+
| Qualifiers | No. |
+------------+--------+
| +a | 223030 |
| +all | 2117 |
| +aspmx | 25 |
| +exists | 1415 |
| +ip | 507 |
| +ip4 | 331927 |
| +ip6 | 833 |
| +ipv4 | 640 |
| +mail | 44 |
| +mx | 215065 |
| +p4 | 27 |
| +ptr | 36507 |
| +spf | 43 |
| -a | 33 |
| -all | 52810 |
| -ip4 | 43 |
| ?all | 53887 |
| ?exists | 66 |
| ~a | 31 |
| ~al | 29 |
| ~all | 164812 |
+------------+--------+
Table 1: SPF qualifiers
4613 of the domains published SPF (Type 99) DNS records.
Approximately 800 of these DNS records do not match the "TXT"
version. 578 domains in the sample published "v=spf2" records.
3.2. Resent header fields
According to RFC 5322 [RFC5322] (Section 3.6.6), Resent fields are
used to identify a message as having been reintroduced into the
transport system by a user. The purpose of using Resent fields is to
have the message appear to the final recipient as if it were sent
directly by the original sender, with all of the original fields
remaining the same. RFC 5322 notes that reintroducing a message into
the transport system and using Resent fields is a different operation
Moonesamy Expires August 18, 2012 [Page 4]
Internet-Draft SenderID and SPF conclusion February 2012
from "forwarding"
There is currently no data to determine whether Resent-* headers
fields are being added for participants in the SenderID experiment.
3.3. Implementation of SUBMITTER SMTP service extension
There has not been widespread implementation of the SUBMITTER SMTP
service extension.
4. Outstanding issues
The SPFBIS Working Group was chartered in February 2012 to work on an
update of RFC 4408 [RFC4408]. The following outstanding issues
should be addressed:
o Should DNS RR of type SPF, code 99 be used in an update of RFC
4408?
o Mail forwarding
5. Conclusion
The IESG invited the community to observe the success or failure of
the SenderID and SPF approaches after the publication of the
Experimental RFCs. It is not possible to determine which approach
was a success or failure as the requirements to assess that were not
defined. It is recommended that the experiments be concluded by
obsoleting the SenderID Experimental RFCs. It is the consensus of
the IETF to produce a standards track document, based on RFC 4408
[RFC4408], which defines a Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail.
Given that the SUBMITTER SMTP service extension is not widely
implemented and deployed, its use is deprecated.
6. Security Considerations
Concluding the SenderID and SPF experiments will not cause loss of
mail.
7. IANA Considerations
The following note for the SUBMITTER SMTP extension should be added
Moonesamy Expires August 18, 2012 [Page 5]
Internet-Draft SenderID and SPF conclusion February 2012
in the "SMTP Service Extensions" registry:
The use of SUBMITTER is deprecated by RFC XXXX.
8. Acknowledgements
I would like to thank Philip Gladstone for his research on the usage
of DNS Records for SenderID and SPF and for providing the data in
Section 3.1.
9. Informative References
[RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for
Indicating the Responsible Submitter of an E-Mail
Message", RFC 4405, April 2006.
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, April 2006.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
Author's Address
S. Moonesamy
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
Email: sm+ietf@elandsys.com
Moonesamy Expires August 18, 2012 [Page 6]
