idnits 2.17.1 draft-wmills-rrvs-header-field-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Mills 3 Internet-Draft Yahoo! Inc. 4 Intended status: Informational M. Kucherawy 5 Expires: January 16, 2014 Facebook, Inc. 6 July 15, 2013 8 The Require-Recipient-Valid-Since Header Field 9 draft-wmills-rrvs-header-field-00 11 Abstract 13 This document defines an email header field, Require-Recipient-Valid- 14 Since, to provide a method for senders to indicate to receivers the 15 time when the sender last confirmed the ownership of the target 16 mailbox. This can be used to detect changes of mailbox ownership, 17 and thus prevent mail from being delivered to the wrong party. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 16, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Mailbox Service Providers (MSPs) are public, often free, services 69 that provide email sending and receiving capabilities to users. Some 70 of them have policies that allow for expiration of account names when 71 they have been unused for a protracted period. If an expired account 72 name can be reclaimed, there is a risk of delivery of mail to the 73 wrong party if some message author is unaware of this change of 74 ownership. 76 This document defines a header field called Require-Recipient-Valid- 77 Since. The content of this header field is a timestamp indicating at 78 what point in time the message author believed the address to be 79 under confirmed ownership of a specific party. If the receiving 80 system observes this field and can determine that the intended 81 recipient mailbox has changed ownership since the provided timestamp, 82 it can decline delivery, preventing possible misdelivery of mail. 84 2. Definitions 86 For a description of the email architecture, consult [EMAIL-ARCH]. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [KEYWORDS]. 92 3. Description 94 The Require-Recipient-Valid-Since header field includes the original 95 intended recipient coupled with a timestamp indicating the most 96 recent date and time when the message author believed the destination 97 mailbox to be under the continuous ownership of a specific party. 98 Presumably there has been some confirmation process applied to 99 establish this ownership; however, the methods of making such 100 determinations is a local matter and outside the scope of this 101 document. 103 The general constraints on syntax and placement of header fields in a 104 message are defined in Internet Message Format [MAIL]. 106 Using Augmented Backus-Naur Form [ABNF], the syntax for the field is: 108 rrvs = "Require-Recipient-Valid-Since:" mailbox; date-time CRLF 110 "CFWS" is defined in Section 3.2.2, "date-time" is defined in Section 111 3.3, and "mailbox" is defined in Section 3.4, of [MAIL]. 113 A receiving system that implements this specification determines 114 whether the named mailbox is based at that receiving system, and has 115 been under continuous ownership since the specified date. If that 116 address is found to be foreign, the header field is ignored. 117 Otherwise, if continuous ownership since the indicated time can be 118 established, the message is delivered normally; if not, the message 119 is rejected. It is preferred that the rejection be enacted as an 120 error response to the Simple Mail Transfer Protocol [SMTP] "DATA" 121 command verb, but this is not strictly necessary. 123 When enacting the "DATA" rejection, servers use an SMTP error code 124 (and Enhanced Mail System Status Code [ESC], if supported) that 125 indicates the intended recipient cannot receive mail for policy 126 reasons. This is done because the mailbox identified in the header 127 field does exist, but there is doubt about the identity of the owner 128 of that mailbox. By contrast, "no such user" errors are more 129 commonly returned in reply to the "RCPT" command verb. 131 Implementation is expected to be transparent to non participants, 132 since they would typically ignore this header field. 134 This header field SHOULD NOT be added to a message that is addressed 135 to multiple recipients. It is presumed that an author making use of 136 this field is seeking to protect transactional or otherwise sensitive 137 data intended for a single recipient. 139 If the agent generating the message uses any kind of message 140 authentication technology, the authentication SHOULD cover this 141 header field if possible. An agent receiving a message bearing this 142 header field that is covered by some kind of authentication SHOULD 143 NOT process it as described above if the authentication does not 144 succeed. 146 If the receiving system detects that the named mailbox is foreign, it 147 is free to remove the header field prior to relaying it toward its 148 destination. 150 4. Discussion 152 The presence of the intended mailbox supports the case where a 153 message bearing this header field is forwarded. The specific use 154 case is as follows: 156 1. A user subscribes to a service "S" on data "D" and confirms an 157 email address at the user's current location, "A"; 159 2. At some later date, the user intends to leave the current 160 location, and thus creates a new mailbox elsewhere, at "B"; 162 3. The user replaces mailbox "A" with forwarding to "B"; 164 4. "S" constructs a message to "A" claiming that address was valid 165 at date "D" and sends it to "A", which forwards to "B"; 167 5. The receiving MTA at "B" asserts that "B" has not been under 168 constant ownership since "D" and rejects the message. 170 Some services generate messages with an RFC5322.To field that does 171 not contain a valid address, in order to obscure the intended 172 recipient. For this reason, the original intended recipient is 173 included in this header field. 175 5. Example 177 In the following example, "C:" indicates data sent by an SMTP client, 178 and "S:" indicates respones by the SMTP server. Message content is 179 CRLF terminated, though these are omitted here for ease of reading. 181 C: [connection established] 182 S: 220 server.example.com ESMTP ready 183 C: HELO client.example.net 184 S: 250 server.example.com 185 C: MAIL FROM: 186 S: 250 OK 187 C: RCPT TO: 188 S: 250 OK 189 C: DATA 190 S: 354 Ready for message content 191 C: From: Mister Sender 192 To: Miss Receiver 193 Subject: Are you still there? 194 Date: Fri, 28 Jun 2013 18:01:01 +0200 195 Require-Recipient-Valid-Since: receiver@example.com; 196 Sat, 1 Jun 2013 09:23:01 -0700 198 Are you still there? 199 . 200 S: 550 5.1.6 receiver@example.com is no longer valid 201 C: QUIT 202 S: 221 So long! 204 6. Privacy Considerations 206 This document proposes a solution to an issue that could cause mail 207 to be unintentionally delivered to the wrong party. 209 7. Security Considerations 211 The response of a server implementing this protocol can reveal 212 information about the age of existing email accounts. 214 8. IANA Considerations 216 IANA is requested to add the following entry to the Permanent Message 217 Header Field registry, as per the procedure found in [IANA-HEADERS]: 219 Header field name: Require-Recipient-Valid-Since 220 Applicable protocol: mail ([MAIL]) 221 Status: Standard 222 Author/Change controller: IETF 223 Specification document(s): [this document] 224 Related information: 225 Requesting review of any proposed changes and additions to 226 this field is recommended. 228 9. References 230 9.1. Normative References 232 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for 233 Syntax Specifications: ABNF", RFC 5234, January 2008. 235 [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, 236 "Registration Procedures for Message Header Fields", 237 BCP 90, RFC 3864, September 2004. 239 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 243 October 2008. 245 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 246 RFC 5321, October 2008. 248 9.2. Informative References 250 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 251 July 2009. 253 [ESC] Vaudreuil, G., "Enhanced Mail System Status Codes", 254 RFC 3463, January 2003. 256 Appendix A. Acknowledgements 258 Erling Ellingsen proposed the idea. 260 Reviews and comments were provided by Gregg Stefancik, Ed Zayas, 261 (others) 263 Authors' Addresses 265 William J. Mills 266 Yahoo! Inc. 268 EMail: wmills_92105@yahoo.com 270 Murray S. Kucherawy 271 Facebook, Inc. 272 1 Hacker Way 273 Menlo Park, CA 94025 274 USA 276 EMail: msk@fb.com