--- 1/draft-ietf-appsawg-rrvs-header-field-07.txt 2014-03-20 13:14:35.521942695 -0700 +++ 2/draft-ietf-appsawg-rrvs-header-field-08.txt 2014-03-20 13:14:35.561943663 -0700 @@ -1,20 +1,20 @@ Network Working Group W. Mills Internet-Draft Yahoo! Inc. Intended status: Standards Track M. Kucherawy -Expires: September 3, 2014 Facebook, Inc. - March 2, 2014 +Expires: September 21, 2014 Facebook, Inc. + March 20, 2014 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension - draft-ietf-appsawg-rrvs-header-field-07 + draft-ietf-appsawg-rrvs-header-field-08 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 point in 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. @@ -31,21 +31,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 September 3, 2014. + This Internet-Draft will expire on September 21, 2014. Copyright Notice Copyright (c) 2014 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 @@ -644,26 +644,26 @@ temperror: At least one form of this protocol was in use, but some kind of error occurred during evaluation that was transient in nature; a later retry will likely produce a final result. permerror: At least one form of this protocol was in use, but some kind of error occurred during evaluation that was not recoverable; a later retry will not likely produce a final result. pass: At least one form of this protocol was in use, and the - destination mailbox was confirmed to have been under constant + destination mailbox was confirmed to have been under continuous ownership since the timestamp thus provided. fail: At least one form of this protocol was in use, and the - destination mailbox was confirmed not to have been under constant - ownership since the timestamp thus provided. + destination mailbox was confirmed not to have been under + continuous ownership since the timestamp thus provided. Where multiple recipients are present on a message, multiple results can be reported using the mechanism described in [AUTHRES]. 13. Examples In the following examples, "C:" indicates data sent by an SMTP client, and "S:" indicates responses by the SMTP server. Message content is CRLF terminated, though these are omitted here for ease of reading. @@ -718,35 +718,35 @@ user@example.com, the continuous ownership test was applied with the provided timestamp, and the check revealed that test was satisfied. The timestamp is not revealed. 14. Security Considerations 14.1. Abuse Countermeasures The response of a server implementing this protocol can disclose information about the age of an existing email mailbox. - Implementation of countermeasures against probing attacks is advised. - For example, an operator could track appearance of this field with - respect to a particular mailbox and observe the timestamps being - submitted for testing; if it appears a variety of timestamps is being - tried against a single mailbox in short order, the field could be - ignored and the message silently discarded. This concern is + Implementation of countermeasures against probing attacks is + RECOMMENDED. For example, an operator could track appearance of this + field with respect to a particular mailbox and observe the timestamps + being submitted for testing; if it appears a variety of timestamps is + being tried against a single mailbox in short order, the field could + be ignored and the message silently discarded. This concern is discussed further in Section 15. 14.2. Suggested Use Restrictions 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 any owner) prior to the date specified in the field, then the field - can be silently ignored and normal message handling applied so that - this information is not disclosed. Such fields are likely the + SHOULD be silently ignored and normal message handling applied so + that this information is not disclosed. Such fields are likely the product of either gross error or an attack. 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.