< draft-ietf-repute-model-05.txt		draft-ietf-repute-model-06.txt >
	REPUTE Working Group N. Borenstein		REPUTE Working Group N. Borenstein
	Internet-Draft Mimecast		Internet-Draft Mimecast
	Intended status: Informational M. Kucherawy		Intended status: Informational M. Kucherawy
	Expires: December 8, 2013 Cloudmark		Expires: January 4, 2014
	A. Sullivan, Ed.		A. Sullivan, Ed.
	Dyn, Inc.		Dyn, Inc.
	June 6, 2013		July 3, 2013
	A Model for Reputation Reporting		A Model for Reputation Reporting
	draft-ietf-repute-model-05		draft-ietf-repute-model-06
	Abstract		Abstract
	This document describes a general architecture for a reputation-based		This document describes a general architecture for a reputation-based
	service and a model for requesting reputation-related data over the		service and a model for requesting reputation-related data over the
	Internet, where "reputation" refers to predictions or expectations		Internet, where "reputation" refers to predictions or expectations
	about an entity or an identifier such as a domain name. The document		about an entity or an identifier such as a domain name. The document
	roughly follows the recommendations of RFC4101 for describing a		roughly follows the recommendations of RFC4101 for describing a
	protocol model.		protocol model.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 December 8, 2013.		This Internet-Draft will expire on January 4, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. High-Level Architecture . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology and Definitions . . . . . . . . . . . . . . . . . 7		3. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5
	3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 7		4. Terminology and Definitions . . . . . . . . . . . . . . . . . 8
	3.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Information Represented in a Response Set . . . . . . . . . . 7		4.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Information Flow in the Reputation Query Protocol . . . . . . 8		5. Information Represented in a Response Set . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. Information Flow in the Reputation Query Protocol . . . . . . 9
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 8		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
	7.2. Collection Of Data . . . . . . . . . . . . . . . . . . . . 9		8.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8.2. Collection Of Data . . . . . . . . . . . . . . . . . . . . 10
	8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 9		9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 10		9.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 11
	8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 10		9.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 11
	9. Informative References . . . . . . . . . . . . . . . . . . . . 10		9.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 11
	Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 11		10. Informative References . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Historically, many Internet protocols have operated between		Historically, many Internet protocols have operated between
	unauthenticated entities. For example, an email message's author		unauthenticated entities. For example, an email message's author
	field (From) [MAIL] can contain any display name or address and is		field (From) [MAIL] can contain any display name or address and is
	not verified by the recipient or other agents along the delivery		not verified by the recipient or other agents along the delivery
	path. Similarly, a sending email server using [SMTP] trusts that the		path. Similarly, a sending email server using [SMTP] trusts that the
	[DNS] has led it to the intended receiving server. Both kinds of		[DNS] has led it to the intended receiving server. Both kinds of
	trust are easily betrayed, opening the operation to subversion of		trust are easily betrayed, opening the operation to subversion of
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 30 ¶
	a generic query mechanism and basic format for reputation retrieval,		a generic query mechanism and basic format for reputation retrieval,
	but allows extensions for each application.		but allows extensions for each application.
	Omitted from this model is the means by which a reputation-reporting		Omitted from this model is the means by which a reputation-reporting
	agent goes about collecting such data and the method for creating an		agent goes about collecting such data and the method for creating an
	evaluation. The mechanism defined here merely enables asking a		evaluation. The mechanism defined here merely enables asking a
	question and getting an answer; the remainder of an overall service		question and getting an answer; the remainder of an overall service
	provided by such a reputation agent is specific to the implementation		provided by such a reputation agent is specific to the implementation
	of that service and is out of scope here.		of that service and is out of scope here.
	2. High-Level Architecture		2. Overview
			The basic premise of this reputation system involves a client that is
			seeking to evaluate content based on an identifier associated with
			the content, and a reputation service provider that collects,
			aggregates, and makes available for consumption, scores based on the
			collected data. Typically client and service operators enter into
			some kind of agreement during which some parameters are exchanged
			such as the location at which the reputation service can be reached,
			the nature of the reputation data being offered, possibly some client
			authentication details, and the like.
			Upon receipt of some content the client operator wishes to evaluate
			(an Internet message, for example), the client extracts from the
			content one or more identifiers of interest to be evaluated.
			Examples of this include the domain name found in the From: field of
			a message, or the domain name extracted from a valid DomainKeys
			Identified Mail (DKIM) signature.
			Next, the goal is to ask the reputation service provider what the
			reputation of the extracted identifier is. This is a two-stage
			query. The first query is to the reputation service provider at a
			well-known resource location to download a template. The template is
			a string into which various parameters about the query, including the
			identifier to be evaluated, are substituted. The result is a second
			resource location, and a query to this location is the actual
			reputation request.
			The client then issues a query to the second location to request the
			reputation score associated with the extracted identifier. The
			client typically folds this information into whatever local
			evaluation logic it applies to decide what disposition the content
			deserves.
			3. High-Level Architecture
	A reputation mechanism functions as a component of an overall		A reputation mechanism functions as a component of an overall
	service. A current example is that of an email system that uses		service. A current example is that of an email system that uses
	DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable		DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable
	identifier to a message and then uses that as a basis for evaluation:		identifier to a message and then uses that as a basis for evaluation:
	+-------------+ +------------+		+-------------+ +------------+
	| Author | | Recipient |		| Author | | Recipient |
	+-------------+ +------------+		+-------------+ +------------+
	| ^		| ^
	skipping to change at page 5, line 22 ¶		skipping to change at page 6, line 22 ¶
	+-------------+ +------------+		+-------------+ +------------+
	| ^		| ^
	| |		| |
	| +------------+		| +------------+
	| | Handling |		| | Handling |
	| | Filter |		| | Filter |
	| +------------+		| +------------+
	| ^		| ^
	| |		| |
	| +------------+ +------------+		| +------------+ +------------+
	| | Reputation |------>| Identifier |		| | Reputation |<=====>| Identifier |
	| | Service | | Assessor |		| | Service | | Assessor |
	| +------------+ +------------+		| +------------+ +------------+
	| ^		| ^
	V |		V |
	+----------------------------------------------------------+		+----------------------------------------------------------+
	| +------------+ Responsible Identifier +------------+ |		| +------------+ Responsible Identifier +------------+ |
	| | Identifier |. . . . . . . . . . . . . .>| Identifier | |		| | Identifier |. . . . . . . . . . . . . .>| Identifier | |
	| | Signer | | Verifier | |		| | Signer | | Verifier | |
	| +------------+ DKIM Service +------------+ |		| +------------+ DKIM Service +------------+ |
	+----------------------------------------------------------+		+----------------------------------------------------------+
	| ^		| ^
	V |		V |
	+-------------+ /~~~~~~~~~~\ +------+-----+		+-------------+ /~~~~~~~~~~\ +------+-----+
	| MTA |----->( other MTAs )------>| MTA |		| MTA |----->( other MTAs )------>| MTA |
	+-------------+ \~~~~~~~~~~/ +------------+		+-------------+ \~~~~~~~~~~/ +------------+
	Figure 1: Actors in a Trust Sequence Using DKIM		Figure 1: Actors in a Trust Sequence Using DKIM
	(See [EMAIL-ARCH] for a general description of the Internet messaging		(See [EMAIL-ARCH] for a general description of the Internet messaging
	architecture.) Here, the DKIM Service provides one or more stable		architecture.) In this figure, the solid lines indicate the flow of
	identifiers that is the basis for the reputation query. On receipt		a message; the dotted line indicates transfer of validated
	of a message from an MTA, the DKIM Service provides a (possibly		identifiers within the message content; and the double line shows the
	empty) set of validated identifiers -- domain names, in this case --		query and response of the reputation information.
	which are the subjects of reputation queries made by the Identity
	Assessor. The Identity Assessor queries a Reputation Service to		Here, the DKIM Service provides one or more stable identifiers that
	determine the reputation of the provided identifiers, and delivers		is the basis for the reputation query. On receipt of a message from
	the identifiers and their reputations to the Handling Filter. The		an MTA, the DKIM Service provides a (possibly empty) set of validated
	Handling Filter makes a decision about whether and how to deliver the		identifiers -- domain names, in this case -- which are the subjects
	message to the recipient based on these and other inputs about the		of reputation queries made by the Identity Assessor. The Identity
	message, possibly including evaluation mechansisms in addition to		Assessor queries a Reputation Service to determine the reputation of
	DKIM.		the provided identifiers, and delivers the identifiers and their
			reputations to the Handling Filter. The Handling Filter makes a
			decision about whether and how to deliver the message to the
			recipient based on these and other inputs about the message, possibly
			including evaluation mechansisms in addition to DKIM.
	This document outlines the reputation query and response mechanism.		This document outlines the reputation query and response mechanism.
	It provides the following definitions:		It provides the following definitions:
	o Vocabulary for the current work and work of this type;		o Vocabulary for the current work and work of this type;
	o The types and content of queries that can be supported;		o The types and content of queries that can be supported;
	o The extensible range of response information that can be provided;		o The extensible range of response information that can be provided;
	o A query/response protocol;		o A query/response protocol;
	o Query/response transport conventions.		o Query/response transport conventions.
	It provides an extremely simple query/response model that can be		It provides an extremely simple query/response model that can be
	carried over a variety of transports, including the Domain Name		carried over a variety of transports, including the Domain Name
	System. (Although not typically thought of as a 'transport', the DNS		System. (Although not typically thought of as a 'transport', the DNS
	provides generic capabilities and can be thought of as a mechanism		provides generic capabilities and can be thought of as a mechanism
	for transporting queries and responses that have nothing to do with		for transporting queries and responses that have nothing to do with
	addresses.) Each specification for Repute transport is independent		Internet addresses, such as is one with a DNS BlockList [DNSBL].)
	of any other specification. A diagram of the basic query service is		Each specification for Repute transport is independent of any other
	found in Figure 2.		specification. A diagram of the basic query service is found in
			Figure 2.
	+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . +		+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . +
	. Reputation Service .		. Reputation Service .
	. +------------+ .		. +------------+ .
	. | Reputation | .		. | Reputation | .
	. | Database | .		. | Database | .
	. +------------+ .		. +------------+ .
	. | .		. | .
	. V .		. V .
	. +-----------+ Query +----------+ .		. +-----------+ Query +----------+ .
	skipping to change at page 7, line 12 ¶		skipping to change at page 8, line 35 ¶
	UDP		UDP
	...		...
	Figure 2: Basic Reputation Query Service		Figure 2: Basic Reputation Query Service
	The precise syntaxes of both the query and response are application-		The precise syntaxes of both the query and response are application-
	specific. An application of the model defines the parameters		specific. An application of the model defines the parameters
	available to queries of that type, and also defines the data returned		available to queries of that type, and also defines the data returned
	in response to any query.		in response to any query.
	3. Terminology and Definitions		4. Terminology and Definitions
	This section defines terms used in the rest of the document.		This section defines terms used in the rest of the document.
	3.1. Response Set		4.1. Response Set
	A "Response Set" comprises those data that are returned in response		A "Response Set" comprises those data that are returned in response
	to a reputation query about a particular entity. The types of data		to a reputation query about a particular entity. The types of data
	are specific to an application; the data returned in the evaluation		are specific to an application; the data returned in the evaluation
	of email senders would be different than the reputation data returned		of email senders would be different than the reputation data returned
	about a movie or a baseball player.		about a movie or a baseball player.
	Response Sets have symbolic names, and these have to be registered		Response Sets have symbolic names, and these have to be registered
	with IANA, in the Reputation Applications Registry, to prevent name		with IANA, in the Reputation Applications Registry, to prevent name
	collisions. IANA registries are created in a separate document.		collisions. IANA registries are created in a separate document.
	Each definition of a Response Set also needs to define its registry		Each definition of a Response Set also needs to define its registry
	entry.		entry.
	3.2. Reputon		4.2. Reputon
	A "reputon" is an object that comprises the basic response to a		A "reputon" is an object that comprises the basic response to a
	reputation query. It contains the response set relevant to the		reputation query. It contains the response set relevant to the
	subject of the query. Its specific encoding is left to documents		subject of the query. Its specific encoding is left to documents
	that implement this model.		that implement this model.
	4. Information Represented in a Response Set		5. Information Represented in a Response Set
	The basic information to be represented in the protocol is fairly		The basic information to be represented in the protocol is fairly
	simple, and includes the following:		simple, and includes the following:
	o the identity of the entity providing the reputation information;		o the identity of the entity providing the reputation information;
	o the identity of the entity being rated;		o the identity of the entity being rated;
	o the application context for the query (e.g., email address		o the application context for the query (e.g., email address
	evaluation);		evaluation);
	skipping to change at page 8, line 4 ¶		skipping to change at page 9, line 25 ¶
	simple, and includes the following:		simple, and includes the following:
	o the identity of the entity providing the reputation information;		o the identity of the entity providing the reputation information;
	o the identity of the entity being rated;		o the identity of the entity being rated;
	o the application context for the query (e.g., email address		o the application context for the query (e.g., email address
	evaluation);		evaluation);
	o the overall rating score for that entity;		o the overall rating score for that entity;
	o the level of confidence in the accuracy of that rating; and		o the level of confidence in the accuracy of that rating; and
	o the number of data points underlying that score.		o the number of data points underlying that score.
	Beyond this, arbitrary amounts of additional information might be		Beyond this, arbitrary amounts of additional information might be
	provided for specific uses of the service. The entire collection is		provided for specific uses of the service. The entire collection is
	the Response Set for that application. The query/response protocol		the Response Set for that application. The query/response protocol
	defines a syntax for representing such Response Sets, but each		defines a syntax for representing such Response Sets, but each
	application defines its own Response Set. Thus, the basic information		application defines its own Response Set. Thus, the basic information
	also includes the name of the application for which the reputation		also includes the name of the application for which the reputation
	data is being expressed.		data is being expressed.
	Each application requires its own specification of the Response Set.		Each application requires its own specification of the Response Set.
	For example, a specification might be needed for a reputation		For example, a specification might be needed for a reputation
	Response Set for an "email-sending-domain"; the Response Set might		Response Set for an "email-sending-domain"; the Response Set might
	include information on how often spam was received from that domain.		include information on how often spam was received from that domain.
	Additional documents define a [MIME] type for reputation data, and		Additional documents define a [MIME] type for reputation data, and
	protocols for exchanging such data.		protocols for exchanging such data.
	5. Information Flow in the Reputation Query Protocol		6. Information Flow in the Reputation Query Protocol
	The basic Response Set could be wrapped into a new MIME media type		The basic Response Set could be wrapped into a new MIME media type
	[MIME] or a DNS RR, and transported accordingly. It also could be		[MIME] or a DNS RR, and transported accordingly. It also could be
	the integral payload of a purpose-built protocol. For a basic		the integral payload of a purpose-built protocol. For a basic
	request/response scenario, one entity (the Client) will ask a second		request/response scenario, one entity (the Client) will ask a second
	entity (the Server) for reputation data about a third entity (the		entity (the Server) for reputation data about a third entity (the
	Target), and the second entity will respond with that data.		Target), and the second entity will respond with that data.
	An application might benefit from an extremely lightweight mechanism,		An application might benefit from an extremely lightweight mechanism,
	supporting constrained queries and responses, while others might need		supporting constrained queries and responses, while others might need
	to support larger and more complex responses.		to support larger and more complex responses.
	6. IANA Considerations		7. IANA Considerations
	This document presents no actions for IANA.		This document presents no actions for IANA.
	[RFC Editor: Please remove this section prior to publication.]		[RFC Editor: Please remove this section prior to publication.]
	7. Privacy Considerations		8. Privacy Considerations
	7.1. Data In Transit		8.1. Data In Transit
	Some kinds of reputation data are sensitive, and should not be shared		Some kinds of reputation data are sensitive, and should not be shared
	publicly. For cases that have such sensitivity, it is imperative to		publicly. For cases that have such sensitivity, it is imperative to
	protect the information from unauthorized access and viewing. The		protect the information from unauthorized access and viewing. The
	model described here neither suggests nor precludes any particular		model described here neither suggests nor precludes any particular
	transport mechanism for the data. However, for the purpose of		transport mechanism for the data. However, for the purpose of
	illustration, a reputation service that operates over HTTP might		illustration, a reputation service that operates over HTTP might
	employ any of its well-known mechanisms to solve these problems,		employ any of its well-known mechanisms to solve these problems,
	which include OpenPGP [OPENPGP], Transport Layer Security [TLS], and		which include OpenPGP [OPENPGP], Transport Layer Security [TLS], and
	S/MIME [SMIME].		S/MIME [SMIME].
	7.2. Collection Of Data		8.2. Collection Of Data
	The basic notion of collection and storage of reputation data is		The basic notion of collection and storage of reputation data is
	obviously a privacy issue in that the opinions of one party about		obviously a privacy issue in that the opinions of one party about
	another are likely to be sensitive. Inadvertent or unauthorized		another are likely to be sensitive. Inadvertent or unauthorized
	exposure of those data can lead to personal or commercial damage.		exposure of those data can lead to personal or commercial damage.
	8. Security Considerations		9. Security Considerations
	This document introduces an overall protocol model, but no		This document introduces an overall protocol model, but no
	implementation details. As such, the security considerations		implementation details. As such, the security considerations
	presented here are very high-level. The detailed analyses of the		presented here are very high-level. The detailed analyses of the
	various specific components of the protocol can be found the		various specific components of the protocol can be found the
	documents that instantiate this model.		documents that instantiate this model.
	8.1. Biased Reputation Agents		9.1. Biased Reputation Agents
	As with [VBR], an agent seeking to make use of a reputation reporting		As with [VBR], an agent seeking to make use of a reputation reporting
	service is placing some trust that the service presents an unbiased		service is placing some trust that the service presents an unbiased
	"opinion" of the object about which reputation is being returned.		"opinion" of the object about which reputation is being returned.
	The result of trusting the data is, presumably, to guide action taken		The result of trusting the data is, presumably, to guide action taken
	by the reputation client. It follows, then, that bias in the		by the reputation client. It follows, then, that bias in the
	reputation service can adversely affect the client. Clients		reputation service can adversely affect the client. Clients
	therefore need to be aware of this possibility and the effect it		therefore need to be aware of this possibility and the effect it
	might have. For example, a biased system returning a reputation		might have. For example, a biased system returning a reputation
	about a DNS domain found in email messages could result in the		about a DNS domain found in email messages could result in the
	skipping to change at page 10, line 7 ¶		skipping to change at page 11, line 33 ¶
	the scope of the present document.		the scope of the present document.
	Similarly, a client placing trust in the results returned by such a		Similarly, a client placing trust in the results returned by such a
	service might suffer if the service itself is compromised, returning		service might suffer if the service itself is compromised, returning
	biased results under the control of an attacker without the knowledge		biased results under the control of an attacker without the knowledge
	of the agency providing the reputation service. This might result		of the agency providing the reputation service. This might result
	from an attack on the data being returned at the source, or from a		from an attack on the data being returned at the source, or from a
	man-in-the-middle attack. Protocols, therefore, need to be designed		man-in-the-middle attack. Protocols, therefore, need to be designed
	so as to be as resilient against such attacks as possible.		so as to be as resilient against such attacks as possible.
	8.2. Malformed Messages		9.2. Malformed Messages
	Both clients and servers of reputation systems need to be resistant		Both clients and servers of reputation systems need to be resistant
	to attacks that involve malformed messages, deliberate or otherwise.		to attacks that involve malformed messages, deliberate or otherwise.
	Malformations can be used to confound clients and servers alike in		Malformations can be used to confound clients and servers alike in
	terms of identifying the party or parties responsible for the content		terms of identifying the party or parties responsible for the content
	under evaluation. This can result in delivery of undesirable or even		under evaluation. This can result in delivery of undesirable or even
	dangerous content.		dangerous content.
	8.3. Further Discussion		9.3. Further Discussion
	Numerous other topics related to use and management of reputation		Numerous other topics related to use and management of reputation
	systems can be found in [I-D.REPUTE-CONSIDERATIONS].		systems can be found in [I-D.REPUTE-CONSIDERATIONS].
	9. Informative References		10. Informative References
	[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,		[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
	"DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,		"DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
	September 2011.		September 2011.
	[DNS] Mockapetris, P., "Domain names - implementation and		[DNS] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
			[DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
			February 2010.
	[EMAIL-ARCH]		[EMAIL-ARCH]
	Crocker, D., "Internet Mail Architecture", RFC 5598,		Crocker, D., "Internet Mail Architecture", RFC 5598,
	July 2009.		July 2009.
	[I-D.REPUTE-CONSIDERATIONS]		[I-D.REPUTE-CONSIDERATIONS]
	Kucherawy, M., "Operational Considerations Regarding		Kucherawy, M., "Operational Considerations Regarding
	Reputation Services", draft-ietf-repute-considerations		Reputation Services", draft-ietf-repute-considerations
	(work in progress), November 2012.		(work in progress), November 2012.
	[MAIL] Resnick, P., "Internet Message Format", RFC 5322,		[MAIL] Resnick, P., "Internet Message Format", RFC 5322,
	skipping to change at page 11, line 33 ¶		skipping to change at page 13, line 17 ¶
	Nathaniel Borenstein		Nathaniel Borenstein
	Mimecast		Mimecast
	203 Crescent St., Suite 303		203 Crescent St., Suite 303
	Waltham, MA 02453		Waltham, MA 02453
	USA		USA
	Phone: +1 781 996 5340		Phone: +1 781 996 5340
	Email: nsb@guppylake.com		Email: nsb@guppylake.com
	Murray S. Kucherawy		Murray S. Kucherawy
	Cloudmark		270 Upland Drive
	128 King St., 2nd Floor		San Francisco, CA 94127
	San Francisco, CA 94107
	USA		USA
	Email: superuser@gmail.com		Email: superuser@gmail.com
	Andrew Sullivan (editor)		Andrew Sullivan (editor)
	Dyn, Inc.		Dyn, Inc.
	150 Dow St.		150 Dow St.
	Manchester, NH 03101		Manchester, NH 03101
	USA		USA
End of changes. 26 change blocks.
	55 lines changed or deleted		98 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/