idnits 2.17.1 draft-ietf-appsawg-rrvs-header-field-08.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 20, 2014) is 3688 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) -- Obsolete informational reference (is this intentional?): RFC 7001 (ref. 'AUTHRES') (Obsoleted by RFC 7601) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: September 21, 2014 Facebook, Inc. 6 March 20, 2014 8 The Require-Recipient-Valid-Since Header Field and SMTP Service 9 Extension 10 draft-ietf-appsawg-rrvs-header-field-08 12 Abstract 14 This document defines an extension for the Simple Mail Transfer 15 Protocol called RRVS, and a header field called Require-Recipient- 16 Valid-Since, to provide a method for senders to indicate to receivers 17 the point in time when the sender last confirmed the ownership of the 18 target mailbox. This can be used to detect changes of mailbox 19 ownership, and thus prevent mail from being delivered to the wrong 20 party. 22 The intended use of these facilities is on automatically generated 23 messages that might contain sensitive information, though it may also 24 be useful in other applications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 21, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. The 'RRVS' SMTP Extension . . . . . . . . . . . . . . . . 5 64 3.2. The 'Require-Recipient-Valid-Since' Header Field . . . . . 5 65 3.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Use By Generators . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Handling By Receivers . . . . . . . . . . . . . . . . . . . . 7 68 5.1. SMTP Extension Used . . . . . . . . . . . . . . . . . . . 7 69 5.1.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.2. Header Field Used . . . . . . . . . . . . . . . . . . . . 8 71 5.2.1. Design Choices . . . . . . . . . . . . . . . . . . . . 9 72 5.3. Clock Synchronization . . . . . . . . . . . . . . . . . . 10 73 6. Role Accounts . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 10 75 7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 10 76 8. Header Field with Multiple Recipients . . . . . . . . . . . . 11 77 9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 12 78 9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 12 79 9.2. Single-Recipient Aliases . . . . . . . . . . . . . . . . . 12 80 9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 13 81 9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 13 82 9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 13 83 10. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 13 84 11. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 14 85 12. Authentication-Results Definitions . . . . . . . . . . . . . . 15 86 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 15 88 13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 16 89 13.3. Authentication-Results Example . . . . . . . . . . . . . . 16 90 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 17 92 14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 17 93 14.3. False Sense of Security . . . . . . . . . . . . . . . . . 17 94 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18 95 15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 18 96 15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 18 97 15.3. Risks with Use . . . . . . . . . . . . . . . . . . . . . . 19 98 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 99 16.1. SMTP Extension Registration . . . . . . . . . . . . . . . 19 100 16.2. Header Field Registration . . . . . . . . . . . . . . . . 19 101 16.3. Enhanced Status Code Registration . . . . . . . . . . . . 19 102 16.4. Authentication Results Registration . . . . . . . . . . . 20 103 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 17.1. Normative References . . . . . . . . . . . . . . . . . . . 21 105 17.2. Informative References . . . . . . . . . . . . . . . . . . 21 106 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 108 1. Introduction 110 Email addresses sometimes get reassigned to a different person. For 111 example, employment changes at a company can cause an address used 112 for an ex-employee to be assigned to a new employee, or a mail 113 service provider (MSP) might expire an account and then let someone 114 else register for the local-part that was previously used. Those who 115 sent mail to the previous owner of an address might not know that it 116 has been reassigned. This can lead to the sending of email to the 117 correct address, but the wrong recipient. 119 What is needed is a way to indicate an attribute of the recipient 120 that will distinguish between the previous owner of an address and 121 its current owner, if they are different. Further, this needs to be 122 done in a way that respects privacy. 124 The mechanisms specified here allow the sender of the mail to 125 indicate how "old" the address assignment is expected to be. In 126 effect, the sender is saying, "The last time the intended recipient 127 was known to be using this address was this point in time." A 128 receiving system can then compare this information against the point 129 in time at which the address was assigned to its current user. If 130 the assignment was made later than the point in time indicated in the 131 message, there is a good chance the current user of the address is 132 not the correct recipient. The receiving system can then choose to 133 prevent delivery and, possibly, to notify the original sender of the 134 problem. 136 The primary application is automatically generated messages rather 137 than user-authored content, though it may be useful in other 138 contexts. 140 One important point is that the protocols presented here provide a 141 way for a sending system to make a request to receiving systems with 142 respect to handling of a message. In the end, there is no guarantee 143 that the request will have the desired effect. 145 2. Definitions 147 For a description of the email architecture, consult [EMAIL-ARCH]. 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [KEYWORDS]. 153 3. Description 155 To address the problem described above, a mail sending client needs 156 to indicate to the server to which it is connecting that there is an 157 expectation that the destination of the message has been under 158 continuous ownership (see Section 10) since some point in time, 159 presumably the most recent time the message author had confirmed its 160 understanding of who owned that mailbox. Two mechanisms are defined 161 here: an extension to the Simple Mail Transfer Protocol [SMTP] and a 162 new message header field. The SMTP extension permits strong 163 assurance of enforcement by confirming support at each handling step 164 for a message. The header field does not provide the strong 165 assurance, but only requires adoption by the receiving Message 166 Delivery Agent (MDA). 168 The SMTP extension is called "RRVS" (Require Recipient Valid Since), 169 and adds a parameter to the SMTP "RCPT" command that indicates the 170 most recent point in time when the message author believed the 171 destination mailbox to be under the continuous ownership of a 172 specific party. Similarly, the Require-Recipient-Valid-Since header 173 field includes an intended recipient coupled with a timestamp 174 indicating the same thing. 176 3.1. The 'RRVS' SMTP Extension 178 Extensions to SMTP are described in Section 2.2 of [SMTP]. 180 The name of the extension is "RRVS", an abbreviation of "Require 181 Recipient Valid Since". Servers implementing the SMTP extension 182 advertise an additional EHLO keyword of "RRVS", which has no 183 associated parameters, introduces no new SMTP commands, and does not 184 alter the MAIL command. 186 A Message Transfer Agent (MTA) implementing RRVS can transmit or 187 accept a new parameter to the RCPT command. An MDA can also accept 188 this new parameter. The new parameter is "RRVS", which takes a value 189 that is a timestamp expressed as a "date-time" as defined in 190 [DATETIME], with the added restriction that a "time-secfrac" MUST NOT 191 be used. Accordingly, this extension increases the maximum command 192 length for the RCPT command by 31 characters. 194 The meaning of this extension, when used, is described in 195 Section 5.1. 197 3.2. The 'Require-Recipient-Valid-Since' Header Field 199 The general constraints on syntax and placement of header fields in a 200 message are defined in Internet Message Format [MAIL]. 202 Using Augmented Backus-Naur Form [ABNF], the syntax for the field is: 204 rrvs = "Require-Recipient-Valid-Since:" addr-spec ";" date-time 205 CRLF 207 "date-time" is defined in Section 3.3, and "addr-spec" is defined in 208 Section 3.4.1, of [MAIL]. 210 3.3. Timestamps 212 The header field version of this protocol has a different format for 213 the date and time expression than the SMTP extension does. This is 214 because message header fields use a format to express time and date 215 that is specific to message header fields, and this is consistent 216 with that usage. 218 Use of both date and time is done to be consistent with how current 219 implementations typically store the timestamp, and to make it easy to 220 include the time zone. In practice, granularity beyond the date may 221 or may not be useful. 223 4. Use By Generators 225 When a message is generated whose content is sufficiently sensitive 226 that an author or author's Administrative Management Domain (ADMD; 227 see [EMAIL-ARCH]) wishes to protect against misdelivery using this 228 protocol, it determines for each recipient mailbox on the message a 229 timestamp at which it last confirmed ownership of that mailbox. It 230 then applies either the SMTP extension or the header field defined 231 above when sending the message to its destination. 233 Use of the SMTP extension provided here is preferable over the header 234 field method because of: 236 1. the positive confirmation of support at each handling node; 238 2. the fact that the protocol is focused on affecting delivery (that 239 is, the transaction) rather than on content; and 241 3. the fact that there is less risk of the timestamp parameter being 242 inadvertently forwarded (see Section 15.3). 244 The header field mechanism is defined only to enable passage of the 245 request between and through systems that do not implement the SMTP 246 extension. 248 5. Handling By Receivers 250 If a receiver implements this specification, then there are two 251 possible evaluation paths: 253 1. The sending client implements the extension, and so there was an 254 RRVS parameter on a RCPT TO command in the SMTP session and the 255 parameters of interest are taken only from there (and the header 256 field, if present, is disregarded); or 258 2. The sending client does not (or elected not to) implement the 259 extension, so the RRVS parameter was not present on the RCPT TO 260 commands in the SMTP session, but the corresponding header field 261 might be present in the message. 263 5.1. SMTP Extension Used 265 For an MTA supporting the SMTP extension, the requirement is to 266 continue enforcement of RRVS during the relaying process to the next 267 MTA or the MDA. 269 A receiving MTA or MDA that implements the SMTP extension declared 270 above and observes an RRVS parameter on a RCPT TO command checks 271 whether the current owner of the destination mailbox has held it 272 continuously, far enough back to include the given point in time, and 273 delivers it unless that check returns in the negative. Specifically, 274 an MDA will do the following before continuing with delivery: 276 1. Ignore the parameter if the named mailbox is known to be a role 277 account as listed in Mailbox Names For Common Services, Roles And 278 Functions [ROLES]. (See Section 6.) 280 2. If the address is not known to be a role account, and if that 281 address has not been under continuous ownership since the 282 timestamp specified in the extension, return a 550 error to the 283 RCPT command. (See also Section 16.3.) 285 3. If any Require-Recipient-Valid-Since header fields are present 286 and refer to the named address, they SHOULD be removed prior to 287 delivery or relaying. (See Section 5.2 and Section 7.1 for 288 discussion.) 290 5.1.1. Relays 292 An MTA that does not make mailbox ownership checks, such as an MTA 293 positioned to do SMTP ingress at an organizational boundary, SHOULD 294 relay the RRVS extension parameter to the next MTA or MDA so that it 295 can be processed there. 297 See Section 9.2 for additional discussion. 299 5.2. Header Field Used 301 A receiving system that implements this specification, upon receiving 302 a message bearing a Require-Recipient-Valid-Since header field when 303 no corresponding RRVS SMTP extension was used, checks whether the 304 destination mailbox owner has held it continuously, far enough back 305 to include the given date-time, and delivers it unless that check 306 returns in the negative. Expressed as a sequence of steps: 308 1. Extract those Require-Recipient-Valid-Since fields from the 309 message that contain a recipient for which no corresponding RRVS 310 SMTP extension was used. 312 2. Discard any such fields that match any of these criteria: 314 * are syntactically invalid; 316 * name a role account as listed in [ROLES] (see Section 6); 318 * the "addr-spec" portion does not match a current recipient, as 319 listed in the RCPT TO commands in the SMTP session; or 321 * the "addr-spec" portion does not refer to a mailbox handled 322 for local delivery by this ADMD. 324 3. For each field remaining, determine if the named address has been 325 under continuous ownership since the corresponding timestamp. If 326 it has not, reject the message. 328 4. RECOMMENDED: If local delivery is being performed, remove all 329 instances of this field prior to delivery to a mailbox; if the 330 message is being forwarded, remove those instances of this header 331 field that were not discarded by steps 1-4 above. 333 Handling proceeds normally upon completion of the above steps if 334 rejection has not been performed. 336 The final step is not mandatory as not all mail handling agents are 337 capable of stripping away header fields, and there are sometimes 338 reasons to keep the field intact such as debugging or presence of 339 digital signatures that might be invalidated by such a change. See 340 Section 11 for additional discussion. 342 If a message is to be rejected within the SMTP protocol itself 343 (versus generating a rejection message separately), servers 344 implementing this protocol SHOULD also implement the SMTP extension 345 described in Enhanced Mail System Status Codes [ESC] and use the 346 enhanced status codes described in Section 16.3 as appropriate. 348 Implementation by this method is expected to be transparent to non- 349 participants, since they would typically ignore this header field. 351 This header field is not normally added to a message that is 352 addressed to multiple recipients. The intended use of this field 353 involves an author seeking to protect transactional or otherwise 354 sensitive data intended for a single recipient, and thus generating 355 independent messages for each individual recipient is normal 356 practice. See Section 8 for further discussion. 358 5.2.1. Design Choices 360 The presence of the intended address in the field content supports 361 the case where a message bearing this header field is forwarded. The 362 specific use case is as follows: 364 1. A user subscribes to a service "S" on date "D" and confirms an 365 email address at the user's current location, "A"; 367 2. At some later date, the user intends to leave the current 368 location, and thus creates a new mailbox elsewhere, at "B"; 370 3. The user replaces address "A" with forwarding to "B"; 372 4. "S" constructs a message to "A" claiming that address was valid 373 at date "D" and sends it to "A"; 375 5. The receiving MTA at "A" determines that the forwarding in effect 376 was created by the same party that owned the mailbox there, and 377 thus concludes the continuous ownership test has been satisfied; 379 6. If possible, "A" removes this header field from the message, and 380 in either case, forwards it to "B"; 382 7. On receipt at "B", either the header field has been removed, or 383 the header field does not refer to a current envelope recipient, 384 and in either case delivers the message. 386 SMTP has never required any correspondence between addresses in the 387 RFC5321.MailFrom and RFC5321.RcptTo parameters and header fields of a 388 message, which is why the header field defined here contains the 389 recipient address to which the timestamp applies. 391 5.3. Clock Synchronization 393 The timestamp portion of this specification supports a precision at 394 the seconds level. Although uncommon, it is not impossible for a 395 clock at either a generator or a receiver to be incorrect, leading to 396 an incorrect result in the RRVS evaluation. 398 To minimize the risk of such incorrect results, both generators and 399 receivers implementing this specification MUST use a standard clock 400 synchronization protocol such as [NTP]. 402 6. Role Accounts 404 It is necessary not to interfere with delivery of messages to role 405 mailboxes (see [ROLES]), but it could be useful to notify users 406 sending to those mailboxes that a change of ownership might have 407 taken place, if such notification is possible. 409 7. Relaying Without RRVS Support 411 When a message is received using the SMTP extension defined here but 412 will not be delivered locally (that is, it needs to be relayed 413 further), the MTA to which the relay will take place might not be 414 compliant with this specification. Where the MTA in possession of 415 the message observes it is going to relay the message to an MTA that 416 does not advertise this extension, it needs to choose one of the 417 following actions: 419 1. Decline to relay the message further, preferably generating a 420 Delivery Status Notification [DSN] to indicate failure 421 (RECOMMENDED); 423 2. Downgrade the data thus provided in the SMTP extension to a 424 header field, as described in Section 7.1 below (RECOMMENDED when 425 the previous option is not available); or 427 3. Silently continue with delivery, dropping the protection offered 428 by this protocol. 430 Using other than the first option needs to be avoided unless there is 431 specific knowledge that further relaying with the degraded 432 protections thus provided does not introduce undue risk. 434 7.1. Header Field Conversion 436 If an SMTP server ("B") that has received mailbox timestamps from a 437 client ("A") using this extension but then needs to relay the 438 corresponding message on to another server ("C") (thereby becoming a 439 client), but "C" does not advertise the SMTP extension and "B" elects 440 not to reject the message, "B" SHOULD add Require-Recipient-Valid- 441 Since header fields matching each mailbox to which relaying is being 442 done, and the corresponding valid-since timestamp for each. 444 Similarly, if "B" receives a message bearing one or more Require- 445 Recipient-Valid-Since header fields from "A" for which it must now 446 relay the message, and "C" advertises support for the SMTP extension, 447 "B" SHOULD delete the header field(s) and instead relay this 448 information by making use of the SMTP extension. Note that such 449 modification of the header might affect later validation of the 450 header upon delivery; for example, a hash of the header would produce 451 a different result. This might be a valid cause for some operators 452 to skip this delete operation. 454 8. Header Field with Multiple Recipients 456 Numerous issues arise when using the header field form of this 457 extension, particularly when multiple recipients are specified for a 458 single message resulting in one multiple fields each with a distinct 459 address and timestamp. 461 Because of the nature of SMTP, a message bearing a multiplicity of 462 Require-Recipient-Valid-Since header fields could result in a single 463 delivery attempt for multiple recipients (in particular, if two of 464 the recipients are handled by the same server), and if any one of 465 them fails the test, the delivery fails to all of them; it then 466 becomes necessary to do one of the following: 468 o reject the message on completion of the DATA phase of the SMTP 469 session, which is a rejection of delivery to all recipients; or 471 o accept the message on completion of DATA, and then generate a 472 Delivery Status Notification [DSN] message for each of the failed 473 recipients 475 Additional complexity arises when a message is sent to two 476 recipients, "A" and "B", presumably with different timestamps, both 477 of which are then redirected to a common address "C". The author is 478 not necessarily aware of the current or past ownership of mailbox 479 "C", or indeed that "A" and/or "B" have been redirected. This might 480 result in either or both of the two deliveries failing at "C", which 481 is likely to confuse the message author, who (as far as the author is 482 aware) never sent a message to "C" in the first place. 484 9. Special Use Addresses 486 In [DSN-SMTP], an SMTP extension was defined to allow SMTP clients to 487 request generation of DSNs, and related information to allow such 488 reports to be maximally useful. Section 5.2.7 of that document 489 explored the issue of the use of that extension where the recipient 490 is a mailing list. This extension has similar concerns which are 491 covered here following that document as a model. 493 9.1. Mailing Lists 495 Delivery to a mailing list service is considered a final delivery. 496 Where this protocol is in use, it is evaluated as per any normal 497 delivery: If the same mailing list has been operating in place of the 498 specified recipient mailbox since at least the timestamp given as the 499 RRVS parameter, the message is delivered to the list service 500 normally, and is otherwise not delivered. 502 It is important, however, that the participating MDA passing the 503 message to the list service needs to omit the RRVS parameter in 504 either form (SMTP extension or header field) when doing so. The 505 emission of a message from the list service to its subscribers 506 constitutes a new message not covered by the previous transaction. 508 9.2. Single-Recipient Aliases 510 Upon delivery of an RRVS-protected message to an alias (acting in 511 place of a mailbox) that results in relaying of the message to a 512 single other destination, the usual RRVS check is performed. The 513 continuous ownership test here might succeed if a conventional user 514 inbox was replaced with an alias on behalf of that same user, and 515 this information is recorded someplace. If the message is thus 516 accepted, the relaying MTA can choose to do one of the following: 518 1. Do not include an RRVS parameter or header field when relaying to 519 the new address. (RECOMMENDED) 521 2. If the relaying system records the time when the alias was 522 established, independent of confirming the validity of the new 523 destination address, it MAY add an RRVS parameter for the new 524 target address that includes that time. 526 3. If an explicit confirmation of the new destination was done, it 527 MAY add an RRVS parameter for the new target address that 528 includes that time. 530 There is risk and additional administrative burden associated with 531 all but the first option in that list which are believed to make them 532 not worth pursuing. 534 9.3. Multiple-Recipient Aliases 536 Upon delivery of an RRVS-protected message to an alias (acting in 537 place of a mailbox) that results in relaying of the message to 538 multiple other destinations, the usual RRVS check is performed as in 539 Section 9.2. The MTA expanding such an alias then decides which of 540 the options enumerated in that section is to be applied for each new 541 recipient. 543 9.4. Confidential Forwarding Addresses 545 In the above cases, the original author could receive message 546 rejections, such as DSNs, from the ultimate destination, where the 547 RRVS check (or indeed, any other) fails and rejection is warranted. 548 This can reveal the existence of a forwarding relationship between 549 the original intended recipient and the actual final recipient. 551 Where this is a concern, the initial delivery attempt is to be 552 treated like a mailing list delivery, with RRVS evaluation done and 553 then all RRVS information removed from the message prior to relaying 554 it to its true destination. 556 9.5. Suggested Mailing List Enhancements 558 Mailing list services could store the timestamp at which a subscriber 559 was added to a mailing list. This specification could then be used 560 in conjunction with that information in order to restrict list 561 traffic to the original subscriber, rather than a different person 562 now in possession of an address under which the original subscriber 563 was added to the list. Upon receiving a rejection caused by this 564 specification, the list service can remove that address from further 565 distribution. 567 A mailing list service that receives a message containing the header 568 field defined here needs to remove it from the message prior to 569 redistributing it, limiting exposure of information regarding the 570 relationship between the message's author and the mailing list. 572 10. Continuous Ownership 574 For the purposes of this specification, an address is defined as 575 having been under continuous ownership since a given date-time if a 576 message sent to the address at any point since the given date would 577 not go to anyone except the owner at that given date-time. That is, 578 while an address may have been suspended or otherwise disabled for 579 some period, any mail actually delivered would have been delivered 580 exclusively to the same owner. It is presumed that some sort of 581 relationship exists between the message sender and the intended 582 recipient. Presumably there has been some confirmation process 583 applied to establish this ownership of the receiver's mailbox; 584 however, the method of making such determinations is a local matter 585 and outside the scope of this document. 587 Evaluating the notion of continuous ownership is accomplished by 588 doing any query that establishes whether the above condition holds 589 for a given mailbox. 591 Determining continuous ownership of a mailbox is a local matter at 592 the receiving site. The only possible answers to the continuous- 593 ownership-since question are "yes", "no", and "unknown"; the action 594 to be taken in the "unknown" case is a matter of local policy. 596 For example, when control of a domain name is transferred, the new 597 domain owner might be unable to determine whether the owner of the 598 subject address has been under continuous ownership since the stated 599 date if the mailbox history is not also transferred (or was not 600 previously maintained). It will also be "unknown" if whatever 601 database contains mailbox ownership data is temporarily unavailable 602 at the time a message arrives for delivery. In this latter case, 603 typical SMTP temporary failure handling is appropriate. 605 To avoid exposing account details unnecessarily, if the address 606 specified has had one continuous owner since it was created, any 607 confirmation date SHOULD be considered to pass the test, even if that 608 date is earlier than the account creation date. This is further 609 discussed in Section 14. 611 11. Digital Signatures 613 This protocol mandates removal of the header field (when used) upon 614 delivery in all but exceptional circumstances. Altering a message in 615 this way will invalidate a digital signature intended to guard 616 against message modification in transit, which can interfere with 617 delivery. 619 Section 5.4.1 of DomainKeys Identified Mail [DKIM] proposes a 620 strategy for selecting header fields to sign. Specifically, it 621 advises including in the signed portion of the message only those 622 header fields that comprise part of the core content of the message. 623 As the header field version of this protocol is ephemeral, it cannot 624 be considered core content. 626 Accordingly, applying digital signatures that attempt to protect the 627 content of this header field is NOT RECOMMENDED. 629 12. Authentication-Results Definitions 631 [AUTHRES] defines a mechanism for indicating, via a header field, the 632 results of message authentication checks. Section 16 registers RRVS 633 as a new method that can be reported in this way, and corresponding 634 result names. The possible result names and their meanings are as 635 follows: 637 none: The message had no recipient mailbox timestamp associated with 638 it, either via the SMTP extension or header field method; this 639 protocol was not in use. 641 unknown: At least one form of this protocol was in use, but 642 continuous ownership of the recipient mailbox could not be 643 determined. 645 temperror: At least one form of this protocol was in use, but some 646 kind of error occurred during evaluation that was transient in 647 nature; a later retry will likely produce a final result. 649 permerror: At least one form of this protocol was in use, but some 650 kind of error occurred during evaluation that was not recoverable; 651 a later retry will not likely produce a final result. 653 pass: At least one form of this protocol was in use, and the 654 destination mailbox was confirmed to have been under continuous 655 ownership since the timestamp thus provided. 657 fail: At least one form of this protocol was in use, and the 658 destination mailbox was confirmed not to have been under 659 continuous ownership since the timestamp thus provided. 661 Where multiple recipients are present on a message, multiple results 662 can be reported using the mechanism described in [AUTHRES]. 664 13. Examples 666 In the following examples, "C:" indicates data sent by an SMTP 667 client, and "S:" indicates responses by the SMTP server. Message 668 content is CRLF terminated, though these are omitted here for ease of 669 reading. 671 13.1. SMTP Extension Example 672 C: [connection established] 673 S: 220 server.example.com ESMTP ready 674 C: EHLO client.example.net 675 S: 250-server.example.com 676 S: 250 RRVS 677 C: MAIL FROM: 678 S: 250 OK 679 C: RCPT TO: RRVS=2014-04-03T23:01:00Z 680 S: 550 5.7.17 receiver@example.com is no longer valid 681 C: QUIT 682 S: 221 So long! 684 13.2. Header Field Example 686 C: [connection established] 687 S: 220 server.example.com ESMTP ready 688 C: HELO client.example.net 689 S: 250 server.example.com 690 C: MAIL FROM: 691 S: 250 OK 692 C: RCPT TO: 693 S: 250 OK 694 C: DATA 695 S: 354 Ready for message content 696 C: From: Mister Sender 697 To: Miss Receiver 698 Subject: Are you still there? 699 Date: Fri, 28 Jun 2013 18:01:01 +0200 700 Require-Recipient-Valid-Since: receiver@example.com; 701 Sat, 1 Jun 2013 09:23:01 -0700 703 Are you still there? 704 . 705 S: 550 5.7.17 receiver@example.com is no longer valid 706 C: QUIT 707 S: 221 So long! 709 13.3. Authentication-Results Example 711 An example use of the Authentication-Results header field used to 712 yield the results of an RRVS evaluation: 714 Authentication-Results: mx.example.com; rrvs=pass 715 smtp.rcptto=user@example.com 717 This indicates that the message arrived addressed to the mailbox 718 user@example.com, the continuous ownership test was applied with the 719 provided timestamp, and the check revealed that test was satisfied. 720 The timestamp is not revealed. 722 14. Security Considerations 724 14.1. Abuse Countermeasures 726 The response of a server implementing this protocol can disclose 727 information about the age of an existing email mailbox. 728 Implementation of countermeasures against probing attacks is 729 RECOMMENDED. For example, an operator could track appearance of this 730 field with respect to a particular mailbox and observe the timestamps 731 being submitted for testing; if it appears a variety of timestamps is 732 being tried against a single mailbox in short order, the field could 733 be ignored and the message silently discarded. This concern is 734 discussed further in Section 15. 736 14.2. Suggested Use Restrictions 738 If the mailbox named in the field is known to have had only a single 739 continuous owner since creation, or not to have existed at all (under 740 any owner) prior to the date specified in the field, then the field 741 SHOULD be silently ignored and normal message handling applied so 742 that this information is not disclosed. Such fields are likely the 743 product of either gross error or an attack. 745 A message author using this specification might restrict inclusion of 746 the header field such that it is only done for recipients known also 747 to implement this specification, in order to reduce the possibility 748 of revealing information about the relationship between the author 749 and the mailbox. 751 If ownership of an entire domain is transferred, the new owner may 752 not know what addresses were assigned in the past by the prior owner. 753 Hence, no address can be known not to have had a single owner, or to 754 have existed (or not) at all. In this case, the "unknown" result is 755 likely appropriate. 757 14.3. False Sense of Security 759 Senders implementing this protocol likely believe their content is 760 being protected by doing so. It has to be considered, however, that 761 receiving systems might not implement this protocol correctly, or at 762 all. Furthermore, use of RRVS by a sending system constitutes 763 nothing more than a request to the receiving system; that system 764 could choose not to prevent delivery for some local policy, legal or 765 operational reason, which compromises the security the sending system 766 believed was a benefit to using RRVS. This could mean the timestamp 767 information involved in the protocol becomes inadvertently revealed. 769 This concern lends further support to the notion that senders would 770 do well to avoid using this protocol other than when sending to 771 known, trusted receivers. 773 15. Privacy Considerations 775 15.1. Probing Attacks 777 As described above, use of this extension or header field in probing 778 attacks can disclose information about the history of the mailbox. 779 The harm that can be done by leaking any kind of private information 780 is difficult to predict, so it is prudent to be sensitive to this 781 sort of disclosure, either inadvertently or in response to probing by 782 an attacker. It bears restating, then, that implementing 783 countermeasures to abuse of this capability needs strong 784 consideration. 786 That some MSPs allow for expiration of account names when they have 787 been unused for a protracted period forces a choice between two 788 potential types of privacy vulnerabilities, one of which presents 789 significantly greater threats to users than the other. Automatically 790 generated mail is often used to convey authentication credentials 791 that can potentially provide access to extremely sensitive 792 information. Supplying such credentials to the wrong party after a 793 mailbox ownership change could allow the previous owner's data to be 794 exposed without his or her authorization or knowledge. In contrast, 795 the information that may be exposed to a third party via the proposal 796 in this document is limited to information about the mailbox history. 797 Given that MSPs have chosen to allow transfers of mailbox ownership 798 without the prior owner's involvement, the information leakage from 799 the extensions specified here creates far fewer risks than the 800 potential for delivering mail to the wrong party. 802 15.2. Envelope Recipients 804 The email To and Cc header fields are not required to be populated 805 with addresses that match the envelope recipient set, and Cc may even 806 be absent. However, the algorithm in Section 3 requires that this 807 header field contain a match for an envelope recipient in order to be 808 actionable. As such, use of this specification can reveal some or 809 all of the original intended recipient set to any party that can see 810 the message in transit or upon delivery. 812 For a message destined to a single recipient, this is unlikely to be 813 a concern, which is one of the reasons use of this specification on 814 multi-recipient messages is discouraged. 816 15.3. Risks with Use 818 MDAs might not implement the recommendation to remove the header 819 field defined here when messages are delivered, either out of 820 ignorance or due to error. Since user agents often do not render all 821 of the header fields present, the message could be forwarded to 822 another party that would then inadvertently have the content of this 823 header field. 825 A bad actor may detect use of either form of the RRVS protocol and 826 interpret it as an indication of high value content. 828 16. IANA Considerations 830 16.1. SMTP Extension Registration 832 Section 2.2.2 of [MAIL] sets out the procedure for registering a new 833 SMTP extension. IANA is requested to register the SMTP extension 834 using the details provided in Section 3.1 of this document. 836 16.2. Header Field Registration 838 IANA is requested to add the following entry to the Permanent Message 839 Header Field Names registry, as per the procedure found in 840 [IANA-HEADERS]: 842 Header field name: Require-Recipient-Valid-Since 843 Applicable protocol: mail ([MAIL]) 844 Status: Standard 845 Author/Change controller: IETF 846 Specification document(s): [this document] 847 Related information: 848 Requesting review of any proposed changes and additions to 849 this field is recommended. 851 16.3. Enhanced Status Code Registration 853 IANA is requested to register the following in the Enumerated Status 854 Codes table of the Simple Mail Transfer Protocol (SMTP) Enhanced 855 Status Codes Registry: 857 Code: X.7.17 858 Sample Text: Mailbox owner has changed 859 Associated basic status code: 5 860 Description: This status code is returned when a message is 861 received with a Require-Recipient-Valid-Since 862 field or RRVS extension and the receiving 863 system is able to determine that the intended 864 recipient mailbox has not been under 865 continuous ownership since the specified date. 866 Reference: [this document] 867 Submitter: M. Kucherawy 868 Change controller: IESG 870 Code: X.7.18 871 Sample Text: Domain owner has changed 872 Associated basic status code: 5 873 Description: This status code is returned when a message is 874 received with a Require-Recipient-Valid-Since 875 field or RRVS extension and the receiving 876 system wishes to disclose that the owner of 877 the domain name of the recipient has changed 878 since the specified date. 879 Reference: [this document] 880 Submitter: M. Kucherawy 881 Change controller: IESG 883 16.4. Authentication Results Registration 885 IANA is requested to register the following in the "Email 886 Authentication Methods" Registry: 888 Method: rrvs 890 Specifying Document: [this document] 892 ptype: smtp 894 Property: rcptto 896 Value: envelope recipient 898 Status: active 900 Version: 1 902 IANA is also requested to register the following in the "Email 903 Authentication Result Names" Registry: 905 Codes: none, unknown, temperror, permerror, pass, fail 907 Defined: [this document] 909 Auth Method(s): rrvs 911 Meaning: Section 12 of [this document] 913 Status: active 915 17. References 917 17.1. Normative References 919 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for 920 Syntax Specifications: ABNF", RFC 5234, January 2008. 922 [DATETIME] Klyne, G. and C. Newman, "Date and Time on the 923 Internet: Timestamps", RFC 3339, July 2002. 925 [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, 926 "Registration Procedures for Message Header Fields", 927 BCP 90, RFC 3864, September 2004. 929 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 930 Requirement Levels", BCP 14, RFC 2119, March 1997. 932 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 933 October 2008. 935 [NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. 936 Kasch, "Network Time Protocol Version 4: Protocol and 937 Algorithms Specification", RFC 5905, June 2010. 939 [ROLES] Crocker, D., "Mailbox Names For Common Services, 940 Roles And Functions", RFC 2142, May 1997. 942 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 943 RFC 5321, October 2008. 945 17.2. Informative References 947 [AUTHRES] Kucherawy, M., "Message Header Field for Indicating 948 Message Authentication Status", RFC 7001, 949 September 2013. 951 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, 952 Ed., "DomainKeys Identified Mail (DKIM) Signatures", 953 RFC 6376, September 2011. 955 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message 956 Format for Delivery Status Notifications", RFC 3464, 957 January 2003. 959 [DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) 960 Service Extension for Delivery Status Notifications 961 (DSNs)", RFC 3461, January 2003. 963 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 964 July 2009. 966 [ESC] Vaudreuil, G., "Enhanced Mail System Status Codes", 967 RFC 3463, January 2003. 969 Appendix A. Acknowledgments 971 Erling Ellingsen proposed the idea. 973 Reviews and comments were provided by Michael Adkins, Kurt Andersen, 974 Eric Burger, Alissa Cooper, Dave Cridland, Dave Crocker, Ned Freed, 975 John Levine, Alexey Melnikov, Jay Nancarrow, Hector Santos, Gregg 976 Stefancik, Ed Zayas, (others) 978 Authors' Addresses 980 William J. Mills 981 Yahoo! Inc. 983 EMail: wmills_92105@yahoo.com 985 Murray S. Kucherawy 986 Facebook, Inc. 987 1 Hacker Way 988 Menlo Park, CA 94025 989 USA 991 EMail: msk@fb.com