draft-ietf-appsawg-rrvs-header-field-04.txt   draft-ietf-appsawg-rrvs-header-field-05.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: May 23, 2014 Facebook, Inc. Expires: June 14, 2014 Facebook, Inc.
November 19, 2013 December 11, 2013
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-04 draft-ietf-appsawg-rrvs-header-field-05
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 time when the sender last confirmed the ownership of the target
mailbox. This can be used to detect changes of mailbox ownership, mailbox. This can be used to detect changes of mailbox ownership,
and thus prevent mail from being delivered to the wrong party. and thus prevent mail from being delivered to the wrong party.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 May 23, 2014. This Internet-Draft will expire on June 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 8 7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 8
7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 9 7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 9
8. Header Field with Multiple Recipients . . . . . . . . . . . . 9 8. Header Field with Multiple Recipients . . . . . . . . . . . . 9
9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 10 9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 10
9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Single-Recipient Alaises . . . . . . . . . . . . . . . . . 10 9.2. Single-Recipient Alaises . . . . . . . . . . . . . . . . . 10
9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 11 9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 11
9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 11 9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 11
9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 11 9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 11
10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 12 11. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 13
12. Authentication-Results Definitions . . . . . . . . . . . . . . 13 12. Authentication-Results Definitions . . . . . . . . . . . . . . 13
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 14 13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 14
13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 14 13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 15
14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 15 14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 15
14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 15 14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 16
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16
15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 15 15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 16
15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 16 15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 17
15.3. Risks with Use of Header Field . . . . . . . . . . . . . . 16 15.3. Risks with Use of Header Field . . . . . . . . . . . . . . 17
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
16.1. SMTP Extension Registration . . . . . . . . . . . . . . . 17 16.1. SMTP Extension Registration . . . . . . . . . . . . . . . 17
16.2. Header Field Registration . . . . . . . . . . . . . . . . 17 16.2. Header Field Registration . . . . . . . . . . . . . . . . 17
16.3. Enhanced Status Code Registration . . . . . . . . . . . . 17 16.3. Enhanced Status Code Registration . . . . . . . . . . . . 18
16.4. Authentication Results Registration . . . . . . . . . . . 18 16.4. Authentication Results Registration . . . . . . . . . . . 18
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
17.1. Normative References . . . . . . . . . . . . . . . . . . . 19 17.1. Normative References . . . . . . . . . . . . . . . . . . . 19
17.2. Informative References . . . . . . . . . . . . . . . . . . 19 17.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
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 49 skipping to change at page 4, line 49
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 since some date-time, presumably the most recent continuous ownership (see Section 11) since some date-time,
time the message author had confirmed its understanding of who owned presumably the most recent time the message author had confirmed its
that mailbox. Two mechanisms are defined here: an extension to the understanding of who owned that mailbox. Two mechanisms are defined
Simple Mail Transfer Protocol [SMTP], for use between a client and here: an extension to the Simple Mail Transfer Protocol [SMTP], for
server that both implement the extension, and a header field that can use between a client and server that both implement the extension,
be used when passing a message to a server that appears not to and a header field that can be used when passing a message to a
implement this extension. server that appears not to implement this extension.
The SMTP extenion is called "RRVS" (Require Recipient Valid Since), The SMTP extenion 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 date and time when the message author believed the
destination mailbox to be under the continuous ownership (see destination mailbox to be under the continuous ownership of a
Section 11) of a specific party. Similarly, the Require-Recipient- specific party. Similarly, the Require-Recipient-Valid-Since header
Valid-Since header field includes an intended recipient coupled with field includes an intended recipient coupled with a timestamp
a timestamp indicating the same thing. Presumably there has been indicating the same thing.
some confirmation process applied to establish this ownership;
however, the method of making such determinations is a local matter
and outside the scope of this document.
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 verbs, and does not
alter the MAIL verb. alter the MAIL verb.
skipping to change at page 5, line 46 skipping to change at page 5, line 43
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 CRLF rrvs = "Require-Recipient-Valid-Since:" addr-spec ";" date-time
CRLF
"CFWS" is defined in Section 3.2.2, "date-time" is defined in Section "date-time" is defined in Section 3.3, and "addr-spec" is defined in
3.3, and "addr-spec" is defined in Section 3.4.1, of [MAIL]. Section 3.4.1, of [MAIL].
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 6 skipping to change at page 7, line 6
the current owner of the destination mailbox has held it the current owner of the destination mailbox has held it
continuously, far enough back to inclue the given date-time, and continuously, far enough back to inclue the given date-time, and
delivers it unless that check returns in the negative. Expressed as delivers it unless that check returns in the negative. Expressed as
a sequence of steps: a sequence of steps:
1. Ignore the parameter if the named mailbox is a role account as 1. Ignore the parameter if the named mailbox is a role account as
listed in Mailbox Names For Common Services, Roles And Functions listed in Mailbox Names For Common Services, Roles And Functions
[ROLES]. (See Section 6.) [ROLES]. (See Section 6.)
2. Determine if the named address is serviced for local delivery. 2. Determine if the named address is serviced for local delivery.
If so, and if that address, has not been under continuous If so, and if that address has not been under continuous
ownership since the specified timestamp, return a 550 error to ownership since the specified timestamp, return a 550 error to
the RCPT command. (See also Section 16.3.) the RCPT command. (See also Section 16.3.)
3. RECOMMENDED: If any Require-Recipient-Valid-Since header fields 3. RECOMMENDED: If any Require-Recipient-Valid-Since header fields
are present and refer to the named address, remove them prior to are present and refer to the named address, remove them prior to
delivery or relaying. (See Section 5.2 for discussion.) delivery or relaying. (See Section 5.2 for discussion.)
Where a message arrives using the SMTP extension that also contains
the Require-Recipient-Valid-Since header field in its header, the
header field SHOULD be removed. (See Section 7.1 for further
discussion about removal of the header field.)
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 so that it can be relay the RRVS extension parameter to the next MTA so that it can be
processed there. processed there.
See Section 9.2 for additional discussion. See Section 9.2 for additional discussion.
5.2. Header Field Used 5.2. Header Field Used
skipping to change at page 9, line 30 skipping to change at page 9, line 35
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), but "C" does not advertise the SMTP extension and "B" elects
not to reject the message, "B" SHOULD add Require-Recipient-Valid- not to reject the message, "B" SHOULD add Require-Recipient-Valid-
Since header fields matching each mailbox to which relaying is being Since header fields matching each mailbox to which relaying is being
done, and the corresponding valid-since timestamp for each. done, and the corresponding valid-since timestamp for each.
Similarly, if "B" receives a message bearing one or more Require- Similarly, if "B" receives a message bearing one or more Require-
Recipient-Valid-Since header fields from "A" for which it must now Recipient-Valid-Since header fields from "A" for which it must now
relay the message, and "C" advertises support for the SMTP extension, relay the message, and "C" advertises support for the SMTP extension,
"B" SHOULD delete the header field(s) and instead relay this "B" SHOULD delete the header field(s) and instead relay this
information by making use of the SMTP extension. information by making use of the SMTP extension. Note that such
modification of the header might affect later validation of the
header upon delivery; for example, a hash of the header would produce
a different result. This might be a valid cause for some operators
to skip this delete operation.
8. Header Field with Multiple Recipients 8. 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 one multiple fields each with a distinct single message resulting in one 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
skipping to change at page 10, line 49 skipping to change at page 11, line 10
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 a conventional user continuous ownership test here might succeed if a conventional user
inbox was replaced with an alias on behalf of that same user, and inbox was replaced with an alias on behalf of that same user, and
this information is recorded someplace. If the message is thus this information is recorded someplace. If the message is thus
accepted, the relaying MTA can choose to do one of the following: accepted, the relaying MTA can choose to do one of the following:
1. Do not include an RRVS parameter or header field when relaying to 1. Do not include an RRVS parameter or header field when relaying to
the new address. (RECOMMENDED) the new address. (RECOMMENDED)
2. If, however, the relaying system knows the time when the alias 2. If the relaying system records the time when the alias was
was established, it MAY add an RRVS parameter for the new target established, independent of confirming the validity of the new
address that includes that time. destination address, it MAY add an RRVS parameter for the new
target address that includes that time.
3. If a confirmation of the new destination was done, it MAY add an 3. If an explicit confirmation of the new destination was done, it
RRVS parameter for the new target address that includes that MAY add an RRVS parameter for the new target address that
time. includes that time.
There is risk and additional administrative burden associated with There is risk and additional administrative burden associated with
all but the first option in that list which are believed to make them all but the first option in that list which are believed to make them
not worth pursuing. not worth pursuing.
9.3. Multiple-Recipient Aliases 9.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
skipping to change at page 12, line 46 skipping to change at page 13, line 7
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.
11. Continuous Ownership 11. Continuous Ownership
For the purposes of this specification, an address is defined as
having been under continuous ownership since a given date-time if a
message sent to the address at any point since the given date would
not go to anyone except the owner at that given date-time. That is,
while an address may have been suspended or otherwise disabled for
some period, any mail actually delivered would have been delivered
exclusively to the same owner. It is is presumed that some sort of
relationship exists between the message sender and the intended
recipient. Presumably there has been some confirmation process
applied to establish this ownership of the receiver's mailbox;
however, the method of making such determinations is a local matter
and outside the scope of this document.
Evaluating the notion of continuous ownership is accomplished by
doing any query that establishes whether the above condition holds
for a given mailbox.
Determining continuous ownership of a mailbox is a local matter at Determining continuous ownership of a mailbox is a local matter at
the receiving site. In particular, the only possible answers to the the receiving site. The only possible answers to the continuous-
continuous-ownership-since question are "yes", "no", and "unknown"; ownership-since question are "yes", "no", and "unknown"; the action
the action to be taken in the "unknown" case is a matter of local to be taken in the "unknown" case is a matter of local policy.
policy.
For example, when control of a domain name is transferred, the new For example, when control of a domain name is transferred, the new
domain owner might be unable to determine whether the owner of the domain owner might be unable to determine whether the owner of the
subject address has been under continuous ownership since the stated subject address has been under continuous ownership since the stated
date if the mailbox history is not also transferred (or was not date if the mailbox history is not also transferred (or was not
previously maintained). previously maintained). It will also be "unknown" if whatever
database contains mailbox ownership data is temporarily unavailable
It will also be "unknown" if whatever database contains mailbox at the time a message arrives for delivery. In this latter case,
ownership data is temporarily unavailable at the time a message typical SMTP temporary failure handling is appropriate.
arrives for delivery. In this case, typical SMTP temporary failure
handling is appropriate.
12. Authentication-Results Definitions 12. 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 16 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
skipping to change at page 15, line 44 skipping to change at page 16, line 23
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. have existed (or not) at all. In this case, the "unknown" result is
likely appropriate.
15. Privacy Considerations 15. Privacy Considerations
15.1. Probing Attacks 15.1. Probing Attacks
As described above, use of this extension or header field in probing As described above, use of this extension or header field in probing
attacks can disclose information about the history of the mailbox. attacks can disclose information about the history of the mailbox.
The harm that can be done by leaking any kind of private information The harm that can be done by leaking any kind of private information
is difficult to predict, so it is prudent to be sensitive to this is difficult to predict, so it is prudent to be sensitive to this
sort of disclosure, either inadvertently or in response to probing by sort of disclosure, either inadvertently or in response to probing by
 End of changes. 21 change blocks. 
51 lines changed or deleted 74 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/