idnits 2.17.1 draft-ietf-appsawg-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 (August 18, 2013) is 3903 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) 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: Standards Track M. Kucherawy 5 Expires: February 19, 2014 Facebook, Inc. 6 August 18, 2013 8 The Require-Recipient-Valid-Since Header Field 9 draft-ietf-appsawg-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 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 19, 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 8.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 7 65 8.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 8 66 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 67 9.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 8 68 9.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 9 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 10.1. Header Field Registration . . . . . . . . . . . . . . . . 9 71 10.2. Enhanced Status Code Registration . . . . . . . . . . . . 9 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Email addresses sometimes get reassigned to a different person. For 80 example, employment changes at a company can cause an address used 81 for an ex-employee to be assigned to a new employee, or a mail 82 service provider (MSP) might expire an account and then let someone 83 else register for the local-part that was previously used. Those who 84 sent mail to the previous owner of an address might not know that it 85 has been reassigned. This can lead to the sending of email to the 86 correct address, but the wrong recipient. 88 What is needed is a way to indicate an attribute of the recipient 89 that will distinguish between the previous owner of an address and 90 its current owner. if they are different. Further, this needs to be 91 done in a way that respects privacy. 93 The mechanism specified here allows the sender of the mail to 94 indicate how "old" the address assignment is expected to be. In 95 effect, the sender is saying, "The person to whom I am sending to had 96 this address assigned to as far back as this date-time." A receiving 97 system can then compare this information against the date and time 98 the address was assigned to its current user. If the assignment was 99 made later than the date-time indicated in the message, there is a 100 good chance the current user of the address is not the correct 101 recipient. The receiving system can then choose to prevent delivery 102 and, possibly, to notify the original sender of the problem. 104 The primary application is automatically generated messages rather 105 than user-authored content. 107 2. Definitions 109 For a description of the email architecture, consult [EMAIL-ARCH]. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [KEYWORDS]. 115 3. Description 117 The Require-Recipient-Valid-Since header field includes an intended 118 recipient coupled with a timestamp indicating the most recent date 119 and time when the message author believed the destination mailbox to 120 be under the continuous ownership (see Section 6) of a specific 121 party. Presumably there has been some confirmation process applied 122 to establish this ownership; however, the method of making such 123 determinations is a local matter and outside the scope of this 124 document. 126 The general constraints on syntax and placement of header fields in a 127 message are defined in Internet Message Format [MAIL]. 129 Using Augmented Backus-Naur Form [ABNF], the syntax for the field is: 131 rrvs = "Require-Recipient-Valid-Since:" addr-spec; date-time CRLF 133 "CFWS" is defined in Section 3.2.2, "date-time" is defined in Section 134 3.3, and "addr-spec" is defined in Section 3.4.1, of [MAIL]. 136 A receiving system that implements this specification checks whether 137 the current mailbox owner has held it continuously, far enough back 138 to include the given date-time, and delivers it unless that check 139 returns in the negative. Expressed as a sequence of steps: 141 1. Extract the set of Require-Recipient-Valid-Since fields from the 142 message. 144 2. Discard any such fields that are syntactically invalid. 146 3. Discard any such fields that name a role account as listed in 147 Mailbox Names For Common Services, Roles And Functions [ROLES]. 149 4. Discard any such fields for which the "addr-spec" portion does 150 not match a current recipient, as listed in the RCPT TO commands 151 in the corresponding Simple Mail Transfer Protocol [SMTP] 152 session. 154 5. For each field remaining, determine if the named address has been 155 under continuous ownership since the corresponding timestamp. If 156 it has not, reject the message. 158 6. RECOMMENDED: If local delivery is being performed, remove all 159 instances of this field prior to delivery to a mailbox; if the 160 message is being forwarded, remove those instances of this header 161 field that were not discarded by steps 1-4 above. 163 The final step is not mandatory as not all mail handling agents are 164 capable of stripping away header fields. 166 If a message is to be rejected within the SMTP protocol itself 167 (versus generating a rejection message separately), servers 168 implementing this protocol and the SMTP extensions described in 169 Enhanced Mail System Status Codes [ESC] SHOULD use the enhanced 170 status code described in Section 10.2. 172 Implementation is expected to be transparent to non participants, 173 since they would typically ignore this header field. 175 This header field is not typically added to a message that is 176 addressed to multiple recipients. The intended use of this field 177 involves an author seeking to protect transactional or otherwise 178 sensitive data intended for a single recipient, and thus generating 179 independent messages for each individual recipient is normal 180 practice. Because of the nature of SMTP, a message bearing this 181 header field for multiple addressees could result in a single 182 delivery attempt for multiple recipients (in particular, if two of 183 the recipients are handled by the same server), and if any one of 184 them fails the test, the delivery fails to all of them; it then 185 becomes necessary to generate a Delivery Status Notification [DSN] 186 message for each of the failed recipients indicating the specific 187 failure cause for each. 189 To further obscure account details on the receiving system, the 190 receiver SHOULD ignore the header field if the address within it has 191 had one continuous owner since it was created, regardless of the 192 purported confirmation date of the address. This is further 193 discussed in Section 8. 195 4. Use with Mailing Lists 197 Mailing list services can store the timestamp at which a subscriber 198 was added to a mailing list. This specification can be used in 199 conjunction with that information in order to restrict traffic to the 200 original subscriber, rather than a different person now in possession 201 of an address under which the original subscriber registered. Upon 202 receiving a rejection caused by this specification, the list service 203 can remove that address from further distribution. 205 A mailing list service that receives a message containing this field 206 removes it from the message prior to redistributing it, limiting 207 exposure of information regarding the relationship between the 208 message's author and mailing list. 210 5. Discussion 212 It can be argued that placing this information in a message header 213 field is not the ideal architectural choice and that it would have 214 been better to introduce this capability as an extension to SMTP. 215 The exchange of meta data about the target address is not part of the 216 actual message content, nor is it meta data about the content. 217 However, if the author and the target address are separated by an 218 SMTP server that does not implement the SMTP extension, the check 219 will not be able to propagate to the intended receiving system. 220 Implementing this service as a header field allows the check to occur 221 even across non-participating systems, effectively tunneling the 222 request. 224 The presence of the intended address in the field content supports 225 the case where a message bearing this header field is forwarded. The 226 specific use case is as follows: 228 1. A user subscribes to a service "S" on date "D" and confirms an 229 email address at the user's current location, "A"; 231 2. At some later date, the user intends to leave the current 232 location, and thus creates a new mailbox elsewhere, at "B"; 234 3. The user replaces address "A" with forwarding to "B"; 236 4. "S" constructs a message to "A" claiming that address was valid 237 at date "D" and sends it to "A"; 239 5. The receiving MTA at "A" determines that the forwarding in effect 240 was created by the same party that owned the mailbox there, and 241 thus concludes the continuous ownership test has been satisfied; 243 6. If possible, "A" removes this header field from the message, and 244 in either case, forwards it to "B"; 246 7. On receipt at "B", either the header field has been removed, or 247 the header field does not refer to a current envelope recipient, 248 and in either case delivers the message. 250 Some services generate messages with an RFC5322.To field that does 251 not contain a valid address, in order to obscure the intended 252 recipient. For this reason, the original intended recipient is 253 included in this header field. 255 6. Continuous Ownership 257 Determining continuous ownership of a mailbox is a local matter at 258 the receiving site. In particular, the only possible answers to the 259 continuous-ownership-since question are "yes", "no", and "unknown"; 260 the action to be taken in the "unknown" case is a matter of local 261 policy. 263 For example, when control of a domain name is transferred, the new 264 domain owner might be unable to determine whether the owner of the 265 subject address has been under continuous ownership since the stated 266 date if the mailbox history is not also transferred (or was not 267 previously maintained). 269 It will also be "unknown" if whatever database contains mailbox 270 ownership data is temporarily unavailable at the time a message 271 arrives for delivery. In this case, typical SMTP temporary failure 272 handling is appropriate. 274 7. Example 276 In the following example, "C:" indicates data sent by an SMTP client, 277 and "S:" indicates responses by the SMTP server. Message content is 278 CRLF terminated, though these are omitted here for ease of reading. 280 C: [connection established] 281 S: 220 server.example.com ESMTP ready 282 C: HELO client.example.net 283 S: 250 server.example.com 284 C: MAIL FROM: 285 S: 250 OK 286 C: RCPT TO: 287 S: 250 OK 288 C: DATA 289 S: 354 Ready for message content 290 C: From: Mister Sender 291 To: Miss Receiver 292 Subject: Are you still there? 293 Date: Fri, 28 Jun 2013 18:01:01 +0200 294 Require-Recipient-Valid-Since: receiver@example.com; 295 Sat, 1 Jun 2013 09:23:01 -0700 297 Are you still there? 298 . 299 S: 550 5.7.15 receiver@example.com is no longer valid 300 C: QUIT 301 S: 221 So long! 303 If an authentication scheme is applied to claim the added header 304 field is valid, but the scheme fails, a receiver might reject the 305 message with an SMTP reply such as: 307 S: 550-5.7.7 Use of Require-Recipient-Valid-Since header 308 S: 550 field requires a valid signature 310 8. Security Considerations 312 8.1. Abuse Countermeasures 314 The response of a server implementing this protocol can disclose 315 information about the age of existing email mailbox. Implementation 316 of countermeasures against probing attacks is advised. For example, 317 an operator could track appearance of this field with respect to a 318 particular mailbox and observe the timestamps being submitted for 319 testing; if it appears a variety of timestamps is being tried against 320 a single mailbox in short order, the field could be ignored and the 321 message silently discarded. This concern is discussed further in 322 Section 9. 324 8.2. Suggested Use Restrictions 326 If the mailbox named in the field is known to have had only a single 327 continuous owner since creation, or not to have existed at all (under 328 any owner) prior to the date specified in the field, then the field 329 can be silently ignored and normal message handling applied so that 330 this information is not disclosed. Such fields are likely the 331 product of either gross error or an attack. 333 A message author using this specification might restrict inclusion of 334 the header field such that it is only done for recipients known also 335 to implement this specification, in order to reduce the possibility 336 of revealing information about the relationship between the author 337 and the mailbox. 339 9. Privacy Considerations 341 9.1. Probing Attacks 343 As described above, use of this header field in probing attacks can 344 disclose information about the history of the mailbox. The harm that 345 can be done by leaking any kind of private information is difficult 346 to predict, so it is prudent to be sensitive to this sort of 347 disclosure, either inadvertently or in response to probing by an 348 attacker. It bears restating, then, that implementing 349 countermeasures to abuse of this capability needs strong 350 consideration. 352 That some MSPs allow for expiration of account names when they have 353 been unused for a protracted period forces a choice between two 354 potential types of privacy vulnerabilities, one of which presents 355 significantly greater threats to users than the other. Automatically 356 generated mail is often used to convey authentication credentials 357 that can potentially provide access to extremely sensitive 358 information. Supplying such credentials to the wrong party after a 359 mailbox ownership change could allow the previous owner's data to be 360 exposed without his or her authorization or knowledge. In contrast, 361 the information that may be exposed to a third party via the proposal 362 in this document is limited to information about the mailbox history. 363 Given that MSPs have chosen to allow transfers of mailbox ownership 364 without the prior owner's involvement, the information leakage from 365 the header field specified here creates far fewer risks than the 366 potential for delivering mail to the wrong party. 368 9.2. Envelope Recipients 370 The email To and Cc header fields are not required to be populated 371 with addresses that match the envelope recipient set, and Cc may even 372 be absent. However, the algorithm in Section 3 requires that this 373 header field contain a match for an envelope recipient in order to be 374 actionable. As such, use of this specification can reveal some or 375 all of the original intended recipient set to any party that can see 376 the message in transit or upon delivery. 378 For a message destined to a single recipient, this is unlikely to be 379 a concern, which is one of the reasons use of this specification on 380 multi-recipient messages is discouraged. 382 10. IANA Considerations 384 10.1. Header Field Registration 386 IANA is requested to add the following entry to the Permanent Message 387 Header Field registry, as per the procedure found in [IANA-HEADERS]: 389 Header field name: Require-Recipient-Valid-Since 390 Applicable protocol: mail ([MAIL]) 391 Status: Standard 392 Author/Change controller: IETF 393 Specification document(s): [this document] 394 Related information: 395 Requesting review of any proposed changes and additions to 396 this field is recommended. 398 10.2. Enhanced Status Code Registration 400 IANA is requested to register the following in the SMTP Enhanced 401 Status Codes registry: 403 Code: X.7.15 404 Sample Text: Mailbox owner has changed 405 Associated basic status code: 5 406 Description: This status code is returned when a message is 407 received with a Require-Recipient-Valid-Since 408 field and the receiving system is able to 409 determine that the intended recipient mailbox 410 has not been under continuous ownership since 411 the specified date. 412 Reference: [this document] 413 Submitter: M. Kucherawy 414 Change controller: IESG 416 11. References 418 11.1. Normative References 420 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for 421 Syntax Specifications: ABNF", RFC 5234, January 2008. 423 [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, 424 "Registration Procedures for Message Header Fields", 425 BCP 90, RFC 3864, September 2004. 427 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 431 October 2008. 433 [ROLES] Crocker, D., "Mailbox Names For Common Services, 434 Roles And Functions", RFC 2142, May 1997. 436 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 437 RFC 5321, October 2008. 439 11.2. Informative References 441 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message 442 Format for Delivery Status Notifications", RFC 3464, 443 January 2003. 445 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 446 July 2009. 448 [ESC] Vaudreuil, G., "Enhanced Mail System Status Codes", 449 RFC 3463, January 2003. 451 Appendix A. Acknowledgments 453 Erling Ellingsen proposed the idea. 455 Reviews and comments were provided by Michael Adkins, Kurt Andersen, 456 Alissa Cooper, Dave Crocker, Ned Freed, John Levine, Gregg Stefancik, 457 Ed Zayas, (others) 459 Authors' Addresses 461 William J. Mills 462 Yahoo! Inc. 464 EMail: wmills_92105@yahoo.com 466 Murray S. Kucherawy 467 Facebook, Inc. 468 1 Hacker Way 469 Menlo Park, CA 94025 470 USA 472 EMail: msk@fb.com