draft-ietf-appsawg-rrvs-header-field-07.txt   draft-ietf-appsawg-rrvs-header-field-08.txt 
Network Working Group W. Mills Network Working Group W. Mills
Internet-Draft Yahoo! Inc. Internet-Draft Yahoo! Inc.
Intended status: Standards Track M. Kucherawy Intended status: Standards Track M. Kucherawy
Expires: September 3, 2014 Facebook, Inc. Expires: September 21, 2014 Facebook, Inc.
March 2, 2014 March 20, 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-07 draft-ietf-appsawg-rrvs-header-field-08
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 point in time when the sender last confirmed the ownership of the the point in time when the sender last confirmed the ownership of the
target mailbox. This can be used to detect changes of mailbox target mailbox. This can be used to detect changes of mailbox
ownership, and thus prevent mail from being delivered to the wrong ownership, and thus prevent mail from being delivered to the wrong
party. party.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2014. This Internet-Draft will expire on September 21, 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
skipping to change at page 15, line 30 skipping to change at page 15, line 30
temperror: At least one form of this protocol was in use, but some temperror: At least one form of this protocol was in use, but some
kind of error occurred during evaluation that was transient in kind of error occurred during evaluation that was transient in
nature; a later retry will likely produce a final result. nature; a later retry will likely produce a final result.
permerror: At least one form of this protocol was in use, but some permerror: At least one form of this protocol was in use, but some
kind of error occurred during evaluation that was not recoverable; kind of error occurred during evaluation that was not recoverable;
a later retry will not likely produce a final result. a later retry will not likely produce a final result.
pass: At least one form of this protocol was in use, and the 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. ownership since the timestamp thus provided.
fail: At least one form of this protocol was in use, and the fail: At least one form of this protocol was in use, and the
destination mailbox was confirmed not to have been under constant destination mailbox was confirmed not to have been under
ownership since the timestamp thus provided. continuous ownership since the timestamp thus provided.
Where multiple recipients are present on a message, multiple results Where multiple recipients are present on a message, multiple results
can be reported using the mechanism described in [AUTHRES]. can be reported using the mechanism described in [AUTHRES].
13. Examples 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.
skipping to change at page 17, line 13 skipping to change at page 17, line 13
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 an existing email mailbox. information about the age of an existing email mailbox.
Implementation of countermeasures against probing attacks is advised. Implementation of countermeasures against probing attacks is
For example, an operator could track appearance of this field with RECOMMENDED. For example, an operator could track appearance of this
respect to a particular mailbox and observe the timestamps being field with respect to a particular mailbox and observe the timestamps
submitted for testing; if it appears a variety of timestamps is being being submitted for testing; if it appears a variety of timestamps is
tried against a single mailbox in short order, the field could be being tried against a single mailbox in short order, the field could
ignored and the message silently discarded. This concern is be ignored and the message silently discarded. This concern is
discussed further in Section 15. discussed further in Section 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 SHOULD be silently ignored and normal message handling applied so
this information is not disclosed. Such fields are likely the that this information is not disclosed. Such fields are likely the
product of either gross error or an attack. product of either gross error or an attack.
A message author using this specification might restrict inclusion of A message author using this specification might restrict inclusion of
the header field such that it is only done for recipients known also the header field such that it is only done for recipients known also
to implement this specification, in order to reduce the possibility to implement this specification, in order to reduce the possibility
of revealing information about the relationship between the author of revealing information about the relationship between the author
and the mailbox. and the mailbox.
If ownership of an entire domain is transferred, the new owner may If ownership of an entire domain is transferred, the new owner may
not know what addresses were assigned in the past by the prior owner. not know what addresses were assigned in the past by the prior owner.
 End of changes. 7 change blocks. 
15 lines changed or deleted 15 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/