--- 1/draft-ietf-appsawg-rrvs-header-field-04.txt 2013-12-11 16:15:17.615240070 -0800 +++ 2/draft-ietf-appsawg-rrvs-header-field-05.txt 2013-12-11 16:15:17.655241033 -0800 @@ -1,20 +1,20 @@ Network Working Group W. Mills Internet-Draft Yahoo! Inc. Intended status: Standards Track M. Kucherawy -Expires: May 23, 2014 Facebook, Inc. - November 19, 2013 +Expires: June 14, 2014 Facebook, Inc. + December 11, 2013 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension - draft-ietf-appsawg-rrvs-header-field-04 + draft-ietf-appsawg-rrvs-header-field-05 Abstract This document defines an extension for the Simple Mail Transfer Protocol called RRVS, and a header field called Require-Recipient- Valid-Since, to provide a method for senders to indicate to receivers the time when the sender last confirmed the ownership of the target mailbox. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -70,41 +70,41 @@ 7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 8 7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 9 8. Header Field with Multiple Recipients . . . . . . . . . . . . 9 9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 10 9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Single-Recipient Alaises . . . . . . . . . . . . . . . . . 10 9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 11 9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 11 9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 11 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 11. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 12 + 11. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 13 12. Authentication-Results Definitions . . . . . . . . . . . . . . 13 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 14 - 13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 14 + 13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 15 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 15 - 14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 15 - 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15 - 15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 15 - 15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 16 - 15.3. Risks with Use of Header Field . . . . . . . . . . . . . . 16 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 16 + 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 + 15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 16 + 15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 17 + 15.3. Risks with Use of Header Field . . . . . . . . . . . . . . 17 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 16.1. SMTP Extension 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 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 17.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 17.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 + 17.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 1. Introduction Email addresses sometimes get reassigned to a different person. For example, employment changes at a company can cause an address used for an ex-employee to be assigned to a new employee, or a mail service provider (MSP) might expire an account and then let someone else register for the local-part that was previously used. Those who sent mail to the previous owner of an address might not know that it has been reassigned. This can lead to the sending of email to the @@ -136,38 +136,35 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 3. Description To address the problem described above, a mail sending client needs to indicate to the server to which it is connecting that there is an expectation that the destination of the message has been under - continuous ownership since some date-time, presumably the most recent - time the message author had confirmed its understanding of who owned - that mailbox. Two mechanisms are defined here: an extension to the - Simple Mail Transfer Protocol [SMTP], for use between a client and - server that both implement the extension, and a header field that can - be used when passing a message to a server that appears not to - implement this extension. + continuous ownership (see Section 11) since some date-time, + presumably the most recent time the message author had confirmed its + understanding of who owned that mailbox. Two mechanisms are defined + here: an extension to the Simple Mail Transfer Protocol [SMTP], for + use between a client and server that both implement the extension, + and a header field that can be used when passing a message to a + server that appears not to implement this extension. The SMTP extenion is called "RRVS" (Require Recipient Valid Since), and adds a parameter to the SMTP "RCPT" command that indicates the most recent date and time when the message author believed the - destination mailbox to be under the continuous ownership (see - Section 11) of a specific party. Similarly, the Require-Recipient- - Valid-Since header field includes an intended recipient coupled with - a timestamp indicating the same thing. Presumably there has been - 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. + destination mailbox to be under the continuous ownership of a + specific party. Similarly, the Require-Recipient-Valid-Since header + field includes an intended recipient coupled with a timestamp + indicating the same thing. 3.1. The 'RRVS' SMTP Extension Extensions to SMTP are described in Section 2.2 of [SMTP]. The name of the extension is "RRVS", an abbreviation of "Require Recipient Valid Since". Servers implementing the SMTP extension advertise an additional EHLO keyword of "RRVS", which has no associated parameters, introduces no new SMTP verbs, and does not alter the MAIL verb. @@ -182,24 +179,25 @@ The meaning of this extension, when used, is described in Section 5.1. 3.2. The 'Require-Recipient-Valid-Since' Header Field The general constraints on syntax and placement of header fields in a message are defined in Internet Message Format [MAIL]. Using Augmented Backus-Naur Form [ABNF], the syntax for the field is: - rrvs = "Require-Recipient-Valid-Since:" addr-spec; date-time CRLF + rrvs = "Require-Recipient-Valid-Since:" addr-spec ";" date-time + CRLF - "CFWS" is defined in Section 3.2.2, "date-time" is defined in Section - 3.3, and "addr-spec" is defined in Section 3.4.1, of [MAIL]. + "date-time" is defined in Section 3.3, and "addr-spec" is defined in + Section 3.4.1, of [MAIL]. 4. Use By Generators When a message is generated whose content is sufficiently sensitive that an author or author's Administrative Management Domain (ADMD; see [EMAIL-ARCH]) wishes to protect against misdelivery using this protocol, it determines for each recipient mailbox on the message a timestamp at which it last confirmed ownership of that mailbox. It then applies either the SMTP extension or the header field defined above when sending the message to its destination. @@ -235,28 +233,33 @@ the current owner of the destination mailbox has held it continuously, far enough back to inclue the given date-time, and delivers it unless that check returns in the negative. Expressed as a sequence of steps: 1. Ignore the parameter if the named mailbox is a role account as listed in Mailbox Names For Common Services, Roles And Functions [ROLES]. (See Section 6.) 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 the RCPT command. (See also Section 16.3.) 3. RECOMMENDED: If any Require-Recipient-Valid-Since header fields are present and refer to the named address, remove them prior to 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 An MTA that does not make mailbox ownership checks, such as an MTA positioned to do SMTP ingress at an organizational boundary, SHOULD relay the RRVS extension parameter to the next MTA so that it can be processed there. See Section 9.2 for additional discussion. 5.2. Header Field Used @@ -355,21 +358,25 @@ corresponding message on to another server ("C") (thereby becoming a client), but "C" does not advertise the SMTP extension and "B" elects not to reject the message, "B" SHOULD add Require-Recipient-Valid- Since header fields matching each mailbox to which relaying is being done, and the corresponding valid-since timestamp for each. Similarly, if "B" receives a message bearing one or more Require- Recipient-Valid-Since header fields from "A" for which it must now relay the message, and "C" advertises support for the SMTP extension, "B" SHOULD delete the header field(s) and instead relay this - information by making use of the SMTP extension. + 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 Numerous issues arise when using the header field form of this extension, particularly when multiple recipients are specified for a single message resulting in one multiple fields each with a distinct address and timestamp. Because of the nature of SMTP, a message bearing a multiplicity of Require-Recipient-Valid-Since header fields could result in a single @@ -422,27 +429,28 @@ place of a mailbox) that results in relaying of the message to a single other destination, the usual RRVS check is performed. The continuous ownership test here might succeed if a conventional user inbox was replaced with an alias on behalf of that same user, and this information is recorded someplace. If the message is thus 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 the new address. (RECOMMENDED) - 2. If, however, the relaying system knows the time when the alias - was established, it MAY add an RRVS parameter for the new target - address that includes that time. + 2. If the relaying system records the time when the alias was + established, independent of confirming the validity of the new + 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 - RRVS parameter for the new target address that includes that - time. + 3. If an explicit confirmation of the new destination was done, it + MAY add an RRVS parameter for the new target address that + includes that time. There is risk and additional administrative burden associated with all but the first option in that list which are believed to make them not worth pursuing. 9.3. Multiple-Recipient Aliases Upon delivery of an RRVS-protected message to an alias (acting in place of a mailbox) that results in relaying of the message to multiple other destinations, the usual RRVS check is performed as in @@ -513,36 +521,50 @@ the header field does not refer to a current envelope recipient, and in either case delivers the message. SMTP has never required any correspondence between addresses in the RFC5321.MailFrom and RFC5321.RcptTo parameters and header fields of a message, which is why the header field defined here contains the recipient address to which the timestamp applies. 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 - the receiving site. In particular, the only possible answers to the - continuous-ownership-since question are "yes", "no", and "unknown"; - the action to be taken in the "unknown" case is a matter of local - policy. + the receiving site. The only possible answers to the continuous- + ownership-since question are "yes", "no", and "unknown"; the action + to be taken in the "unknown" case is a matter of local policy. For example, when control of a domain name is transferred, the new domain owner might be unable to determine whether the owner of the subject address has been under continuous ownership since the stated date if the mailbox history is not also transferred (or was not - previously maintained). - - It will also be "unknown" if whatever database contains mailbox - ownership data is temporarily unavailable at the time a message - arrives for delivery. In this case, typical SMTP temporary failure - handling is appropriate. + previously maintained). It will also be "unknown" if whatever + database contains mailbox ownership data is temporarily unavailable + at the time a message arrives for delivery. In this latter case, + typical SMTP temporary failure handling is appropriate. 12. Authentication-Results Definitions [AUTHRES] defines a mechanism for indicating, via a header field, the results of message authentication checks. Section 16 registers RRVS as a new method that can be reported in this way, and corresponding result names. The possible result names and their meanings are as follows: none: The message had no recipient mailbox timestamp associated with @@ -650,21 +672,22 @@ A message author using this specification might restrict inclusion of the header field such that it is only done for recipients known also to implement this specification, in order to reduce the possibility of revealing information about the relationship between the author and the mailbox. If ownership of an entire domain is transferred, the new owner may not know what addresses were assigned in the past by the prior owner. Hence, no address can be known not to have had a single owner, or to - have existed (or not) at all. + have existed (or not) at all. In this case, the "unknown" result is + likely appropriate. 15. Privacy Considerations 15.1. 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