diff options
Diffstat (limited to 'doc/rfc/rfc7293.txt')
| -rw-r--r-- | doc/rfc/rfc7293.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7293.txt b/doc/rfc/rfc7293.txt new file mode 100644 index 0000000..8801d45 --- /dev/null +++ b/doc/rfc/rfc7293.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) W. Mills +Request for Comments: 7293 Yahoo! Inc. +Category: Standards Track M. Kucherawy +ISSN: 2070-1721 Facebook, Inc. + July 2014 + + + The Require-Recipient-Valid-Since Header Field + and SMTP Service Extension + +Abstract + + This document defines an extension for the Simple Mail Transfer + Protocol (SMTP) called "RRVS" to provide a method for senders to + indicate to receivers a point in time when the ownership of the + target mailbox was known to the sender. This can be used to detect + changes of mailbox ownership and thus prevent mail from being + delivered to the wrong party. This document also defines a header + field called "Require-Recipient-Valid-Since" that can be used to + tunnel the request through servers that do not support the extension. + + The intended use of these facilities is on automatically generated + messages, such as account statements or password change instructions, + that might contain sensitive information, though it may also be + useful in other applications. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7293. + + + + + + + + + + + + +Mills & Kucherawy Standards Track [Page 1] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. The "RRVS" SMTP Extension . . . . . . . . . . . . . . . . 5 + 3.2. The "Require-Recipient-Valid-Since" Header Field . . . . 5 + 3.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Use By Generators . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Handling By Receivers . . . . . . . . . . . . . . . . . . . . 7 + 5.1. SMTP Extension Used . . . . . . . . . . . . . . . . . . . 7 + 5.1.1. Relays . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.2. Header Field Used . . . . . . . . . . . . . . . . . . . . 9 + 5.2.1. Design Choices . . . . . . . . . . . . . . . . . . . 10 + 5.3. Clock Synchronization . . . . . . . . . . . . . . . . . . 11 + 6. Relaying without RRVS Support . . . . . . . . . . . . . . . . 11 + 6.1. Header Field Conversion . . . . . . . . . . . . . . . . . 11 + 7. Header Field with Multiple Recipients . . . . . . . . . . . . 12 + 8. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 13 + 8.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 13 + 8.2. Single-Recipient Aliases . . . . . . . . . . . . . . . . 13 + 8.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . 14 + 8.4. Confidential Forwarding Addresses . . . . . . . . . . . . 14 + 8.5. Suggested Mailing List Enhancements . . . . . . . . . . . 14 + 9. Continuous Ownership . . . . . . . . . . . . . . . . . . . . 15 + 10. Digital Signatures . . . . . . . . . . . . . . . . . . . . . 15 + 11. Authentication-Results Definitions . . . . . . . . . . . . . 16 + 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 12.1. SMTP Extension Example . . . . . . . . . . . . . . . . . 17 + 12.2. Header Field Example . . . . . . . . . . . . . . . . . . 17 + 12.3. Authentication-Results Example . . . . . . . . . . . . . 17 + + + + + +Mills & Kucherawy Standards Track [Page 2] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 13.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . 18 + 13.2. Suggested Use Restrictions . . . . . . . . . . . . . . . 18 + 13.3. False Sense of Security . . . . . . . . . . . . . . . . 18 + 13.4. Reassignment of Mailboxes . . . . . . . . . . . . . . . 19 + 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 + 14.1. The Tradeoff . . . . . . . . . . . . . . . . . . . . . . 19 + 14.2. Probing Attacks . . . . . . . . . . . . . . . . . . . . 19 + 14.3. Envelope Recipients . . . . . . . . . . . . . . . . . . 20 + 14.4. Risks with Use . . . . . . . . . . . . . . . . . . . . . 20 + 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 15.1. SMTP Extension Registration . . . . . . . . . . . . . . 20 + 15.2. Header Field Registration . . . . . . . . . . . . . . . 20 + 15.3. Enhanced Status Code Registration . . . . . . . . . . . 21 + 15.4. Authentication Results Registration . . . . . . . . . . 22 + 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 17.2. Informative References . . . . . . . . . . . . . . . . . 23 + +1. Introduction + + Email addresses sometimes get reassigned to a different person. For + example, employment changes at a company can cause an address used + for an ex-employee to be assigned to a new employee, or a mail + service provider (MSP) might expire an account and then let someone + else register for the local-part that was previously used. Those who + sent mail to the previous owner of an address might not know that it + has been reassigned. This can lead to the sending of email to the + correct address but the wrong recipient. This situation is of + particular concern with transactional mail related to purchases, + online accounts, and the like. + + What is needed is a way to indicate an attribute of the recipient + that will distinguish between the previous owner of an address and + its current owner, if they are different. Further, this needs to be + done in a way that respects privacy. + + The mechanisms specified here allow the sender of the mail to + indicate how "old" the address assignment is expected to be. In + effect, the sender is saying, "I know that the intended recipient was + using this address at this point in time. I don't want this message + delivered to anyone else". A receiving system can then compare this + information against the point in time at which the address was + assigned to its current user. If the assignment was made later than + the point in time indicated in the message, there is a good chance + + + + + +Mills & Kucherawy Standards Track [Page 3] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + the current user of the address is not the correct recipient. The + receiving system can then prevent delivery and, preferably, notify + the original sender of the problem. + + The primary application is transactional mail (such as account + information, password change requests, and other automatically + generated messages) rather than user-authored content. However, it + may be useful in other contexts; for example, a personal address book + could record the time an email address was added to it, and thus use + that time with this extension. + + Because the use cases for this extension are strongly tied to privacy + issues, attention to the Security Considerations (Section 13) and the + Privacy Considerations (Section 14) is particularly important. Note, + especially, the limitation described in Section 13.3. + +2. Definitions + + For a description of the email architecture, consult [EMAIL-ARCH]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORDS]. + +3. Description + + To address the problem described in Section 1, a mail-sending client + (usually an automated agent) needs to indicate to the server to which + it is connecting that it expects the destination address of the + message to have been under continuous ownership (see Section 9) since + a specified point time. That specified time would be the time when + the intended recipient gave the address to the message author, or + perhaps a more recent time when the intended recipient reconfirmed + ownership of the address with the sender. + + Two mechanisms are defined here: an extension to the Simple Mail + Transfer Protocol [SMTP] and a new message header field. The SMTP + extension permits strong assurance of enforcement by confirming + support at each handling step for a message and the option to demand + support at all nodes in the handling path of the message (and + returning of the message to the originator otherwise). The header + field can be used when the Message Delivery Agent (MDA) supports this + function, but an intermediary system between the sending system and + the MDA does not. However, the header field does not provide the + same strong assurance described above and is more prone to exposure + of private information (see Section 14.1). + + + + + +Mills & Kucherawy Standards Track [Page 4] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + The SMTP extension is called "RRVS" and adds a parameter to the SMTP + "RCPT" command that indicates the most recent point in time when the + message author believed the destination mailbox to be under the + continuous ownership of a specific party. Similarly, the "Require- + Recipient-Valid-Since" header field includes an intended recipient + coupled with a timestamp indicating the same thing. + +3.1. The "RRVS" SMTP Extension + + Extensions to SMTP are described in Section 2.2 of [SMTP]. + + The name of the extension is "RRVS", an abbreviation of "Require + Recipient Valid Since". Servers implementing the SMTP extension + advertise an additional EHLO keyword of "RRVS", which has no + associated parameters, introduces no new SMTP commands, and does not + alter the MAIL command. + + A Message Transfer Agent (MTA) implementing RRVS can transmit or + accept one new parameter to the RCPT command. An MDA can also accept + this new parameter. The parameter is "RRVS", and the value is a + timestamp expressed as "date-time" as defined in [DATETIME], with the + added restriction that a "time-secfrac" MUST NOT be used. The + timestamp MAY optionally be followed by a semicolon character and a + letter (known as the "no-support action"), indicating the action to + be taken when a downstream MTA is discovered that does not support + the extension. Valid actions are "R" (reject; the default) and "C" + (continue). + + Formally, the new parameter and its value are defined as follows: + + rrvs-param = "RRVS=" date-time [ ";" ( "C" / "R" ) ] + + Accordingly, this extension increases the maximum command length for + the RCPT command by 33 characters. + + The meaning of this extension, when used, is described in + Section 5.1. + +3.2. The "Require-Recipient-Valid-Since" Header Field + + The general constraints on syntax and placement of header fields in a + message are defined in "Internet Message Format" [MAIL]. + + Using Augmented Backus-Naur Form [ABNF], the syntax for the field is: + + rrvs = "Require-Recipient-Valid-Since:" addr-spec ";" date-time + CRLF + + + + +Mills & Kucherawy Standards Track [Page 5] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + "date-time" is defined in Section 3.3, and "addr-spec" is defined in + Section 3.4.1 of [MAIL]. + +3.3. Timestamps + + The header field version of this protocol has a different format for + the date and time expression than the SMTP extension does. This is + because message header fields use a format to express date and time + that is specific to message header fields, and this is consistent + with that usage. + + Use of both date and time is done to be consistent with how current + implementations typically store the timestamp and to make it easy to + include the time zone. In practice, granularity beyond the date may + or may not be useful. + +4. Use By Generators + + When a message is generated whose content is sufficiently sensitive + that an author or author's ADministrative Management Domain (ADMD), + see [EMAIL-ARCH], wishes to protect against misdelivery using this + protocol, it determines for each recipient mailbox on the message a + timestamp at which it last confirmed ownership of that mailbox. It + then applies the SMTP extension when sending the message to its + destination. + + In cases where the outgoing MTA does not support the extension, the + header field defined above can be used to pass the request through + that system. However, use of the header field is only a "best- + effort" approach to solving the stated goals, and it has some + shortcomings: + + 1. The positive confirmation of support at each handling node, with + the option to return the message to the originator when + end-to-end support cannot be confirmed, will be unavailable; + + 2. The protocol is focused on affecting delivery (that is, the + transaction) rather than content, and therefore use of a header + field in the content is generally inappropriate; + + 3. The mechanism cannot be used with multiple recipients without + unintentionally exposing information about one recipient to the + others (see Section 7); and + + 4. There is a risk of the timestamp parameter being inadvertently + forwarded, automatically or intentionally by the user (since user + agents might not reveal the presence of the header field), and + therefore exposed to unintended recipients. (See Section 14.4.) + + + +Mills & Kucherawy Standards Track [Page 6] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + Thus, the header field format MUST NOT be used unless the originator + or relay has specific knowledge that the receiving MDA or an + intermediary MTA will apply it properly. In any case, it SHOULD NOT + be used for the multi-recipient case. + + Use of the header field mechanism is further restricted by the + practices described in Section 7.2 of [SMTP], Section 3.6.3 of + [MAIL], and Section 7 of this document. + +5. Handling By Receivers + + If a receiver implements this specification, then there are two + possible evaluation paths: + + 1. The sending client uses the extension, and so there is an RRVS + parameter on a RCPT TO command in the SMTP session, and the + parameters of interest are taken only from there (and the header + field, if present, is disregarded); or + + 2. The sending client does not use the extension, so the RRVS + parameter is not present on the RCPT TO commands in the SMTP + session, but the corresponding header field might be present in + the message. + + When the continuous ownership test fails for transient reasons (such + as an unavailable database or other condition that is likely + temporary), normal transient failure handling for the message is + applied. + + If the continuous ownership test cannot be completed because the + necessary datum (the mailbox creation or reassignment date and time) + was not recorded, the MDA doing the evaluation selects a date and + time to use that is the latest possible point in time at which the + mailbox could have been created or reassigned. For example, this + might be the earliest of all recorded mailbox creation/reassignment + timestamps, or the time when the host was first installed. If no + reasonable substitute for the timestamp can be selected, the MDA + rejects the message using an SMTP reply code, preferably with an + enhanced mail system status code (see Section 15.3), that indicates + the test cannot be completed. A message originator can then decide + whether to reissue the message without RRVS protection or find + another way to reach the mailbox owner. + +5.1. SMTP Extension Used + + For an MTA supporting the SMTP extension, the requirement is to + continue enforcement of RRVS during the relaying process to the next + MTA or the MDA. + + + +Mills & Kucherawy Standards Track [Page 7] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + A receiving MTA or MDA that implements the SMTP extension declared + above and observes an RRVS parameter on a RCPT TO command checks + whether the current owner of the destination mailbox has held it + continuously, far enough back to include the given point in time, and + delivers it unless that check returns in the negative. Specifically, + an MDA will do the following before continuing with delivery: + + 1. Ignore the parameter if the named mailbox is known to be a role + account as listed in "Mailbox Names for Common Services, Roles + and Functions" [ROLES]. + + 2. If the address is not known to be a role account, and if that + address has not been under continuous ownership since the + timestamp specified in the extension, return a 550 error to the + RCPT command. (See also Section 15.3.) + +5.1.1. Relays + + An MTA that does not make mailbox ownership checks, such as an MTA + positioned to do SMTP ingress at an organizational boundary, SHOULD + relay the RRVS extension parameter to the next MTA or MDA so that it + can be processed there. + + For the SMTP extension, the optional RRVS parameter defined in + Section 5.1 indicates the action to be taken when relaying a message + to another MTA that does not advertise support for this extension. + When this is the case and the no-support action was not specified or + is "R" (reject), the MTA handling the message MUST reject the message + by: + + 1. returning a 550 error to the DATA command, if synchronous service + is being provided to the SMTP client that introduced the message, + or + + 2. generating a Delivery Status Notification [DSN] to indicate to + the originator of the message that the non-delivery occurred and + terminating further relay attempts. + + An enhanced mail system status code is defined for such rejections in + Section 15.3. + + See Section 8.2 for additional discussion. + + When relaying, an MTA MUST preserve the no-support action if it was + used by the SMTP client. + + + + + + +Mills & Kucherawy Standards Track [Page 8] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + +5.2. Header Field Used + + A receiving system that implements this specification, upon receiving + a message bearing a "Require-Recipient-Valid-Since" header field when + no corresponding RRVS SMTP extension was used, checks whether the + destination mailbox owner has held it continuously, far enough back + to include the given date-time, and delivers it unless that check + returns in the negative. Expressed as a sequence of steps: + + 1. Extract those Require-Recipient-Valid-Since fields from the + message that contain a recipient for which no corresponding RRVS + SMTP extension was used. + + 2. Discard any such fields that match any of these criteria: + + * are syntactically invalid; + + * name a role account as listed in [ROLES]; + + * the "addr-spec" portion does not match a current recipient, as + listed in the RCPT TO commands in the SMTP session; or + + * the "addr-spec" portion does not refer to a mailbox handled + for local delivery by this ADMD. + + 3. For each field remaining, determine if the named address has been + under continuous ownership since the corresponding timestamp. If + it has not, reject the message. + + 4. RECOMMENDED: If local delivery is being performed, remove all + instances of this field prior to delivery to a mailbox; if the + message is being forwarded, remove those instances of this header + field that were not discarded by step 2 above. + + Handling proceeds normally upon completion of the above steps if + rejection has not been performed. + + The final step is not mandatory as not all mail handling agents are + capable of stripping away header fields, and there are sometimes + reasons to keep the field intact such as debugging or presence of + digital signatures that might be invalidated by such a change. See + Section 10 for additional discussion. + + If a message is to be rejected within the SMTP protocol itself + (versus generating a rejection message separately), servers + implementing this protocol SHOULD also implement the SMTP extension + described in "Enhanced Mail System Status Codes" [ESC] and use the + enhanced status codes described in Section 15.3 as appropriate. + + + +Mills & Kucherawy Standards Track [Page 9] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + Implementation by this method is expected to be transparent to non- + participants, since they would typically ignore this header field. + + This header field is not normally added to a message that is + addressed to multiple recipients. The intended use of this field + involves an author seeking to protect transactional or otherwise + sensitive data intended for a single recipient, and thus generating + independent messages for each individual recipient is normal + practice. See Section 7 for further discussion and restrictions. + +5.2.1. Design Choices + + The presence of the address in the field content supports the case + where a message bearing this header field is forwarded. The specific + use case is as follows: + + 1. A user subscribes to a service "S" at date-time "D" and confirms + an email address at the user's current location, "A"; + + 2. At some later date, the user intends to leave the current + location and thus creates a new mailbox elsewhere, at "B"; + + 3. The user configures address "A" to forward to "B"; + + 4. "S" constructs a message to "A" claiming that the address was + valid at date-time "D" and sends it to "A"; + + 5. The receiving MTA for "A" determines that the forwarding in + effect was created by the same party that owned the mailbox there + and thus concludes that the continuous ownership test has been + satisfied; + + 6. If possible, the MTA for "A" removes this header field from the + message, and in either case, forwards it to "B"; and + + 7. On receipt at "B", either the header field has been removed or + the header field does not refer to a current envelope recipient, + and in either case the MTA delivers the message. + + Section 8 discusses some interesting use cases, such as the case + where "B" above results in further forwarding of the message. + + SMTP has never required any correspondence between addresses in the + RFC5321.MailFrom and RFC5321.RcptTo parameters and header fields of a + message, which is why the header field defined here contains the + recipient address to which the timestamp applies. + + + + + +Mills & Kucherawy Standards Track [Page 10] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + +5.3. Clock Synchronization + + The timestamp portion of this specification supports a precision at + the seconds level. Although uncommon, it is not impossible for a + clock at either a generator or a receiver to be incorrect, leading to + an incorrect result in the RRVS evaluation. + + To minimize the risk of such incorrect results, both generators and + receivers implementing this specification MUST use a standard clock + synchronization protocol such as [NTP] to synchronize to a common + clock. + +6. Relaying without RRVS Support + + When a message is received using the SMTP extension defined here but + will not be delivered locally (that is, it needs to be relayed + further), the MTA to which the relay will take place might not be + compliant with this specification. Where the MTA in possession of + the message observes it is going to relay the message to an MTA that + does not advertise this extension, it needs to choose one of the + following actions: + + 1. Decline to relay the message further, preferably generating a + Delivery Status Notification [DSN] to indicate failure + (RECOMMENDED); + + 2. Downgrade the data thus provided in the SMTP extension to a + header field, as described in Section 6.1 below (SHOULD NOT + unless the conditions in that section are satisfied, and only + when the previous option is not available); or + + 3. Silently continue with delivery, dropping the protection offered + by this protocol. + + Using options other than the first option needs to be avoided unless + there is specific knowledge that further relaying with the degraded + protections thus provided does not introduce undue risk. + +6.1. Header Field Conversion + + If an SMTP server ("B") receives a message bearing one or more + "Require-Recipient-Valid-Since" header fields from a client ("A"), + presumably because "A" does not support the SMTP extension, and needs + to relay the corresponding message on to another server ("C") + (thereby becoming a client), and "C" advertises support for the SMTP + extension, "B" SHOULD delete the header field(s) and instead relay + this information by making use of the SMTP extension. Note that such + modification of the header might affect later validation of the + + + +Mills & Kucherawy Standards Track [Page 11] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + header upon delivery; for example, a hash of the modified header + would produce a different result. This might be a valid cause for + some operators to skip this delete operation. + + Conversely, if "B" has received a mailbox timestamp from "A" using + the SMTP extension for which it must now relay the message on to "C", + but "C" does not advertise the SMTP extension, and "B" does not + reject the message because rejection was specifically declined by the + client (see Section 5.1.1), "B" SHOULD add a Require-Recipient-Valid- + Since header field matching the mailbox to which relaying is being + done, and the corresponding valid-since timestamp for it, if it has + prior information that the eventual MDA or another intermediate MTA + supports this mechanism and will be able to process the header field + as described in this specification. + + The admonitions about very cautious use of the header field described + in Section 4 apply to this relaying mechanism as well. If multiple + mailbox timestamps are received from "A", the admonitions in + Section 7 also apply. + +7. Header Field with Multiple Recipients + + Numerous issues arise when using the header field form of this + extension, particularly when multiple recipients are specified for a + single message resulting in multiple fields each with a distinct + address and timestamp. + + Because of the nature of SMTP, a message bearing a multiplicity of + Require-Recipient-Valid-Since header fields could result in a single + delivery attempt for multiple recipients (in particular, if two of + the recipients are handled by the same server), and if any one of + them fails the test, the delivery fails to all of them; it then + becomes necessary to do one of the following: + + o reject the message on completion of the DATA phase of the SMTP + session, which is a rejection of delivery to all recipients, or + + o accept the message on completion of DATA, and then generate a + Delivery Status Notification [DSN] message for each of the failed + recipients. + + Additional complexity arises when a message is sent to two + recipients, "A" and "B", presumably with different timestamps, both + of which are then redirected to a common address "C". The author is + not necessarily aware of the current or past ownership of mailbox + "C", or indeed that "A" and/or "B" have been redirected. This might + + + + + +Mills & Kucherawy Standards Track [Page 12] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + result in either or both of the two deliveries failing at "C", which + is likely to confuse the message author, who (as far as the author is + aware) never sent a message to "C" in the first place. + + Finally, there is an obvious concern with the fan-out of a message + bearing the timestamps of multiple users; tight control over the + handling of the timestamp information is very difficult to assure as + the number of handling agents increases. + +8. Special Use Addresses + + In [DSN-SMTP], an SMTP extension was defined to allow SMTP clients to + request generation of DSNs and related information to allow such + reports to be maximally useful. Section 5.2.7 of that document + explored the issue of the use of that extension where the recipient + is a mailing list. This extension has similar concerns, which are + covered here following that document as a model. + + For all cases described below, a receiving MTA SHOULD NOT introduce + RRVS in either form (SMTP extension or header field) if the message + did not arrive with RRVS in use. This would amount to second + guessing the message originator's intention and might lead to an + undesirable outcome. + +8.1. Mailing Lists + + Delivery to a mailing list service is considered a final delivery. + Where this protocol is in use, it is evaluated as per any normal + delivery: if the same mailing list has been operating in place of the + specified recipient mailbox since at least the timestamp given as the + RRVS parameter, the message is delivered to the list service + normally, and is otherwise not delivered. + + It is important, however, that the participating MDA passing the + message to the list service needs to omit the RRVS parameter in + either form (SMTP extension or header field) when doing so. The + emission of a message from the list service to its subscribers + constitutes a new message not covered by the previous transaction. + +8.2. Single-Recipient Aliases + + Upon delivery of an RRVS-protected message to an alias (acting in + place of a mailbox) that results in relaying of the message to a + single other destination, the usual RRVS check is performed. The + continuous ownership test here might succeed if, for example, a + conventional user inbox was replaced with an alias on behalf of that + same user, and the time when this was done is recorded in a way that + can be queried by the relaying MTA. + + + +Mills & Kucherawy Standards Track [Page 13] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + If the relaying system also performs some kind of step where + ownership of the new destination address is confirmed, it SHOULD + apply RRVS using the later of that timestamp and the one that was + used inbound. This also allows for changes to the alias without + disrupting the protection offered by RRVS. + + If the relaying system has no such time records related to the new + destination address, the RRVS SMTP extension is not used on the + relaying SMTP session, and the header field relative to the local + alias is removed, in accordance with Section 5. + +8.3. Multiple-Recipient Aliases + + Upon delivery of an RRVS-protected message to an alias (acting in + place of a mailbox) that results in relaying of the message to + multiple other destinations, the usual RRVS check is performed as in + Section 8.2. The MTA expanding such an alias then decides which of + the options enumerated in that section is to be applied for each new + recipient. + +8.4. Confidential Forwarding Addresses + + In the above cases, the original author could receive message + rejections, such as DSNs, from the ultimate destination, where the + RRVS check (or indeed, any other) fails and rejection is warranted. + This can reveal the existence of a forwarding relationship between + the original intended recipient and the actual final recipient. + + Where this is a concern, the initial delivery attempt is to be + treated like a mailing list delivery, with RRVS evaluation done and + then all RRVS information removed from the message prior to relaying + it to its true destination. + +8.5. Suggested Mailing List Enhancements + + Mailing list services could store the timestamp at which a subscriber + was added to a mailing list. This specification could then be used + in conjunction with that information in order to restrict list + traffic to the original subscriber, rather than a different person + now in possession of an address under which the original subscriber + was added to the list. Upon receiving a rejection caused by this + specification, the list service can remove that address from further + distribution. + + A mailing list service that receives a message containing the header + field defined here needs to remove it from the message prior to + redistributing it, limiting exposure of information regarding the + relationship between the message's author and the mailing list. + + + +Mills & Kucherawy Standards Track [Page 14] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + +9. Continuous Ownership + + For the purposes of this specification, an address is defined as + having been under continuous ownership since a given date-time if a + message sent to the address at any point since the given date-time + would not go to anyone except the owner at that given date-time. + That is, while an address may have been suspended or otherwise + disabled for some period, any mail actually delivered would have been + delivered exclusively to the same owner. It is presumed that some + sort of relationship exists between the message sender and the + intended recipient. Presumably, there has been some confirmation + process applied to establish this ownership of the receiver's + mailbox; however, the method of making such determinations is a local + matter and outside the scope of this document. + + Evaluating the notion of continuous ownership is accomplished by + doing any query that establishes whether the above condition holds + for a given mailbox. + + Determining continuous ownership of a mailbox is a local matter at + the receiving site. The only possible answers to the continuous- + ownership-since question are "yes", "no", and "unknown"; the action + to be taken in the "unknown" case is a matter of local policy. + + For example, when control of a domain name is transferred, the new + domain owner might be unable to determine whether the owner of the + subject address has been under continuous ownership since the stated + date-time if the mailbox history is not also transferred (or was not + previously maintained). It will also be "unknown" if whatever + database contains mailbox ownership data is temporarily unavailable + at the time a message arrives for delivery. In this latter case, + typical SMTP temporary failure handling is appropriate. + + To avoid exposing account details unnecessarily, if the address + specified has had one continuous owner since it was created, any + confirmation date-time SHOULD be considered to pass the test, even if + that date-time is earlier than the account creation date and time. + This is further discussed in Section 13. + +10. Digital Signatures + + This protocol mandates removal of the header field (when used) upon + delivery in all but exceptional circumstances. If a message with the + header field were digitally signed in a way that included the header + field, altering a message in this way would invalidate the signature. + However, the header field is strictly for tunneling purposes and + should be regarded by the rest of the transport system as purely + trace information. + + + +Mills & Kucherawy Standards Track [Page 15] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + Accordingly, the header field MUST NOT be included in the content + covered by digital signatures. + +11. Authentication-Results Definitions + + [AUTHRES] defines a mechanism for indicating, via a header field, the + results of message authentication checks. Section 15 registers RRVS + as a new method that can be reported in this way, as well as + corresponding result names. The possible result names and their + meanings are as follows: + + none: The message had no recipient mailbox timestamp associated with + it, either via the SMTP extension or header field method; this + protocol was not in use. + + unknown: At least one form of this protocol was in use, but + continuous ownership of the recipient mailbox could not be + determined. + + temperror: At least one form of this protocol was in use, but some + kind of error occurred during evaluation that was transient in + nature; a later retry will likely produce a final result. + + permerror: At least one form of this protocol was in use, but some + kind of error occurred during evaluation that was not recoverable; + a later retry will not likely produce a final result. + + pass: At least one form of this protocol was in use, and the + destination mailbox was confirmed to have been under continuous + ownership since the timestamp thus provided. + + fail: At least one form of this protocol was in use, and the + destination mailbox was confirmed not to have been under + continuous ownership since the timestamp thus provided. + + Where multiple recipients are present on a message, multiple results + can be reported using the mechanism described in [AUTHRES]. + +12. Examples + + In the following examples, "C:" indicates data sent by an SMTP + client, and "S:" indicates responses by the SMTP server. Message + content is CRLF terminated, though these are omitted here for ease of + reading. + + + + + + + +Mills & Kucherawy Standards Track [Page 16] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + +12.1. SMTP Extension Example + + C: [connection established] + S: 220 server.example.com ESMTP ready + C: EHLO client.example.net + S: 250-server.example.com + S: 250 RRVS + C: MAIL FROM:<sender@example.net> + S: 250 OK + C: RCPT TO:<receiver@example.com> RRVS=2014-04-03T23:01:00Z + S: 550 5.7.17 receiver@example.com is no longer valid + C: QUIT + S: 221 So long! + +12.2. Header Field Example + + C: [connection established] + S: 220 server.example.com ESMTP ready + C: HELO client.example.net + S: 250 server.example.com + C: MAIL FROM:<sender@example.net> + S: 250 OK + C: RCPT TO:<receiver@example.com> + S: 250 OK + C: DATA + S: 354 Ready for message content + C: From: Mister Sender <sender@example.net> + To: Miss Receiver <receiver@example.com> + Subject: Are you still there? + Date: Fri, 28 Jun 2013 18:01:01 +0200 + Require-Recipient-Valid-Since: receiver@example.com; + Sat, 1 Jun 2013 09:23:01 -0700 + + Are you still there? + . + S: 550 5.7.17 receiver@example.com is no longer valid + C: QUIT + S: 221 So long! + +12.3. Authentication-Results Example + + Here is an example use of the Authentication-Results header field + used to yield the results of an RRVS evaluation: + + Authentication-Results: mx.example.com; rrvs=pass + smtp.rcptto=user@example.com + + + + + +Mills & Kucherawy Standards Track [Page 17] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + This indicates that the message arrived addressed to the mailbox + user@example.com, the continuous ownership test was applied with the + provided timestamp, and the check revealed that the test was + satisfied. The timestamp is not revealed. + +13. Security Considerations + +13.1. Abuse Countermeasures + + The response of a server implementing this protocol can disclose + information about the age of an existing email mailbox. + Implementation of countermeasures against probing attacks is + RECOMMENDED. For example, an operator could track appearance of this + field with respect to a particular mailbox and observe the timestamps + being submitted for testing; if it appears that a variety of + timestamps are being tried against a single mailbox in short order, + the field could be ignored and the message silently discarded. This + concern is discussed further in Section 14. + +13.2. Suggested Use Restrictions + + If the mailbox named in the field is known to have had only a single + continuous owner since creation, or not to have existed at all (under + any owner) prior to the date-time specified in the field, then the + field SHOULD be silently ignored and normal message handling applied + so that this information is not disclosed. Such fields are likely + the product of either gross error or an attack. + + A message author using this specification might restrict inclusion of + the header field such that it is only done for recipients known also + to implement this specification, in order to reduce the possibility + of revealing information about the relationship between the author + and the mailbox. + + If ownership of an entire domain is transferred, the new owner may + not know what addresses were assigned in the past by the prior owner. + Hence, no address can be known not to have had a single owner, or to + have existed (or not) at all. In this case, the "unknown" result is + likely appropriate. + +13.3. False Sense of Security + + Senders implementing this protocol likely believe their content is + being protected by doing so. It has to be considered, however, that + receiving systems might not implement this protocol correctly, or at + all. Furthermore, use of RRVS by a sending system constitutes + nothing more than a request to the receiving system; that system + could choose not to prevent delivery for some local policy, for legal + + + +Mills & Kucherawy Standards Track [Page 18] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + or operational reasons, which compromises the security the sending + system believed was a benefit to using RRVS. This could mean the + timestamp information involved in the protocol becomes inadvertently + revealed. + + This concern lends further support to the notion that senders would + do well to avoid using this protocol other than when sending to + known, trusted receivers. + +13.4. Reassignment of Mailboxes + + This specification is a direct response to the risks involved with + reassignment or recycling of email addresses, an inherently dangerous + practice. It is typically expected that email addresses will not + have a high rate of turnover or ownership change. + + It is RECOMMENDED to have a substantial period of time between + mailbox owners during which the mailbox accepts no mail, giving + message generators an opportunity to detect that the previous owner + is no longer at that address. + +14. Privacy Considerations + +14.1. The Tradeoff + + That some MSPs allow for expiration of account names when they have + been unused for a protracted period forces a choice between two + potential types of privacy vulnerabilities, one of which presents + significantly greater threats to users than the other. Automatically + generated mail is often used to convey authentication credentials + that can potentially provide access to extremely sensitive + information. Supplying such credentials to the wrong party after a + mailbox ownership change could allow the previous owner's data to be + exposed without his or her authorization or knowledge. In contrast, + the information that may be exposed to a third party via the proposal + in this document is limited to information about the mailbox history. + Given that MSPs have chosen to allow transfers of mailbox ownership + without the prior owner's involvement, the information leakage from + the extensions specified here creates far lower overall risk than the + potential for delivering mail to the wrong party. + +14.2. Probing Attacks + + As described above, use of this extension or header field in probing + attacks can disclose information about the history of the mailbox. + The harm that can be done by leaking any kind of private information + is difficult to predict, so it is prudent to be sensitive to this + sort of disclosure, either inadvertently or in response to probing by + + + +Mills & Kucherawy Standards Track [Page 19] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + an attacker. It bears restating, then, that implementing + countermeasures against abuse of this capability needs strong + consideration. + +14.3. Envelope Recipients + + The email To and Cc header fields are not required to be populated + with addresses that match the envelope recipient set, and Cc may even + be absent. However, the algorithm in Section 3 requires that this + header field contain a match for an envelope recipient in order to be + actionable. As such, use of this specification can reveal some or + all of the original intended recipient set to any party that can see + the message in transit or upon delivery. + + For a message destined to a single recipient, this is unlikely to be + a concern, which is one of the reasons use of this specification on + multi-recipient messages is discouraged. + +14.4. Risks with Use + + MDAs might not implement the recommendation to remove the header + field defined here when messages are delivered, either out of + ignorance or due to error. Since user agents often do not render all + of the header fields present, the message could be forwarded to + another party that would then inadvertently have the content of this + header field. + + A bad actor may detect use of either form of the RRVS protocol and + interpret it as an indication of high-value content. + +15. IANA Considerations + +15.1. SMTP Extension Registration + + Section 2.2.2 of [SMTP] sets out the procedure for registering a new + SMTP extension. IANA has registered the SMTP extension using the + details provided in Section 3.1 of this document. + +15.2. Header Field Registration + + IANA has added the following entry to the "Permanent Message Header + Field Names" registry, as per the procedure found in [IANA-HEADERS]: + + Header field name: Require-Recipient-Valid-Since + Applicable protocol: mail ([MAIL]) + Status: standard + Author/Change controller: IETF + Specification document(s): RFC 7293 + + + +Mills & Kucherawy Standards Track [Page 20] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + Related information: + Requesting review of any proposed changes and additions to + this field is recommended. + +15.3. Enhanced Status Code Registration + + IANA has registered the following in the Enumerated Status Codes + table of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status + Codes Registry": + + Code: X.7.17 + Sample Text: Mailbox owner has changed + Associated basic status code: 5XX + Description: This status code is returned when a message is + received with a Require-Recipient-Valid-Since + field or RRVS extension and the receiving + system is able to determine that the intended + recipient mailbox has not been under continuous + ownership since the specified date-time. + Reference: RFC 7293 + Submitter: M. Kucherawy + Change controller: IESG + + Code: X.7.18 + Sample Text: Domain owner has changed + Associated basic status code: 5XX + Description: This status code is returned when a message is + received with a Require-Recipient-Valid-Since + field or RRVS extension and the receiving + system wishes to disclose that the owner of + the domain name of the recipient has changed + since the specified date-time. + Reference: RFC 7293 + Submitter: M. Kucherawy + Change controller: IESG + + Code: X.7.19 + Sample Text: RRVS test cannot be completed + Associated basic status code: 5XX + Description: This status code is returned when a message is + received with a Require-Recipient-Valid-Since + field or RRVS extension and the receiving + system cannot complete the requested + evaluation because the required timestamp was + not recorded. The message originator needs to + decide whether to reissue the message without + RRVS protection. + Reference: RFC 7293 + + + +Mills & Kucherawy Standards Track [Page 21] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + Submitter: M. Kucherawy + Change controller: IESG + +15.4. Authentication Results Registration + + IANA has registered the following in the "Email Authentication + Methods" registry: + + Method: rrvs + + Specifying Document: RFC 7293 + + ptype: smtp + + Property: rcptto + + Value: envelope recipient + + Status: active + + Version: 1 + + IANA has also registered the following in the "Email Authentication + Result Names" registry: + + Codes: none, unknown, temperror, permerror, pass, fail + + Defined: RFC 7293 + + Auth Method(s): rrvs + + Meaning: Section 11 of RFC 7293 + + Status: active + +16. Acknowledgments + + Erling Ellingsen proposed the idea. + + Reviews and comments were provided by Michael Adkins, Kurt Andersen, + Eric Burger, Alissa Cooper, Dave Cridland, Dave Crocker, Ned Freed, + John Levine, Alexey Melnikov, Jay Nancarrow, Hector Santos, Gregg + Stefancik, and Ed Zayas. + + + + + + + + +Mills & Kucherawy Standards Track [Page 22] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + +17. References + +17.1. Normative References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [DATETIME] Klyne, G., Ed. and C. Newman, "Date and Time on the + Internet: Timestamps", RFC 3339, July 2002. + + [IANA-HEADERS] + Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, + October 2008. + + [NTP] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network + Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, June 2010. + + [ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and + Functions", RFC 2142, May 1997. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + +17.2. Informative References + + [AUTHRES] Kucherawy, M., "Message Header Field for Indicating + Message Authentication Status", RFC 7001, September 2013. + + [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format + for Delivery Status Notifications", RFC 3464, January + 2003. + + [DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service + Extension for Delivery Status Notifications (DSNs)", RFC + 3461, January 2003. + + [EMAIL-ARCH] + Crocker, D., "Internet Mail Architecture", RFC 5598, July + 2009. + + + + +Mills & Kucherawy Standards Track [Page 23] + +RFC 7293 Require-Recipient-Valid-Since July 2014 + + + [ESC] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC + 3463, January 2003. + +Authors' Addresses + + William J. Mills + Yahoo! Inc. + + EMail: wmills_92105@yahoo.com + + + Murray S. Kucherawy + Facebook, Inc. + 1 Hacker Way + Menlo Park, CA 94025 + USA + + EMail: msk@fb.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mills & Kucherawy Standards Track [Page 24] + |