draft-ietf-appsawg-rrvs-header-field-09.txt   draft-ietf-appsawg-rrvs-header-field-10.txt 
Network Working Group W. Mills Network Working Group W. Mills
Internet-Draft Yahoo! Inc. Internet-Draft Yahoo! Inc.
Intended status: Standards Track M. Kucherawy Intended status: Standards Track M. Kucherawy
Expires: September 26, 2014 Facebook, Inc. Expires: October 18, 2014 Facebook, Inc.
March 25, 2014 April 16, 2014
The Require-Recipient-Valid-Since Header Field and SMTP Service The Require-Recipient-Valid-Since Header Field and SMTP Service
Extension Extension
draft-ietf-appsawg-rrvs-header-field-09 draft-ietf-appsawg-rrvs-header-field-10
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, and a header field called Require-Recipient- Protocol called RRVS, to provide a method for senders to indicate to
Valid-Since, to provide a method for senders to indicate to receivers receivers a point in time when the the ownership of the target
a point in time when the the ownership of the target mailbox was mailbox was known to the sender. This can be used to detect changes
known to the sender. This can be used to detect changes of mailbox of mailbox ownership, and thus prevent mail from being delivered to
ownership, and thus prevent mail from being delivered to the wrong the wrong party. This document also defines a header field called
party. 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 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 43 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 26, 2014. This Internet-Draft will expire on October 18, 2014.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Reassignment of Mailboxes . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 7 5.1. SMTP Extension Used . . . . . . . . . . . . . . . . . . . 8
5.1.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Header Field Used . . . . . . . . . . . . . . . . . . . . 8 5.2. Header Field Used . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Design Choices . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Design Choices . . . . . . . . . . . . . . . . . . . . 10
5.3. Clock Synchronization . . . . . . . . . . . . . . . . . . 10 5.3. Clock Synchronization . . . . . . . . . . . . . . . . . . 11
6. Role Accounts . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 11
7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 10 6.1. Header Field Conversion . . . . . . . . . . . . . . . . . 12
7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 11 7. Header Field with Multiple Recipients . . . . . . . . . . . . 13
8. Header Field with Multiple Recipients . . . . . . . . . . . . 11 8. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 13
9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 12 8.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Single-Recipient Aliases . . . . . . . . . . . . . . . . . 14
9.2. Single-Recipient Aliases . . . . . . . . . . . . . . . . . 12 8.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 14
9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 13 8.4. Confidential Forwarding Addresses . . . . . . . . . . . . 15
9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 13 8.5. Suggested Mailing List Enhancements . . . . . . . . . . . 15
9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 13 9. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 15
10. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 14 10. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 16
11. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 14 11. Authentication-Results Definitions . . . . . . . . . . . . . . 16
12. Authentication-Results Definitions . . . . . . . . . . . . . . 15 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 17
13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 16 12.2. Header Field Example . . . . . . . . . . . . . . . . . . . 18
13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 16 12.3. Authentication-Results Example . . . . . . . . . . . . . . 18
13.3. Authentication-Results Example . . . . . . . . . . . . . . 17 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18
14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 18
14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 17 13.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 19
14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 17 13.3. False Sense of Security . . . . . . . . . . . . . . . . . 19
14.3. False Sense of Security . . . . . . . . . . . . . . . . . 18 13.4. Reassignment of Mailboxes . . . . . . . . . . . . . . . . 19
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 20
15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 18 14.1. The Trade-Off . . . . . . . . . . . . . . . . . . . . . . 20
15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 19 14.2. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 20
15.3. Risks with Use . . . . . . . . . . . . . . . . . . . . . . 19 14.3. Envelope Recipients . . . . . . . . . . . . . . . . . . . 20
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14.4. Risks with Use . . . . . . . . . . . . . . . . . . . . . . 21
16.1. SMTP Extension Registration . . . . . . . . . . . . . . . 19 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
16.2. Header Field Registration . . . . . . . . . . . . . . . . 19 15.1. SMTP Extension Registration . . . . . . . . . . . . . . . 21
16.3. Enhanced Status Code Registration . . . . . . . . . . . . 20 15.2. Header Field Registration . . . . . . . . . . . . . . . . 21
16.4. Authentication Results Registration . . . . . . . . . . . 20 15.3. Enhanced Status Code Registration . . . . . . . . . . . . 21
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 15.4. Authentication Results Registration . . . . . . . . . . . 22
17.1. Normative References . . . . . . . . . . . . . . . . . . . 21 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
17.2. Informative References . . . . . . . . . . . . . . . . . . 22 16.1. Normative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 16.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 24
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
skipping to change at page 4, line 32 skipping to change at page 4, line 32
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 choose to prevent delivery and, possibly, receiving system can then prevent delivery and, preferably, notify
to 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.
One important point is that the protocols presented here provide a Because the use cases for this extension are strongly tied to privacy
way for a sending system to make a request to receiving systems with issues, attention to the Security Considerations (Section 13) and the
respect to handling of a message. In the end, there is no guarantee Privacy Considerations (Section 14), is particularly important.
that the request will have the desired effect. Note, especially, the limitation described in Section 13.3.
1.1. Reassignment of Mailboxes
It is expected that email addresses will not have a high rate of
turnover or ownership change. High-precision timestamps are used out
of convenience and convention rather than out of necessity.
It is also good practice to have a substantial period of time between
mailbox owners during which the mailbox accepts no mail.
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 10) message to have been under continuous ownership (see Section 9) since
since a specified point time. That specified time would be the time a specified point time. That specified time would be the time when
when the intended recipient gave the address to the message author, the intended recipient gave the address to the message author, or
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. The header field does support at each handling step for a message, and the option to demand
not provide the strong assurance, but only requires adoption by the support at all nodes in the handling path of the message (and
receiving Message Delivery Agent (MDA). 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).
The SMTP extension is called "RRVS" (Require Recipient Valid Since), The SMTP extension is called "RRVS" (Require Recipient Valid Since),
and adds a parameter to the SMTP "RCPT" command that indicates the and adds a parameter to the SMTP "RCPT" command that indicates the
most recent point in time when the message author believed the most recent point in time when the message author believed the
destination mailbox to be under the continuous ownership of a destination mailbox to be under the continuous ownership of a
specific party. Similarly, the Require-Recipient-Valid-Since header specific party. Similarly, the Require-Recipient-Valid-Since header
field includes an intended recipient coupled with a timestamp field includes an intended recipient 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 a 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 new parameter is "RRVS", which takes a value this new parameter. The parameter is "RRVS", and the value is a
that is a timestamp expressed as a "date-time" as defined in timestamp expressed as a "date-time" as defined in [DATETIME], with
[DATETIME], with the added restriction that a "time-secfrac" MUST NOT the added restriction that a "time-secfrac" MUST NOT be used. The
be used. Accordingly, this extension increases the maximum command timestamp MAY optionally be followed by a semi-colon character and a
length for the RCPT command by 31 characters. 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 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:
skipping to change at page 6, line 47 skipping to change at page 7, line 5
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 either the SMTP extension or the header field defined then applies the SMTP extension when sending the message to its
above when sending the message to its destination. destination.
Use of the SMTP extension provided here is preferable over the header In cases where the outgoing MTA does not support the extension, the
field method because of: 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; 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 fact that the protocol is focused on affecting delivery (that 2. The protocol is focused on affecting delivery (that is, the
is, the transaction) rather than on content; and transaction) rather than on content, and therefore use of a
header field in the content is generally inappropriate;
3. the fact that there is less risk of the timestamp parameter being 3. The mechanism cannot be used with multiple recipients without
inadvertently forwarded (see Section 15.3). unintentionally exposing information about one recipient to the
others (see Section 7; and
The header field mechanism is defined only to enable passage of the 4. There is a risk of the timestamp parameter being inadvertently
request between and through systems that do not implement the SMTP forwarded, automatically or intentionally by the user (since user
extension. agents might not reveal the presence of the header field), and
therefore exposed to unintended recipients. (See Section 14.4.)
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 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 implements the extension, and so there was an 1. The sending client uses the extension, and so there was an RRVS
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 (or elected not to) implement the 2. The sending client does not use the extension, so the RRVS
extension, so the RRVS parameter was not present on the RCPT TO parameter was not present on the RCPT TO commands in the SMTP
commands in the SMTP session, but the corresponding header field session, but the corresponding header field might be present in
might be present in the message. 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/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 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 And
Functions [ROLES]. (See Section 6.) 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 16.3.) RCPT command. (See also Section 15.3.)
3. If any Require-Recipient-Valid-Since header fields are present
and refer to the named address, they SHOULD be removed prior to
delivery or relaying. (See Section 5.2 and Section 7.1 for
discussion.)
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
relay the RRVS extension parameter to the next MTA or MDA so that it relay the RRVS extension parameter to the next MTA or MDA so that it
can be processed there. can be processed there.
See Section 9.2 for additional discussion. 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 [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.
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:
* are syntactically invalid; * are syntactically invalid;
* name a role account as listed in [ROLES];
* name a role account as listed in [ROLES] (see Section 6);
* the "addr-spec" portion does not match a current recipient, as * the "addr-spec" portion does not match a current recipient, as
listed in the RCPT TO commands in the SMTP session; or listed in the RCPT TO commands in the SMTP session; or
* the "addr-spec" portion does not refer to a mailbox handled * the "addr-spec" portion does not refer to a mailbox handled
for local delivery by this ADMD. for local delivery by this ADMD.
3. For each field remaining, determine if the named address has been 3. For each field remaining, determine if the named address has been
under continuous ownership since the corresponding timestamp. If under continuous ownership since the corresponding timestamp. If
it has not, reject the message. it has not, reject the message.
skipping to change at page 9, line 12 skipping to change at page 10, line 28
message is being forwarded, remove those instances of this header message is being forwarded, remove those instances of this header
field that were not discarded by step 2 above. field that were not discarded by step 2 above.
Handling proceeds normally upon completion of the above steps if Handling proceeds normally upon completion of the above steps if
rejection has not been performed. rejection has not been performed.
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 11 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 16.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 8 for further discussion. practice. See Section 7 for further discussion and restrictions.
5.2.1. Design Choices 5.2.1. Design Choices
The presence of the intended address in the field content supports The presence of the address in the field content supports the case
the case where a message bearing this header field is forwarded. The where a message bearing this header field is forwarded. The specific
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" on date "D" and confirms an
email address at the user's current location, "A"; 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 replaces address "A" with forwarding 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 address was valid
at date "D" and sends it to "A"; at date "D" and sends it to "A";
5. The receiving MTA at "A" determines that the forwarding in effect 5. The receiving MTA for "A" determines that the forwarding in
was created by the same party that owned the mailbox there, and effect was created by the same party that owned the mailbox
thus concludes the continuous ownership test has been satisfied; there, and thus concludes the continuous ownership test has been
satisfied;
6. If possible, "A" removes this header field from the message, and 6. If possible, the MTA for "A" removes this header field from the
in either case, forwards it to "B"; message, and in either case, forwards it to "B";
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 delivers the message.
Section 9 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
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. Role Accounts 6. Relaying Without RRVS Support
It is necessary not to interfere with delivery of messages to role
mailboxes (see [ROLES]), but it could be useful to notify users
sending to those mailboxes that a change of ownership might have
taken place, if such notification is possible.
7. 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
Delivery Status Notification [DSN] to indicate failure Delivery Status Notification [DSN] to indicate failure
(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 7.1 below (RECOMMENDED when header field, as described in Section 6.1 below (SHOULD NOT
the previous option is not available); or 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 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 other than the first option needs to be avoided unless there is
specific knowledge that further relaying with the degraded specific knowledge that further relaying with the degraded
protections thus provided does not introduce undue risk. protections thus provided does not introduce undue risk.
7.1. Header Field Conversion 6.1. Header Field Conversion
If an SMTP server ("B") that has received mailbox timestamps from a If an SMTP server ("B") receives a message bearing one or more
client ("A") using this extension but then needs to relay the Require-Recipient-Valid-Since 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 corresponding message on to another server ("C") (thereby becoming a
client), but "C" does not advertise the SMTP extension and "B" elects client), and "C" advertises support for the SMTP extension, "B"
not to reject the message, "B" SHOULD add Require-Recipient-Valid- SHOULD delete the header field(s) and instead relay this information
Since header fields matching each mailbox to which relaying is being by making use of the SMTP extension. Note that such modification of
done, and the corresponding valid-since timestamp for each. the header might affect later validation of the 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.
Similarly, if "B" receives a message bearing one or more Require- Conversely, if "B" has received a mailbox timestamp from "A" using
Recipient-Valid-Since header fields from "A" for which it must now the SMTP extension for which it must now relay the message on to "C",
relay the message, and "C" advertises support for the SMTP extension, but "C" does not advertise the SMTP extension, and "B" does not
"B" SHOULD delete the header field(s) and instead relay this reject the message because rejection was specifically declined by the
information by making use of the SMTP extension. Note that such client (see Section 5.1.1), "B" SHOULD add a Require-Recipient-Valid-
modification of the header might affect later validation of the Since header field matching the mailbox to which relaying is being
header upon delivery; for example, a hash of the header would produce done, and the corresponding valid-since timestamp for it, if it has
a different result. This might be a valid cause for some operators prior information that the eventual MDA or another intermediate MTA
to skip this delete operation. supports this mechanism and will be able to process the header field
as described in this specification.
8. Header Field with Multiple Recipients 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 Numerous issues arise when using the header field form of this
extension, particularly when multiple recipients are specified for a extension, particularly when multiple recipients are specified for a
single message resulting in multiple fields each with a distinct single message resulting in multiple fields each with a distinct
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
result in either or both of the two deliveries failing at "C", which 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 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. aware) never sent a message to "C" in the first place.
9. Special Use Addresses 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 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 of the message originator's intention and might lead to an
undesirable outcome. undesirable outcome.
9.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.
9.2. Single-Recipient Aliases 8.2. Single-Recipient Aliases
Upon delivery of an RRVS-protected message to an alias (acting in 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 place of a mailbox) that results in relaying of the message to a
single other destination, the usual RRVS check is performed. The single other destination, the usual RRVS check is performed. The
continuous ownership test here might succeed if, for example, a continuous ownership test here might succeed if, for example, a
conventional user inbox was replaced with an alias on behalf of that 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 same user, and the time when this was done is recorded in a way that
can be queried by the relaying MTA. can be queried by the relaying MTA.
If the relaying system also performs some kind of step where If the relaying system also performs some kind of step where
ownership of the new destination address is confirmed, it SHOULD ownership of the new destination address is confirmed, it SHOULD
apply RRVS using the later of that timestamp and the one that was apply RRVS using the later of that timestamp and the one that was
used inbound. This also allows for changes to the alias without used inbound. This also allows for changes to the alias without
disrupting the protection offered by RRVS. disrupting the protection offered by RRVS.
If the relaying system has no such time records related to the new If the relaying system has no such time records related to the new
destination address, the RRVS SMTP extension is not used on the destination address, the RRVS SMTP extension is not used on the
relaying SMTP session, and the header field relative to the local relaying SMTP session, and the header field relative to the local
alias is removed, in accordance with Section 5. alias is removed, in accordance with Section 5.
9.3. Multiple-Recipient Aliases 8.3. Multiple-Recipient Aliases
Upon delivery of an RRVS-protected message to an alias (acting in Upon delivery of an RRVS-protected message to an alias (acting in
place of a mailbox) that results in relaying of the message to place of a mailbox) that results in relaying of the message to
multiple other destinations, the usual RRVS check is performed as in multiple other destinations, the usual RRVS check is performed as in
Section 9.2. The MTA expanding such an alias then decides which of 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 the options enumerated in that section is to be applied for each new
recipient. recipient.
9.4. Confidential Forwarding Addresses 8.4. Confidential Forwarding Addresses
In the above cases, the original author could receive message In the above cases, the original author could receive message
rejections, such as DSNs, from the ultimate destination, where the rejections, such as DSNs, from the ultimate destination, where the
RRVS check (or indeed, any other) fails and rejection is warranted. RRVS check (or indeed, any other) fails and rejection is warranted.
This can reveal the existence of a forwarding relationship between This can reveal the existence of a forwarding relationship between
the original intended recipient and the actual final recipient. the original intended recipient and the actual final recipient.
Where this is a concern, the initial delivery attempt is to be Where this is a concern, the initial delivery attempt is to be
treated like a mailing list delivery, with RRVS evaluation done and treated like a mailing list delivery, with RRVS evaluation done and
then all RRVS information removed from the message prior to relaying then all RRVS information removed from the message prior to relaying
it to its true destination. it to its true destination.
9.5. Suggested Mailing List Enhancements 8.5. Suggested Mailing List Enhancements
Mailing list services could store the timestamp at which a subscriber Mailing list services could store the timestamp at which a subscriber
was added to a mailing list. This specification could then be used was added to a mailing list. This specification could then be used
in conjunction with that information in order to restrict list in conjunction with that information in order to restrict list
traffic to the original subscriber, rather than a different person traffic to the original subscriber, rather than a different person
now in possession of an address under which the original subscriber now in possession of an address under which the original subscriber
was added to the list. Upon receiving a rejection caused by this was added to the list. Upon receiving a rejection caused by this
specification, the list service can remove that address from further specification, the list service can remove that address from further
distribution. distribution.
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.
10. 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 would
not go to anyone except the owner at that given date-time. That is, 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 while an address may have been suspended or otherwise disabled for
some period, any mail actually delivered would have been delivered some period, any mail actually delivered would have been delivered
exclusively to the same owner. It is presumed that some sort of exclusively to the same owner. It is presumed that some sort of
relationship exists between the message sender and the intended relationship exists between the message sender and the intended
recipient. Presumably there has been some confirmation process recipient. Presumably there has been some confirmation process
skipping to change at page 14, line 42 skipping to change at page 16, line 24
date if the mailbox history is not also transferred (or was not date 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 SHOULD be considered to pass the test, even if that
date is earlier than the account creation date. This is further date is earlier than the account creation date. This is further
discussed in Section 14. discussed in Section 13.
11. 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. Altering a message in delivery in all but exceptional circumstances. If a message with the
this way will invalidate a digital signature intended to guard header field were digitally signed in a way that included the header
against message modification in transit, which can interfere with field, altering a message in this way would invalidate the signature.
delivery. However, the header field is strictly for tunneling purposes and
should be regarded by the rest of the transport system as purely
Section 5.4.1 of DomainKeys Identified Mail [DKIM] proposes a trace information.
strategy for selecting header fields to sign. Specifically, it
advises including in the signed portion of the message only those
header fields that comprise part of the core content of the message.
As the header field version of this protocol is ephemeral, it cannot
be considered core content.
Accordingly, applying digital signatures that attempt to protect the Accordingly, the header field MUST NOT be included in the content
content of this header field is NOT RECOMMENDED. covered by digital signatures.
12. 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 16 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, and corresponding
result names. The possible result names and their meanings are as result names. The possible result names and their meanings are as
follows: 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
skipping to change at page 15, line 48 skipping to change at page 17, line 28
destination mailbox was confirmed to have been under continuous destination mailbox was confirmed to have been under continuous
ownership since the timestamp thus provided. ownership since the timestamp thus provided.
fail: At least one form of this protocol was in use, and the fail: At least one form of this protocol was in use, and the
destination mailbox was confirmed not to have been under destination mailbox was confirmed not to have been under
continuous ownership since the timestamp thus provided. continuous ownership since the timestamp thus provided.
Where multiple recipients are present on a message, multiple results Where multiple recipients are present on a message, multiple results
can be reported using the mechanism described in [AUTHRES]. can be reported using the mechanism described in [AUTHRES].
13. Examples 12. Examples
In the following examples, "C:" indicates data sent by an SMTP In the following examples, "C:" indicates data sent by an SMTP
client, and "S:" indicates responses by the SMTP server. Message client, and "S:" indicates responses by the SMTP server. Message
content is CRLF terminated, though these are omitted here for ease of content is CRLF terminated, though these are omitted here for ease of
reading. reading.
13.1. SMTP Extension Example 12.1. SMTP Extension Example
C: [connection established] C: [connection established]
S: 220 server.example.com ESMTP ready S: 220 server.example.com ESMTP ready
C: EHLO client.example.net C: EHLO client.example.net
S: 250-server.example.com S: 250-server.example.com
S: 250 RRVS S: 250 RRVS
C: MAIL FROM:<sender@example.net> C: MAIL FROM:<sender@example.net>
S: 250 OK S: 250 OK
C: RCPT TO:<receiver@example.com> RRVS=2014-04-03T23:01:00Z C: RCPT TO:<receiver@example.com> RRVS=2014-04-03T23:01:00Z
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!
13.2. Header Field Example 12.2. Header Field Example
C: [connection established] C: [connection established]
S: 220 server.example.com ESMTP ready S: 220 server.example.com ESMTP ready
C: HELO client.example.net C: HELO client.example.net
S: 250 server.example.com S: 250 server.example.com
C: MAIL FROM:<sender@example.net> C: MAIL FROM:<sender@example.net>
S: 250 OK S: 250 OK
C: RCPT TO:<receiver@example.com> C: RCPT TO:<receiver@example.com>
S: 250 OK S: 250 OK
C: DATA C: DATA
skipping to change at page 17, line 5 skipping to change at page 18, line 30
Date: Fri, 28 Jun 2013 18:01:01 +0200 Date: Fri, 28 Jun 2013 18:01:01 +0200
Require-Recipient-Valid-Since: receiver@example.com; Require-Recipient-Valid-Since: receiver@example.com;
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!
13.3. Authentication-Results Example 12.3. Authentication-Results Example
An example use of the Authentication-Results header field used to An example use of the Authentication-Results header field used to
yield the results of an RRVS evaluation: 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 test was satisfied.
The timestamp is not revealed. The timestamp is not revealed.
14. Security Considerations 13. Security Considerations
14.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 a variety of timestamps is
being tried against a single mailbox in short order, the field could being tried against a single mailbox in short order, the field could
be ignored and the message silently discarded. This concern is be ignored and the message silently discarded. This concern is
discussed further in Section 15. discussed further in Section 14.
14.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 specified in the field, then the field
SHOULD be silently ignored and normal message handling applied so SHOULD be silently ignored and normal message handling applied so
that this information is not disclosed. Such fields are likely the that this information is not disclosed. Such fields are likely the
product of either gross error or an attack. 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.
14.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, legal or
operational reason, which compromises the security the sending system operational reason, which compromises the security the sending system
believed was a benefit to using RRVS. This could mean the timestamp believed was a benefit to using RRVS. This could mean the timestamp
information involved in the protocol becomes inadvertently revealed. 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.
15. Privacy Considerations 13.4. Reassignment of Mailboxes
15.1. Probing Attacks 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.
As described above, use of this extension or header field in probing It is RECOMMENDED to have a substantial period of time between
attacks can disclose information about the history of the mailbox. mailbox owners during which the mailbox accepts no mail, giving
The harm that can be done by leaking any kind of private information message generators an opportunity to detect that the previous owner
is difficult to predict, so it is prudent to be sensitive to this is no longer at that address.
sort of disclosure, either inadvertently or in response to probing by
an attacker. It bears restating, then, that implementing 14. Privacy Considerations
countermeasures to abuse of this capability needs strong
consideration. 14.1. The Trade-Off
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,
the information that may be exposed to a third party via the proposal the information that may be exposed to a third party via the proposal
in this document is limited to information about the mailbox history. in this document is limited to information about the mailbox history.
Given that MSPs have chosen to allow transfers of mailbox ownership Given that MSPs have chosen to allow transfers of mailbox ownership
without the prior owner's involvement, the information leakage from without the prior owner's involvement, the information leakage from
the extensions specified here creates far lower overall risk than the the extensions specified here creates far lower overall risk than the
potential for delivering mail to the wrong party. potential for delivering mail to the wrong party.
15.2. Envelope Recipients 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
an attacker. It bears restating, then, that implementing
countermeasures to abuse of this capability needs strong
consideration.
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
the message in transit or upon delivery. the message in transit or upon delivery.
For a message destined to a single recipient, this is unlikely to be 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 a concern, which is one of the reasons use of this specification on
multi-recipient messages is discouraged. multi-recipient messages is discouraged.
15.3. 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.
16. IANA Considerations 15. IANA Considerations
16.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 [MAIL] sets out the procedure for registering a new
SMTP extension. IANA is requested to register the SMTP extension SMTP extension. IANA is requested to register the SMTP extension
using the details provided in Section 3.1 of this document. using the details provided in Section 3.1 of this document.
16.2. Header Field Registration 15.2. Header Field Registration
IANA is requested to add the following entry to the Permanent Message IANA is requested to add the following entry to the Permanent Message
Header Field Names registry, as per the procedure found in Header 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): [this document]
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.
16.3. Enhanced Status Code Registration 15.3. Enhanced Status Code Registration
IANA is requested to register the following in the Enumerated Status IANA is requested to register the following in the Enumerated Status
Codes table of the Simple Mail Transfer Protocol (SMTP) Enhanced Codes table of the Simple Mail Transfer Protocol (SMTP) Enhanced
Status Codes Registry: Status 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: 5 Associated basic status code: 5
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
skipping to change at page 20, line 37 skipping to change at page 22, line 31
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.
Reference: [this document] Reference: [this document]
Submitter: M. Kucherawy Submitter: M. Kucherawy
Change controller: IESG Change controller: IESG
16.4. Authentication Results Registration Code: X.7.19
Sample Text: RRVS test cannot be completed
Associated basic status code: 5
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: [this document]
Submitter: M. Kucherawy
Change controller: IESG
15.4. Authentication Results Registration
IANA is requested to register the following in the "Email IANA is requested to register the following in the "Email
Authentication Methods" Registry: Authentication Methods" Registry:
Method: rrvs Method: rrvs
Specifying Document: [this document] Specifying Document: [this document]
ptype: smtp ptype: smtp
skipping to change at page 21, line 19 skipping to change at page 23, line 28
IANA is also requested to register the following in the "Email IANA is also requested to register the following in the "Email
Authentication Result Names" Registry: Authentication Result Names" Registry:
Codes: none, unknown, temperror, permerror, pass, fail Codes: none, unknown, temperror, permerror, pass, fail
Defined: [this document] Defined: [this document]
Auth Method(s): rrvs Auth Method(s): rrvs
Meaning: Section 12 of [this document] Meaning: Section 11 of [this document]
Status: active Status: active
17. References 16. References
17.1. Normative References 16.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 5234, January 2008. Syntax Specifications: ABNF", RFC 5234, January 2008.
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the [DATETIME] Klyne, G. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul,
"Registration Procedures for Message Header Fields", "Registration Procedures for Message Header Fields",
BCP 90, RFC 3864, September 2004. BCP 90, RFC 3864, September 2004.
skipping to change at page 21, line 44 skipping to change at page 24, line 4
"Registration Procedures for Message Header Fields", "Registration Procedures for Message Header Fields",
BCP 90, RFC 3864, September 2004. BCP 90, RFC 3864, September 2004.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322, [MAIL] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. [NTP] Mills, D., Martin, J., Ed., Burbank, J., and W.
Kasch, "Network Time Protocol Version 4: Protocol and Kasch, "Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010. Algorithms Specification", RFC 5905, June 2010.
[ROLES] Crocker, D., "Mailbox Names For Common Services, [ROLES] Crocker, D., "Mailbox Names For Common Services,
Roles And Functions", RFC 2142, May 1997. Roles And Functions", RFC 2142, May 1997.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
RFC 5321, October 2008. RFC 5321, October 2008.
17.2. Informative References 16.2. Informative References
[AUTHRES] Kucherawy, M., "Message Header Field for Indicating [AUTHRES] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7001, Message Authentication Status", RFC 7001,
September 2013. September 2013.
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy,
Ed., "DomainKeys Identified Mail (DKIM) Signatures",
RFC 6376, September 2011.
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464, Format for Delivery Status Notifications", RFC 3464,
January 2003. January 2003.
[DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) [DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003. (DSNs)", RFC 3461, January 2003.
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. July 2009.
 End of changes. 78 change blocks. 
207 lines changed or deleted 296 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/