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/