draft-ietf-appsawg-rrvs-header-field-06.txt   draft-ietf-appsawg-rrvs-header-field-07.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: July 14, 2014 Facebook, Inc. Expires: September 3, 2014 Facebook, Inc.
January 10, 2014 March 2, 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-06 draft-ietf-appsawg-rrvs-header-field-07
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, and a header field called Require-Recipient-
Valid-Since, to provide a method for senders to indicate to receivers Valid-Since, to provide a method for senders to indicate to receivers
the time when the sender last confirmed the ownership of the target the point in time when the sender last confirmed the ownership of the
mailbox. This can be used to detect changes of mailbox ownership, target mailbox. This can be used to detect changes of mailbox
and thus prevent mail from being delivered to the wrong party. ownership, and thus prevent mail from being delivered to the wrong
party.
The intended use of these facilities is on automatically generated The intended use of these facilities is on automatically generated
messages that might contain sensitive information, though it may also messages that might contain sensitive information, though it may also
be useful in other applications. be 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.
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 July 14, 2014. This Internet-Draft will expire on September 3, 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
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . 5 3.2. The 'Require-Recipient-Valid-Since' Header Field . . . . . 5
3.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Use By Generators . . . . . . . . . . . . . . . . . . . . . . 6 4. Use By Generators . . . . . . . . . . . . . . . . . . . . . . 6
5. Handling By Receivers . . . . . . . . . . . . . . . . . . . . 6 5. Handling By Receivers . . . . . . . . . . . . . . . . . . . . 7
5.1. SMTP Extension Used . . . . . . . . . . . . . . . . . . . 7 5.1. SMTP Extension Used . . . . . . . . . . . . . . . . . . . 7
5.1.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Header Field Used . . . . . . . . . . . . . . . . . . . . 7 5.2. Header Field Used . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Design Choices . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Design Choices . . . . . . . . . . . . . . . . . . . . 9
6. Role Accounts . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Clock Synchronization . . . . . . . . . . . . . . . . . . 10
7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 9 6. Role Accounts . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 10
7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 10 7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 10
8. Header Field with Multiple Recipients . . . . . . . . . . . . 10 8. Header Field with Multiple Recipients . . . . . . . . . . . . 11
9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 11 9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 12
9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Single-Recipient Aliases . . . . . . . . . . . . . . . . . 11 9.2. Single-Recipient Aliases . . . . . . . . . . . . . . . . . 12
9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 12 9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 13
9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 12 9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 13
9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 12 9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 13
10. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 13 10. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 13
11. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 14 11. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 14
12. Authentication-Results Definitions . . . . . . . . . . . . . . 14 12. Authentication-Results Definitions . . . . . . . . . . . . . . 15
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 15 13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 15
13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 15 13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 16
13.3. Authentication-Results Example . . . . . . . . . . . . . . 16 13.3. Authentication-Results Example . . . . . . . . . . . . . . 16
14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 16 14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 17
14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 17 14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 17
14.3. False Sense of Security . . . . . . . . . . . . . . . . . 17 14.3. False Sense of Security . . . . . . . . . . . . . . . . . 17
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18
15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 17 15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 18
15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 18 15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 18
15.3. Risks with Use of Header Field . . . . . . . . . . . . . . 18 15.3. Risks with Use . . . . . . . . . . . . . . . . . . . . . . 19
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
16.1. SMTP Extension Registration . . . . . . . . . . . . . . . 19 16.1. SMTP Extension Registration . . . . . . . . . . . . . . . 19
16.2. Header Field Registration . . . . . . . . . . . . . . . . 19 16.2. Header Field Registration . . . . . . . . . . . . . . . . 19
16.3. Enhanced Status Code Registration . . . . . . . . . . . . 19 16.3. Enhanced Status Code Registration . . . . . . . . . . . . 19
16.4. Authentication Results Registration . . . . . . . . . . . 20 16.4. Authentication Results Registration . . . . . . . . . . . 20
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
17.1. Normative References . . . . . . . . . . . . . . . . . . . 21 17.1. Normative References . . . . . . . . . . . . . . . . . . . 21
17.2. Informative References . . . . . . . . . . . . . . . . . . 21 17.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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. correct address, but the wrong recipient.
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, "The person to whom I am sending to had effect, the sender is saying, "The last time the intended recipient
this address assigned to as far back as this date-time." A receiving was known to be using this address was this point in time." A
system can then compare this information against the date and time receiving system can then compare this information against the point
the address was assigned to its current user. If the assignment was in time at which the address was assigned to its current user. If
made later than the date-time indicated in the message, there is a the assignment was made later than the point in time indicated in the
good chance the current user of the address is not the correct message, there is a good chance the current user of the address is
recipient. The receiving system can then choose to prevent delivery not the correct recipient. The receiving system can then choose to
and, possibly, to notify the original sender of the problem. prevent delivery and, possibly, to notify the original sender of the
problem.
The primary application is automatically generated messages rather The primary application is automatically generated messages rather
than user-authored content, though it may be useful in other than user-authored content, though it may be useful in other
contexts. contexts.
One important point is that the protocols presented here provide a One important point is that the protocols presented here provide a
way for a sending system to make a request to receiving systems with way for a sending system to make a request to receiving systems with
respect to handling of a message. In the end, there is no guarantee respect to handling of a message. In the end, there is no guarantee
that the request will have the desired effect. that the request will have the desired effect.
skipping to change at page 5, line 5 skipping to change at page 5, line 10
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 above, a mail sending client needs To address the problem described above, a mail sending client needs
to indicate to the server to which it is connecting that there is an to indicate to the server to which it is connecting that there is an
expectation that the destination of the message has been under expectation that the destination of the message has been under
continuous ownership (see Section 10) since some date-time, continuous ownership (see Section 10) since some point in time,
presumably the most recent time the message author had confirmed its presumably the most recent time the message author had confirmed its
understanding of who owned that mailbox. Two mechanisms are defined understanding of who owned that mailbox. Two mechanisms are defined
here: an extension to the Simple Mail Transfer Protocol [SMTP] and a here: an extension to the Simple Mail Transfer Protocol [SMTP] and a
new message header field. The SMTP extension permits strong new message header field. The SMTP extension permits strong
assurance of enforcement by confirming support at each handling step assurance of enforcement by confirming support at each handling step
for a message. The header field does not provide the strong for a message. The header field does not provide the strong
assurance, but only requires adoption by the receiving Message assurance, but only requires adoption by the receiving Message
Delivery Agent (MDA). Delivery Agent (MDA).
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 date and 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 verbs, and does not associated parameters, introduces no new SMTP commands, and does not
alter the MAIL verb. 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 a 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 new parameter is "RRVS", which takes a value
that is a timestamp expressed as a "date-time" as defined in that is a timestamp expressed as a "date-time" as defined in
[DATETIME], with the added restriction that a "time-secfrac" MUST NOT [DATETIME], with the added restriction that a "time-secfrac" MUST NOT
be used. Accordingly, this extension increases the maximum command be used. Accordingly, this extension increases the maximum command
length for the RCPT verb by 31 characters. length for the RCPT command by 31 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
The header field version of this protocol has a different format for
the date and time expression than the SMTP extension does. This is
because message header fields use a format to express time and date
that is specific to message header fields, and this is consistent
with that usage.
Use of both date and time is done to be consistent with how current
implementations typically store the timestamp, and to make it easy to
include the time zone. In practice, granularity beyond the date may
or may not be useful.
4. Use By Generators 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 either the SMTP extension or the header field defined
above when sending the message to its destination. above when sending the message to its destination.
skipping to change at page 7, line 11 skipping to change at page 7, line 26
extension, so the RRVS parameter was not present on the RCPT TO extension, so the RRVS parameter was not present on the RCPT TO
commands in the SMTP session, but the corresponding header field commands in the SMTP session, but the corresponding header field
might be present in the message. might be present in the message.
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 MDA that implements the SMTP extension declared above and A receiving MTA or MDA that implements the SMTP extension declared
observes an RRVS parameter on a RCPT TO command checks whether the above and observes an RRVS parameter on a RCPT TO command checks
current owner of the destination mailbox has held it continuously, whether the current owner of the destination mailbox has held it
far enough back to include the given date-time, and delivers it continuously, far enough back to include the given point in time, and
unless that check returns in the negative. Specifically, an MDA will delivers it unless that check returns in the negative. Specifically,
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]. (See Section 6.)
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 16.3.)
skipping to change at page 7, line 50 skipping to change at page 8, line 16
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 the set of Require-Recipient-Valid-Since fields from MDA 1. Extract those Require-Recipient-Valid-Since fields from the
the message for which no corresponding RRVS SMTP extension was message that contain a recipient for which no corresponding RRVS
used. SMTP extension was used.
2. Discard any such fields that are syntactically invalid. 2. Discard any such fields that match any of these criteria:
3. Discard any such fields that name a role account as listed in * are syntactically invalid;
[ROLES] (see Section 6).
4. Discard any such fields for which the "addr-spec" portion does * name a role account as listed in [ROLES] (see Section 6);
not match a current recipient, as listed in the RCPT TO commands
in the SMTP session.
5. Discard any such fields for which the "addr-spec" portion does * the "addr-spec" portion does not match a current recipient, as
not refer to a mailbox handled for local delivery by this ADMD. listed in the RCPT TO commands in the SMTP session; or
6. For each field remaining, determine if the named address has been * the "addr-spec" portion does not refer to a mailbox handled
for local delivery by this ADMD.
3. For each field remaining, determine if the named address has been
under continuous ownership since the corresponding timestamp. If under continuous ownership since the corresponding timestamp. If
it has not, reject the message. it has not, reject the message.
7. RECOMMENDED: If local delivery is being performed, remove all 4. RECOMMENDED: If local delivery is being performed, remove all
instances of this field prior to delivery to a mailbox; if the instances of this field prior to delivery to a mailbox; if the
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 steps 1-4 above. field that were not discarded by steps 1-4 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
skipping to change at page 9, line 38 skipping to change at page 10, line 5
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.
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
The timestamp portion of this specification supports a precision at
the seconds level. Although uncommon, it is not impossible for a
clock at either a generator or a receiver to be incorrect, leading to
an incorrect result in the RRVS evaluation.
To minimize the risk of such incorrect results, both generators and
receivers implementing this specification MUST use a standard clock
synchronization protocol such as [NTP].
6. Role Accounts 6. Role Accounts
It is necessary not to interfere with delivery of messages to role It is necessary not to interfere with delivery of messages to role
mailboxes (see [ROLES]), but it could be useful to notify users mailboxes (see [ROLES]), but it could be useful to notify users
sending to those mailboxes that a change of ownership might have sending to those mailboxes that a change of ownership might have
taken place, if such notification is possible. taken place, if such notification is possible.
7. Relaying Without RRVS Support 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
skipping to change at page 13, line 23 skipping to change at page 14, line 4
relationship between the message's author and the mailing list. relationship between the message's author and the mailing list.
10. Continuous Ownership 10. 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 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
applied to establish this ownership of the receiver's mailbox; applied to establish this ownership of the receiver's mailbox;
however, the method of making such determinations is a local matter however, the method of making such determinations is a local matter
and outside the scope of this document. 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.
skipping to change at page 13, line 48 skipping to change at page 14, line 29
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 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 further obscure account details on the receiving system, the To avoid exposing account details unnecessarily, if the address
receiver SHOULD ignore the SMTP extension or the header field if the specified has had one continuous owner since it was created, any
address specified has had one continuous owner since it was created, confirmation date SHOULD be considered to pass the test, even if that
regardless of the purported confirmation date of the address. This date is earlier than the account creation date. This is further
is further discussed in Section 14. discussed in Section 14.
11. Digital Signatures 11. 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 iexceptional circumstances. Altering a message delivery in all but exceptional circumstances. Altering a message in
in this way will invalidate a digital signature intended to guard this way will invalidate a digital signature intended to guard
against message modification in transit, which can interfere with against message modification in transit, which can interfere with
delivery. delivery.
Section 5.4.1 of DomainKeys Identified Mail [DKIM] proposes a Section 5.4.1 of DomainKeys Identified Mail [DKIM] proposes a
strategy for selecting header fields to sign. Specifically, it strategy for selecting header fields to sign. Specifically, it
advises including in the signed portion of the message only those advises including in the signed portion of the message only those
header fields that comprise part of the core content of the message. header fields that comprise part of the core content of the message.
As the header field version of this protocol is ephemeral, it cannot As the header field version of this protocol is ephemeral, it cannot
be considered core content. be considered core content.
skipping to change at page 15, line 20 skipping to change at page 16, line 4
can be reported using the mechanism described in [AUTHRES]. can be reported using the mechanism described in [AUTHRES].
13. Examples 13. 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 13.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=1381993177 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 13.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
S: 354 Ready for message content S: 354 Ready for message content
skipping to change at page 16, line 45 skipping to change at page 17, line 12
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 14. Security Considerations
14.1. Abuse Countermeasures 14.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 existing email mailbox. Implementation information about the age of an existing email mailbox.
of countermeasures against probing attacks is advised. For example, Implementation of countermeasures against probing attacks is advised.
an operator could track appearance of this field with respect to a For example, an operator could track appearance of this field with
particular mailbox and observe the timestamps being submitted for respect to a particular mailbox and observe the timestamps being
testing; if it appears a variety of timestamps is being tried against submitted for testing; if it appears a variety of timestamps is being
a single mailbox in short order, the field could be ignored and the tried against a single mailbox in short order, the field could be
message silently discarded. This concern is discussed further in ignored and the message silently discarded. This concern is
Section 15. discussed further in Section 15.
14.2. Suggested Use Restrictions 14.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
can be silently ignored and normal message handling applied so that can be silently ignored and normal message handling applied so that
this information is not disclosed. Such fields are likely the 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.
skipping to change at page 17, line 34 skipping to change at page 17, line 49
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 14.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 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 15. Privacy Considerations
skipping to change at page 18, line 38 skipping to change at page 19, line 5
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 of Header Field 15.3. 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.
skipping to change at page 21, line 22 skipping to change at page 21, line 35
[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.
[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.
Kasch, "Network Time Protocol Version 4: Protocol and
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 17.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,
skipping to change at page 22, line 11 skipping to change at page 22, line 26
[ESC] Vaudreuil, G., "Enhanced Mail System Status Codes", [ESC] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003. RFC 3463, January 2003.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Erling Ellingsen proposed the idea. Erling Ellingsen proposed the idea.
Reviews and comments were provided by Michael Adkins, Kurt Andersen, Reviews and comments were provided by Michael Adkins, Kurt Andersen,
Eric Burger, Alissa Cooper, Dave Cridland, Dave Crocker, Ned Freed, Eric Burger, Alissa Cooper, Dave Cridland, Dave Crocker, Ned Freed,
John Levine, Alexey Melnikov, Hector Santos, Gregg Stefancik, Ed John Levine, Alexey Melnikov, Jay Nancarrow, Hector Santos, Gregg
Zayas, (others) 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.
 End of changes. 41 change blocks. 
80 lines changed or deleted 112 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/