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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/