idnits 2.17.1 draft-wmills-rrvs-header-field-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 : ---------------------------------------------------------------------------- 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 (August 2, 2013) is 3920 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: February 3, 2014 Facebook, Inc. 6 August 2, 2013 8 The Require-Recipient-Valid-Since Header Field 9 draft-wmills-rrvs-header-field-01 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 The intended use of this header field is on automatically generated 20 messages that might contain sensitive information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 3, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Use with Mailing Lists . . . . . . . . . . . . . . . . . . . . 5 60 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 6 62 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 10.1. Header Field Registration . . . . . . . . . . . . . . . . 8 67 10.2. Enhanced Status Code Registration . . . . . . . . . . . . 9 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 11.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 Mailbox Service Providers (MSPs) are public, often free, services 76 that provide email sending and receiving capabilities to users. Some 77 of them have policies that allow for expiration of account names when 78 they have been unused for a protracted period. If an expired account 79 name can be reclaimed, there is a risk of delivery of mail to the 80 wrong party if some message author is unaware of this change of 81 ownership. 83 This document defines a header field called Require-Recipient-Valid- 84 Since. The content of this header field includes an intended 85 recipient mailbox and a timestamp indicating at what point in time 86 the message author believed that mailbox to be under confirmed 87 ownership of a specific party. If the receiving system observes this 88 field and can determine that the intended recipient mailbox has 89 changed ownership since the provided timestamp, it can decline 90 delivery, preventing possible misdelivery of mail. 92 The primary application is automatically generated messages rather 93 than user-authored content. 95 2. Definitions 97 For a description of the email architecture, consult [EMAIL-ARCH]. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [KEYWORDS]. 103 3. Description 105 The Require-Recipient-Valid-Since header field includes an intended 106 recipient coupled with a timestamp indicating the most recent date 107 and time when the message author believed the destination mailbox to 108 be under the continuous ownership (see Section 6) of a specific 109 party. Presumably there has been some confirmation process applied 110 to establish this ownership; however, the method of making such 111 determinations is a local matter and outside the scope of this 112 document. 114 The general constraints on syntax and placement of header fields in a 115 message are defined in Internet Message Format [MAIL]. 117 Using Augmented Backus-Naur Form [ABNF], the syntax for the field is: 119 rrvs = "Require-Recipient-Valid-Since:" mailbox; date-time CRLF 121 "CFWS" is defined in Section 3.2.2, "date-time" is defined in Section 122 3.3, and "mailbox" is defined in Section 3.4, of [MAIL]. 124 A receiving system that implements this specification determines 125 whether the named mailbox is based at that receiving system, is a 126 current intended recipient of the message, and has been under 127 continuous ownership since the specified date. If that address does 128 not match an intended local recipient (in terms of the email 129 transaction details), the header field is ignored. Otherwise, if 130 continuous ownership since the indicated time can be established, the 131 message is delivered normally; if not, the message is rejected. 132 Finally, when delivery is being performed (and the message is not 133 being forwarded), the header field is removed. Expressed 134 algorithmically: 136 1. Extract the set of Require-Recipient-Valid-Since fields from the 137 message. 139 2. Discard any such fields that are syntactically invalid. 141 3. Discard any such fields that name a role account as listed in 142 Mailbox Names For Common Services, Roles And Functions [ROLES]. 144 4. Discard any such fields for which the "mailbox" portion does not 145 match a current recipient, as listed in the RCPT TO commands in 146 the corresponding Simple Mail Transfer Protocol [SMTP] session. 148 5. For each field remaining, determine if the named mailbox has been 149 under continuous ownership since the corresponding timestamp. If 150 it has not, reject the message. 152 6. RECOMMENDED: If local delivery is being performed, remove all 153 instances of this field prior to delivery to a mailbox; if the 154 message is being forwarded, remove those instances of this header 155 field that were not discarded by steps 1-4 above. 157 The final step is not mandatory as not all mail handling agents are 158 capable of stripping away header fields. 160 It is preferred that the rejection be enacted as an error response to 161 the SMTP command verb, but this is not strictly necessary. When 162 performing the "DATA" rejection, servers use an SMTP error code (and 163 Enhanced Mail System Status Code [ESC], if supported) as described in 164 Section 10.2. 166 Implementation is expected to be transparent to non participants, 167 since they would typically ignore this header field. 169 This header field SHOULD NOT be added to a message that is addressed 170 to multiple recipients. Because of the nature of SMTP, a message 171 bearing this header field for multiple mailboxes could result in a 172 single delivery attempt for multiple recipients (in particular, if 173 two of the recipients are handled by the same server), and if any one 174 of them fails the test, the delivery fails to all of them. It is 175 presumed that an author making use of this field is seeking to 176 protect transactional or otherwise sensitive data intended for a 177 single recipient, and thus generating independent messages for each 178 individual recipient is RECOMMENDED. 180 If the agent generating the message uses any kind of message 181 authentication technology, the authentication SHOULD cover this 182 header field. An agent receiving a message bearing this header field 183 that is covered by some kind of authentication SHOULD ignore it if 184 the authentication does not succeed. 186 To further obscure account details on the receiving system, the 187 receiver SHOULD ignore the header field if the address within it has 188 had one continuous owner since it was created, regardless of the 189 purported confirmation date of the address. This is further 190 discussed in Section 8. 192 4. Use with Mailing Lists 194 Mailing list services can store the timestamp at which a subscriber 195 was added to a mailing list. Thus, when generating a message for 196 distribution, the list service can use this field as a means of 197 preventing mailing list traffic from going to the wrong recipient, 198 and instead remove that address from further distribution. 200 A mailing list service that receives a message containing this field 201 removes it from the message prior to redistributing it, limiting 202 exposure of information regarding the relationship between the 203 message's author and mailing list. 205 5. Discussion 207 It can be argued that the architecturally better decision would be to 208 introduce this capability as an extension to SMTP. The exchange of 209 meta data about the target mailbox is not part of the actual message 210 content, nor is it meta data about the content. However, if the 211 author and the target mailbox are separated by an SMTP server that 212 does not implement the SMTP extension, the check will not be able to 213 propagate to the intended receiving system. Implementing this 214 service as a header field allows the check to occur even across non- 215 participating systems, effectively tunneling the request. 217 The presence of the intended mailbox in the field content supports 218 the case where a message bearing this header field is forwarded. The 219 specific use case is as follows: 221 1. A user subscribes to a service "S" on date "D" and confirms an 222 email address at the user's current location, "A"; 224 2. At some later date, the user intends to leave the current 225 location, and thus creates a new mailbox elsewhere, at "B"; 227 3. The user replaces mailbox "A" with forwarding to "B"; 229 4. "S" constructs a message to "A" claiming that address was valid 230 at date "D" and sends it to "A"; 232 5. The receiving MTA at "A" determines that the forwarding in effect 233 was created by the same party that owned the mailbox there, and 234 thus concludes the continuous ownership test has been satisfied; 236 6. If possible, "A" removes this header field from the message, and 237 in either case, forwards it to "B"; 239 7. On receipt at "B", either the header field has been removed, or 240 the header field does not refer to a current envelope recipient, 241 and in either case delivers the message. 243 Some services generate messages with an RFC5322.To field that does 244 not contain a valid address, in order to obscure the intended 245 recipient. For this reason, the original intended recipient is 246 included in this header field. 248 6. Continuous Ownership 250 Determining continuous ownership of a mailbox is entirely a local 251 matter. In particular, the only possible answers to that question 252 are "yes", "no", and "unknown"; the action to be taken in the 253 "unknown" case is a matter of local policy. 255 For example, when control of a domain name is transferred, the new 256 domain owner may be unable to determine whether the owner of the 257 subject mailbox has been under continuous ownership since the stated 258 date if the mailbox history is not also transferred (or was not 259 previously maintained). 261 It will also be "unknown" if whatever database contains mailbox 262 ownership data is temporarily unavailable at the time a message 263 arrives for delivery. In this case, typical SMTP temporary failure 264 handling is appropriate. 266 7. Example 268 In the following example, "C:" indicates data sent by an SMTP client, 269 and "S:" indicates responses by the SMTP server. Message content is 270 CRLF terminated, though these are omitted here for ease of reading. 272 C: [connection established] 273 S: 220 server.example.com ESMTP ready 274 C: HELO client.example.net 275 S: 250 server.example.com 276 C: MAIL FROM: 277 S: 250 OK 278 C: RCPT TO: 279 S: 250 OK 280 C: DATA 281 S: 354 Ready for message content 282 C: From: Mister Sender 283 To: Miss Receiver 284 Subject: Are you still there? 285 Date: Fri, 28 Jun 2013 18:01:01 +0200 286 Require-Recipient-Valid-Since: receiver@example.com; 287 Sat, 1 Jun 2013 09:23:01 -0700 289 Are you still there? 290 . 291 S: 550 5.7.15 receiver@example.com is no longer valid 292 C: QUIT 293 S: 221 So long! 295 8. Security Considerations 297 The response of a server implementing this protocol can disclose 298 information about the age of existing email mailbox. Implementation 299 of countermeasures against probing attacks is advised. For example, 300 an operator could track appearance of this field with respect to a 301 particular mailbox and observe the timestamps being submitted for 302 testing; if it appears a variety of timestamps is being tried against 303 a single mailbox in short order, the field could be ignored and the 304 message silently discarded. This concern is discussed further in 305 Section 9. 307 If the mailbox named in the field is known to have had only a single 308 continuous owner since creation, or not to have existed at all (under 309 any owner) prior to the date specified in the field, then the field 310 can be silently ignored and normal message handling applied so that 311 this information is not disclosed. Such fields are likely the 312 product of either an attack or gross error. 314 9. Privacy Considerations 316 As described above, use of this header field in probing attacks can 317 disclose information about the history of the mailbox. In the 318 terminology defined in Privacy Considerations for Internet Protocols 319 [PRIVACY], this is an Item of Interest. The harm that can be done by 320 leaking any kind of private information varies widely and cannot be 321 predicted, so it is prudent to be sensitive to this sort of 322 disclosure, either inadvertently or in response to probing by an 323 attacker. It bears restating, then, that implementing 324 countermeasures to abuse of this capability needs strong 325 consideration. 327 That some MSPs allow for expiration of account names when they have 328 been unused for a protracted period forces a choice between two 329 potential types of privacy vulnerabilities, one of which presents 330 significantly greater threats to users than the other. Automatically 331 generated mail is often used to convey authentication credentials 332 that can potentially provide access to extremely sensitive 333 information. Supplying such credentials to the wrong party after a 334 mailbox ownership change could allow the previous owner's data to be 335 exposed without his or her authorization or knowledge. In contrast, 336 the information that may be exposed to a third party via the proposal 337 in this document is limited to information about the mailbox history. 338 Given that MSPs have chosen to allow transfers of mailbox ownership 339 without the prior owner's involvement, the information leakage from 340 the header field specified here creates far fewer risks than the 341 potential for delivering mail to the wrong party. 343 10. IANA Considerations 345 10.1. Header Field Registration 347 IANA is requested to add the following entry to the Permanent Message 348 Header Field registry, as per the procedure found in [IANA-HEADERS]: 350 Header field name: Require-Recipient-Valid-Since 351 Applicable protocol: mail ([MAIL]) 352 Status: Standard 353 Author/Change controller: IETF 354 Specification document(s): [this document] 355 Related information: 356 Requesting review of any proposed changes and additions to 357 this field is recommended. 359 10.2. Enhanced Status Code Registration 361 IANA is requested to register the following in the SMTP Enhanced 362 Status Codes registry: 364 Code: X.7.15 365 Sample Text: Mailbox owner has changed 366 Associated basic status code: 5 367 Description: This status code is returned when a message is 368 received with a Require-Recipient-Valid-Since 369 field and the receiving system is able to 370 determine that the intended recipient mailbox 371 has not been under continuous ownership since 372 the specified date. 373 Reference: [this document] 374 Submitter: M. Kucherawy 375 Change controller: IESG 377 11. References 379 11.1. Normative References 381 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for 382 Syntax Specifications: ABNF", RFC 5234, January 2008. 384 [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, 385 "Registration Procedures for Message Header Fields", 386 BCP 90, RFC 3864, September 2004. 388 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 392 October 2008. 394 [ROLES] Crocker, D., "Mailbox Names For Common Services, 395 Roles And Functions", RFC 2142, May 1997. 397 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 398 RFC 5321, October 2008. 400 11.2. Informative References 402 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 403 July 2009. 405 [ESC] Vaudreuil, G., "Enhanced Mail System Status Codes", 406 RFC 3463, January 2003. 408 [PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 409 Morris, J., Hansen, M., and R. Smith, "Privacy 410 Considerations for Internet Protocols", RFC 6973, 411 July 2013. 413 Appendix A. Acknowledgments 415 Erling Ellingsen proposed the idea. 417 Reviews and comments were provided by Michael Adkins, Kurt Andersen, 418 Alissa Cooper, Ned Freed, John Levine, Gregg Stefancik, Ed Zayas, 419 (others) 421 Authors' Addresses 423 William J. Mills 424 Yahoo! Inc. 426 EMail: wmills_92105@yahoo.com 428 Murray S. Kucherawy 429 Facebook, Inc. 430 1 Hacker Way 431 Menlo Park, CA 94025 432 USA 434 EMail: msk@fb.com