idnits 2.17.1 draft-ietf-appsawg-rrvs-header-field-02.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 (November 6, 2013) is 3795 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: May 10, 2014 Facebook, Inc. 6 November 6, 2013 8 The "Require Recipient Valid Since" SMTP Service Extension 9 draft-ietf-appsawg-rrvs-header-field-02 11 Abstract 13 This document defines an extension for the Simple Mail Transfer 14 Protocol, called RRVS (for "Require Recipient Valid Since"), to 15 provide a method for senders to indicate to receivers the time when 16 the sender last confirmed the ownership of the target mailbox. This 17 can be used to detect changes of mailbox ownership, and thus prevent 18 mail from being delivered to the wrong party. 20 The intended use of this facility is on automatically generated 21 messages that might contain sensitive information, though it may also 22 be useful in other applications. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 10, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. The 'RRVS' SMTP Extension . . . . . . . . . . . . . . . . . 4 62 4. Handling By Receivers . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. SMTP Extension Offered . . . . . . . . . . . . . . . . . . 4 64 4.2. SMTP Extension Not Offered . . . . . . . . . . . . . . . . 5 65 5. Role Accounts . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Use with Mailing Lists . . . . . . . . . . . . . . . . . . . . 5 67 7. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 6 68 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 6 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . . 6 72 9.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 7 73 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 7 74 10.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . . 7 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 76 11.1. SMTP Extension Registration . . . . . . . . . . . . . . . . 8 77 11.2. Enhanced Status Code Registration . . . . . . . . . . . . . 8 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 12.1. Normative References . . . . . . . . . . . . . . . . . . . 8 80 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 Email addresses sometimes get reassigned to a different person. For 86 example, employment changes at a company can cause an address used 87 for an ex-employee to be assigned to a new employee, or a mail 88 service provider (MSP) might expire an account and then let someone 89 else register for the local-part that was previously used. Those who 90 sent mail to the previous owner of an address might not know that it 91 has been reassigned. This can lead to the sending of email to the 92 correct address, but the wrong recipient. 94 What is needed is a way to indicate an attribute of the recipient 95 that will distinguish between the previous owner of an address and 96 its current owner, if they are different. Further, this needs to be 97 done in a way that respects privacy. 99 The mechanism specified here allows the sender of the mail to 100 indicate how "old" the address assignment is expected to be. In 101 effect, the sender is saying, "The person to whom I am sending to had 102 this address assigned to as far back as this date-time." A receiving 103 system can then compare this information against the date and time 104 the address was assigned to its current user. If the assignment was 105 made later than the date-time indicated in the message, there is a 106 good chance the current user of the address is not the intended 107 recipient. The receiving system can then choose to prevent delivery 108 and, possibly, to notify the original sender of the problem. 110 The primary application is automatically generated messages rather 111 than user-authored content, though it may be useful in other 112 contexts. 114 2. Definitions 116 For a description of the email architecture, consult [EMAIL-ARCH]. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [KEYWORDS]. 122 3. Description 124 To address the problem described above, a mail sending client needs 125 to indicate to the server to which it is connecting that there is an 126 expectation that the destination of the message has been under 127 continuous ownership since some date-time, presumably the most recent 128 time the message author had confirmed its understanding of who owned 129 that mailbox. The mechanism defined here is an extension to the 130 Simple Mail Transfer Protocol [SMTP] for use between a client and 131 server that both implement the extension. 133 The SMTP extenion is called "RRVS" (Require Recipient Valid Since), 134 and adds a parameter to the SMTP "RCPT" command that indicates the 135 most recent date and time when the message author believed the 136 destination mailbox to be under the continuous ownership (see 137 Section 7) of a specific party. Presumably there has been some 138 confirmation process applied to establish this ownership; however, 139 the method of making such determinations is a local matter and 140 outside the scope of this document. 142 3.1. The 'RRVS' SMTP Extension 144 Extensions to SMTP are described in Section 2.2 of [SMTP]. 146 The name of the extension is "RRVS", an abbreviation of "Require 147 Recipient Valid Since". Servers implementing the SMTP extension 148 advertise an additional EHLO keyword of "RRVS", which has no 149 associated parameters, introduces no new SMTP verbs, and does not 150 alter the MAIL verb. 152 An MTA implementing RRVS can transmit or accept a new parameter to 153 the RCPT command. The new parameter is "RRVS", which takes a value 154 that is a timestamp expressed as a "date-time" as defiend in 155 [DATETIME], with the added restriction that a "time-secfrac" MUST NOT 156 be used. Accordingly, this extension increases the maximum command 157 length for the RCPT verb by 31 characters. 159 The meaning of this extension, when used, is described in 160 Section 4.1. 162 4. Handling By Receivers 164 If a receiver implements the RRVS SMTP extension, then there are two 165 possible evaluation paths: 167 1. The sending client implements the extension, and so there was an 168 RRVS parameter on a RCPT TO command in the SMTP session; or 170 2. The sending client does not (or elected not to) implement the 171 extension, so the RRVS parameter was not present on the RCPT TO 172 commands in the SMTP session. 174 4.1. SMTP Extension Offered 176 A receiving system that implements the SMTP extension declared above 177 and observes an RRVS parameter on a RCPT TO command checks whether 178 the current owner of the destination mailbox has held it 179 continuously, far enough back to inclue the given date-time, and 180 delivers it unless that check returns in the negative. Expressed as 181 a sequence of steps: 183 1. Ignore the parameter if the named mailbox is a role account as 184 listed in Mailbox Names For Common Services, Roles And Functions 185 [ROLES]. (See Section 5.) 187 2. Determine if the named address is serviced for local delivery. 188 If so, and if that address has not been under continuous 189 ownership since the specified timestamp, return a 550 error to 190 the RCPT command. If the server implements Enhanced Mail System 191 Status Codes [ESC], it SHOULD use the code defined in 192 Section 11.2. 194 3. Otherwise, continue with normal delivery. 196 To further obscure account details on the receiving system, the 197 receiver SHOULD ignore the SMTP extension if the address specified 198 has had one continuous owner since it was created, regardless of the 199 purported confirmation date of the address. This is further 200 discussed in Section 9. 202 4.2. SMTP Extension Not Offered 204 For a message being sent that includes content meant to be protected 205 by this extension, the client MUST NOT continue to deliver a message 206 to a server where the server does not advertise the RRVS SMTP 207 extension. 209 5. Role Accounts 211 It is necessary not to interfere with delivery of messages to role 212 mailboxes (see [ROLES]), but it could be useful to indicate to users 213 handling those mailboxes that a change of ownership might have taken 214 place where such notification is possible. 216 6. Use with Mailing Lists 218 Mailing list services can store the timestamp at which a subscriber 219 was added to a mailing list. This specification can be used in 220 conjunction with that information in order to restrict traffic to the 221 original subscriber, rather than a different person now in possession 222 of an address under which the original subscriber registered. Upon 223 receiving a rejection caused by this specification, the list service 224 can remove that address from further distribution. 226 7. Continuous Ownership 228 Determining continuous ownership of a mailbox is a local matter at 229 the receiving site. In particular, the only possible answers to the 230 continuous-ownership-since question are "yes", "no", and "unknown"; 231 the action to be taken in the "unknown" case is a matter of local 232 policy. 234 For example, when control of a domain name is transferred, the new 235 domain owner might be unable to determine whether the owner of the 236 subject address has been under continuous ownership since the stated 237 date if the mailbox history is not also transferred (or was not 238 previously maintained). 240 It will also be "unknown" if whatever database contains mailbox 241 ownership data is temporarily unavailable at the time a message 242 arrives for delivery. In this case, typical SMTP temporary failure 243 handling is appropriate. 245 8. Examples 247 In the following examples, "C:" indicates data sent by an SMTP 248 client, and "S:" indicates responses by the SMTP server. Message 249 content is CRLF terminated, though these are omitted here for ease of 250 reading. 252 8.1. SMTP Extension Example 254 C: [connection established] 255 S: 220 server.example.com ESMTP ready 256 C: EHLO client.example.net 257 S: 250-server.example.com 258 S: 250 RRVS 259 C: MAIL FROM: 260 S: 250 OK 261 C: RCPT TO: RRVS=2013-12-31T23:59:59 262 S: 550 5.7.15 receiver@example.com is no longer valid 263 C: QUIT 264 S: 221 So long! 266 9. Security Considerations 268 9.1. Abuse Countermeasures 270 The response of a server implementing this protocol can disclose 271 information about the age of existing email mailbox. Implementation 272 of countermeasures against probing attacks is advised. For example, 273 an operator could track appearance of this extension with respect to 274 a particular mailbox and observe the timestamps being submitted for 275 testing; if it appears a variety of timestamps is being tried against 276 a single mailbox in short order, the extension could be ignored and 277 the message silently discarded. This concern is discussed further in 278 Section 10. 280 9.2. Suggested Use Restrictions 282 If the mailbox named in the RCPT TO command is known to have had only 283 a single continuous owner since creation, or not to have existed at 284 all (under any owner) prior to the time specified in the parameter, 285 then the field can be silently ignored and normal message handling 286 applied so that this information is not disclosed. Such parameters 287 are likely the product of either gross error or an attack. 289 A message author using this specification might restrict use of the 290 extension such that it is only done for recipients known also to 291 implement this specification, in order to reduce the possibility of 292 revealing information about the relationship between the author and 293 the mailbox. 295 If ownership of an entire domain is transferred, the new owner may 296 not know what addresses were assigned in the past by the prior owner. 297 Hence, no address can be known not to have had a single owner, or to 298 have existed (or not) at all. 300 10. Privacy Considerations 302 10.1. Probing Attacks 304 As described above, use of this extension in probing attacks can 305 disclose information about the history of the mailbox. The harm that 306 can be done by leaking any kind of private information is difficult 307 to predict, so it is prudent to be sensitive to this sort of 308 disclosure, be it inadvertently or in response to probing by an 309 attacker. It bears restating, then, that implementing 310 countermeasures to abuse of this capability needs strong 311 consideration. 313 That some MSPs allow for expiration of account names when they have 314 been unused for a protracted period forces a choice between two 315 potential types of privacy vulnerabilities, one of which presents 316 significantly greater threats to users than the other. Automatically 317 generated mail is often used to convey authentication credentials 318 that can potentially provide access to extremely sensitive 319 information. Supplying such credentials to the wrong party after a 320 mailbox ownership change could allow the previous owner's data to be 321 exposed without his or her authorization or knowledge. In contrast, 322 the information that may be exposed to a third party via the proposal 323 in this document is limited to information about the mailbox history. 324 Given that MSPs have chosen to allow transfers of mailbox ownership 325 without the prior owner's involvement, the information leakage from 326 the header field specified here creates far fewer risks than the 327 potential for delivering mail to the wrong party. 329 11. IANA Considerations 331 11.1. SMTP Extension Registration 333 IANA is requested to register the SMTP extension described in 334 Section 3.1. 336 11.2. Enhanced Status Code Registration 338 IANA is requested to register the following in the SMTP Enhanced 339 Status Codes registry: 341 Code: X.7.15 342 Sample Text: Mailbox owner has changed 343 Associated basic status code: 5 344 Description: This status code is returned when a message is 345 received with a Require-Recipient-Valid-Since 346 field and the receiving system is able to 347 determine that the intended recipient mailbox 348 has not been under continuous ownership since 349 the specified date. 350 Reference: [this document] 351 Submitter: M. Kucherawy 352 Change controller: IESG 354 12. References 356 12.1. Normative References 358 [DATETIME] Klyne, G. and C. Newman, "Date and Time on the 359 Internet: Timestamps", RFC 3339, July 2002. 361 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [ROLES] Crocker, D., "Mailbox Names For Common Services, Roles 365 And Functions", RFC 2142, May 1997. 367 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 368 October 2008. 370 12.2. Informative References 372 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 373 July 2009. 375 [ESC] Vaudreuil, G., "Enhanced Mail System Status Codes", 376 RFC 3463, January 2003. 378 Appendix A. Acknowledgments 380 Erling Ellingsen proposed the idea. 382 Reviews and comments were provided by Michael Adkins, Kurt Andersen, 383 Alissa Cooper, Dave Cridland, Dave Crocker, Ned Freed, John Levine, 384 Hector Santos, Gregg Stefancik, Ed Zayas, (others) 386 Authors' Addresses 388 William J. Mills 389 Yahoo! Inc. 391 EMail: wmills_92105@yahoo.com 393 Murray S. Kucherawy 394 Facebook, Inc. 395 1 Hacker Way 396 Menlo Park, CA 94025 397 USA 399 EMail: msk@fb.com