idnits 2.17.1 draft-andersen-historic-4406-etal-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC4405], [RFC4406], [RFC4407]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4405, but the abstract doesn't seem to directly say this. It does mention RFC4405 though, so this could be OK. -- The draft header indicates that this document updates RFC4406, but the abstract doesn't seem to directly say this. It does mention RFC4406 though, so this could be OK. -- The draft header indicates that this document updates RFC4407, but the abstract doesn't seem to directly say this. It does mention RFC4407 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4405, updated by this document, for RFC5378 checks: 2004-11-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2018) is 2226 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC4405' on line 69 looks like a reference -- Missing reference section? 'RFC4406' on line 74 looks like a reference -- Missing reference section? 'RFC4407' on line 78 looks like a reference -- Missing reference section? 'RFC4408' on line 82 looks like a reference -- Missing reference section? 'RFC6686' on line 87 looks like a reference -- Missing reference section? 'RFC7208' on line 92 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Andersen 3 Internet-Draft LinkedIn 4 Updates: 4405, 4406, 4407 (if approved) March 23, 2018 5 Intended status: Informational 6 Expires: September 24, 2018 8 Status Change for RFCs 4405, 4406, 4407 to Historic 9 draft-andersen-historic-4406-etal-01 11 Abstract 13 This document acknowledges that Sender ID did not pass its 14 experiment, and changes the status of RFCs 4405 [RFC4405], 4406 15 [RFC4406], and 4407 [RFC4407] to Historic. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 24, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Normative References . . . . . . . . . . . . . . . . . . . . 2 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1. Reasoning 57 In 2006, two experiments were started for email authentication: 58 Sender Policy Framework (SPF, RFC 4408 [RFC4408]) and Sender ID (RFC 59 4406 [RFC4406], supported by RFCs 4405 [RFC4405] and 4407 [RFC4407]). 60 After eight years of experimental data (RFC 6686 [RFC6686]), it was 61 clear that SPF remained in widespread use while Sender ID did not. 62 RFC 7208 [RFC7208] moved SPF from Experimental status to Proposed 63 Standard. This document acknowledges that Sender ID did not pass its 64 experiment, and changes the status of RFCs 4405 [RFC4405], 4406 65 [RFC4406], and 4407 [RFC4407] to Historic. 67 2. Normative References 69 [RFC4405] Allman, E. and H. Katz, "SMTP Service Extension for 70 Indicating the Responsible Submitter of an E-Mail 71 Message", RFC 4405, DOI 10.17487/RFC4405, April 2006, 72 . 74 [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 75 RFC 4406, DOI 10.17487/RFC4406, April 2006, 76 . 78 [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail 79 Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, 80 . 82 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 83 for Authorizing Use of Domains in E-Mail, Version 1", 84 RFC 4408, DOI 10.17487/RFC4408, April 2006, 85 . 87 [RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework 88 (SPF) and Sender ID Experiments", RFC 6686, 89 DOI 10.17487/RFC6686, July 2012, 90 . 92 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 93 Authorizing Use of Domains in Email, Version 1", RFC 7208, 94 DOI 10.17487/RFC7208, April 2014, 95 . 97 Author's Address 99 Kurt Andersen 100 LinkedIn 101 1000 West Maude 102 Sunnyvale, CA 94085 104 Phone: +1 208 252 5488 105 Email: kurta@linkedin.com