< draft-crocker-email-arch-08.txt		draft-crocker-email-arch-09.txt >
	SMTP D. Crocker		SMTP D. Crocker
	Internet-Draft Brandenburg InternetWorking		Internet-Draft Brandenburg InternetWorking
	Intended status: Standards Track May 20, 2007		Intended status: Standards Track May 26, 2007
	Expires: November 21, 2007		Expires: November 27, 2007
	Internet Mail Architecture		Internet Mail Architecture
	draft-crocker-email-arch-08		draft-crocker-email-arch-09
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 21, 2007.		This Internet-Draft will expire on November 27, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Over its thirty-five year history Internet Mail has undergone		Over its thirty-five year history Internet Mail has undergone
	significant changes in scale and complexity, as it has become a		significant changes in scale and complexity, as it has become a
	global infrastructure service. The first standardized architecture		global infrastructure service. The first standardized architecture
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6		1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
	2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 7		2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 7
	2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. Mail Handling Service (MHS) Actors . . . . . . . . . . . . 10		2.2. Mail Handling Service (MHS) Actors . . . . . . . . . . . . 10
	2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 13		2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 13
	3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 16		3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 16		3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 17		3.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 17
	3.3. Message Identifier . . . . . . . . . . . . . . . . . . . . 17		3.3. Message Identifier . . . . . . . . . . . . . . . . . . . . 17
	4. Services and Standards . . . . . . . . . . . . . . . . . . . . 19		4. Services and Standards . . . . . . . . . . . . . . . . . . . . 19
	4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 22		4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 23
	4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 27		4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 28
	4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 29		4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 30
	5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 32		5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	5.1. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 33		5.1. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 34
	5.2. Re-Sending . . . . . . . . . . . . . . . . . . . . . . . . 34		5.2. Re-Sending . . . . . . . . . . . . . . . . . . . . . . . . 35
	5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 36		5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 37
	5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 37		5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 38
	5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 38		5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 39
	6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 39		6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 40
	6.1. Security Considerations . . . . . . . . . . . . . . . . . 39		6.1. Security Considerations . . . . . . . . . . . . . . . . . 40
	6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 39		6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 39		7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 40
	7.2. Descriptive . . . . . . . . . . . . . . . . . . . . . . . 41		7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 42
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 43
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
	Intellectual Property and Copyright Statements . . . . . . . . . . 43		Intellectual Property and Copyright Statements . . . . . . . . . . 44
	1. Introduction		1. Introduction
	Over its thirty-five year history Internet Mail has undergone		Over its thirty-five year history Internet Mail has undergone
	significant changes in scale and complexity, as it has become a		significant changes in scale and complexity, as it has become a
	global infrastructure service. The changes have been evolutionary,		global infrastructure service. The changes have been evolutionary,
	rather than revolutionary, reflecting a strong desire to preserve its		rather than revolutionary, reflecting a strong desire to preserve its
	installed base of users and utility. Today, Internet Mail is marked		installed base of users and utility. Today, Internet Mail is marked
	by many independent operators, many different components for		by many independent operators, many different components for
	providing service to users and many other components for performing		providing service to users and many other components for performing
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	For Internet Mail the term "end-to-end" usually refers to a single		For Internet Mail the term "end-to-end" usually refers to a single
	posting and the set of deliveries directly resulting from its single		posting and the set of deliveries directly resulting from its single
	transiting of the MHS. A common exception is with group dialogue		transiting of the MHS. A common exception is with group dialogue
	that is mediated via a mailing list, so that two postings occur		that is mediated via a mailing list, so that two postings occur
	before intended recipients receive an originator's message, as		before intended recipients receive an originator's message, as
	discussed in Section 2.1.4. In fact some uses of email consider the		discussed in Section 2.1.4. In fact some uses of email consider the
	entire email service -- including Originator and Recipient -- as a		entire email service -- including Originator and Recipient -- as a
	subordinate component. For these services "end-to-end" refers to		subordinate component. For these services "end-to-end" refers to
	points outside of the email service. Examples are voicemail over		points outside of the email service. Examples are voicemail over
	email [RFC3801], EDI over email [RFC1767] and facsimile over email.		email [RFC3801], EDI over email [RFC1767] and facsimile over email
	[RFC4142]		[RFC4142].
	+--------+		+--------+
	+---------------->| User |		+---------------->| User |
	| +--------+		| +--------+
	| ^		| ^
	+--------+ | +--------+ .		+--------+ | +--------+ .
	| User +--+--------->| User | .		| User +--+--------->| User | .
	+--------+ | +--------+ .		+--------+ | +--------+ .
	. | ^ .		. | ^ .
	. | +--------+ . .		. | +--------+ . .
	. +-->| User | . .		. +-->| User | . .
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	same time.		same time.
	The end-to-end portion of the service is the email object, called a		The end-to-end portion of the service is the email object, called a
	message. Broadly the message, itself, distinguishes between control		message. Broadly the message, itself, distinguishes between control
	information for handling, versus the author's message content.		information for handling, versus the author's message content.
	A precept to the design of mail over the open Internet is permitting		A precept to the design of mail over the open Internet is permitting
	user-to-user and MTA-to-MTA interoperability to take place with no		user-to-user and MTA-to-MTA interoperability to take place with no
	prior, direct arrangement between the independent administrative		prior, direct arrangement between the independent administrative
	authorities that are responsible for handling a message. That is,		authorities that are responsible for handling a message. That is,
	all participants rely on having the core services be universally		all participants rely on the core services being universally
	supported and accessible, either directly or through gateways that		supported and accessible, either directly or through gateways that
	translate between Internet Mail standards and other email		translate between Internet Mail standards and other email
	environments. Given the importance of spontaneity and serendipity in		environments. Given the importance of spontaneity and serendipity in
	the world of human communications, this lack of prearrangement		the world of human communications, this lack of prearrangement
	between participants is a core benefit of Internet Mail and remains a		between participants is a core benefit of Internet Mail and remains a
	core requirement for it.		core requirement for it.
	Within localized networks at the edge of the public Internet, prior		Within localized networks at the edge of the public Internet, prior
	administrative arrangement often is required and can include access		administrative arrangement often is required and can include access
	control, routing constraints and lookup service configuration. In		control, routing constraints and lookup service configuration. In
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 40 ¶
	In this document, references to structured fields of a message use a		In this document, references to structured fields of a message use a
	two-part dotted notation. The first part cites the document that		two-part dotted notation. The first part cites the document that
	contains the specification for the field and the second is the name		contains the specification for the field and the second is the name
	of the field. Hence <RFC2822.From> is the From field in an email		of the field. Hence <RFC2822.From> is the From field in an email
	content header and <RFC2821.MailFrom> is the address in the SMTP		content header and <RFC2821.MailFrom> is the address in the SMTP
	"Mail From" command.		"Mail From" command.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as specified in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Discussion venue: Please direct discussion about this document		Discussion venue: Please direct discussion about this document
	to the IETF-SMTP mailing list <http://www.imc.org/ietf-smtp>.		to the IETF-SMTP mailing list <http://www.imc.org/ietf-smtp>.
	Changes: Removed "associated with" construct, relying only on		Changes: Added definition of acronyms to beginning of Services
	"set by"		and standards.
	Made identity table and discussions more consistent.
	Restricted "envelope" only to refer to SMTP information,		Restricted 'envelope' to transport level and added 'trace' for
	calling RFC2822-level fields "Trace information".		other handling information, and added 'handling' to cover both.
	Moved "Bounce" to be User Actor.		Removed construct of "associated with" to now use only "set
			by".
	Extended introduction to acronyms in Services and Standards		Cleanup to pass the 'nits' tool check.
	section.
	2. Responsible Actor Roles		2. Responsible Actor Roles
	Internet Mail is a highly distributed service, with a variety of		Internet Mail is a highly distributed service, with a variety of
	actors serving different roles. These divide into 3 basic types:		actors serving different roles. These divide into 3 basic types:
	* User		* User
	* Mail Handling Service (MHS)		* Mail Handling Service (MHS)
	skipping to change at page 8, line 4 ¶		skipping to change at page 7, line 46 ¶
	* Originators		* Originators
	* Recipients		* Recipients
	* Mediators		* Mediators
	From the User-level perspective all mail transfer activities are		From the User-level perspective all mail transfer activities are
	performed by a monolithic Mail Handling Service (MHS), even though		performed by a monolithic Mail Handling Service (MHS), even though
	the actual service can be provided by many independent organizations.		the actual service can be provided by many independent organizations.
	Users are customers of this unified service.		Users are customers of this unified service.
	The following depicts the flow of messages among Actors:		The following figure depicts the flow of messages among Actors:
	+------------+		+------------+
	| |<---------------------------+		| |<---------------------------+
	| Originator |<----------------+ |		| Originator |<----------------+ |
	| |<----+ | |		| |<----+ | |
	+-+---+----+-+ | | |		+-+---+----+-+ | | |
	| | | | | |		| | | | | |
	| | V | | |		| | V | | |
	| | +---------+-+ | |		| | +---------+-+ | |
	| | | Recipient | | |		| | | Recipient | | |
	| | +-----------+ | |		| | +-----------+ | |
	skipping to change at page 10, line 5 ¶		skipping to change at page 9, line 49 ¶
	A Mediator preserves the Originator information of the message it		A Mediator preserves the Originator information of the message it
	reformulates, but may make meaningful changes to the content. Hence		reformulates, but may make meaningful changes to the content. Hence
	the MHS sees a new message, but Users receive a message that is		the MHS sees a new message, but Users receive a message that is
	interpreted as primarily being from -- or, at least, initiated by --		interpreted as primarily being from -- or, at least, initiated by --
	the author of the original message. The role of a Mediator permits		the author of the original message. The role of a Mediator permits
	distinct, active creativity, rather than being limited to the more		distinct, active creativity, rather than being limited to the more
	constrained job of merely connecting together other participants.		constrained job of merely connecting together other participants.
	Hence it is really the Mediator that is responsible for the new		Hence it is really the Mediator that is responsible for the new
	message.		message.
	A Mediator's task can be complex and contingent, such as by modifying		A Mediator's task can be complex and contingent, such as modifying
	and adding content or regulating which users are allowed to		and adding content or regulating which users are allowed to
	participate and when. The popular example of this role is a group		participate and when. The popular example of this role is a group
	mailing list. A sequence of Mediators may even perform a series of		mailing list. A sequence of Mediators may even perform a series of
	formal steps, such as reviewing, modifying and approving a purchase		formal steps, such as reviewing, modifying and approving a purchase
	request.		request.
	Because a Mediator originates messages, it can also receive replies.		Because a Mediator originates messages, it can also receive replies.
	So a Mediator really is a full-fledged User.		So a Mediator really is a full-fledged User.
	Gateway: A Gateway is a particularly interesting form of		Gateway: A Gateway is a particularly interesting form of
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	2.2. Mail Handling Service (MHS) Actors		2.2. Mail Handling Service (MHS) Actors
	The Mail Handling Service (MHS) has the task of performing a single,		The Mail Handling Service (MHS) has the task of performing a single,
	end-to-end transfer on behalf of the Originator and reaching the		end-to-end transfer on behalf of the Originator and reaching the
	Recipient address(es) specified in the original RFC2821.RcptTo		Recipient address(es) specified in the original RFC2821.RcptTo
	commands. Mediated or protracted, iterative exchanges, such as those		commands. Mediated or protracted, iterative exchanges, such as those
	used for collaboration over time, are part of the User-level service,		used for collaboration over time, are part of the User-level service,
	and are not part of this transfer-level Handling Service.		and are not part of this transfer-level Handling Service.
	The following depicts the relationships among transfer participants		The following figure depicts the relationships among transfer
	in Internet Mail. It shows the Source as distinct from the		participants in Internet Mail. It shows the Source as distinct from
	Originator, and Dest[ination] as distinct from Recipient, although it		the Originator, and Dest[ination] as distinct from Recipient,
	is common for each pair to be the same actor. Transfers typically		although it is common for each pair to be the same actor. Transfers
	entail one or more Relays. However direct delivery from the Source		typically entail one or more Relays. However direct delivery from
	to Destination is possible. For intra-organization mail services, it		the Source to Destination is possible. For intra-organization mail
	is common to have only one Relay.		services, it is common to have only one Relay.
	+------------+ +-----------+		+------------+ +-----------+
	| Originator | +--------+ | Recipient |		| Originator | +--------+ | Recipient |
	+-----+------+ ..>| Bounce | +-----------+		+-----+------+ ..>| Bounce | +-----------+
	| . +--------+ ^		| . +--------+ ^
	| . ^ |		| . ^ |
	/+=================================================+\		/+=================================================+\
	|| | . | Mail Handling | ||		|| | . | Mail Handling | ||
	|| | . | Service (MHS) | ||		|| | . | Service (MHS) | ||
	V . | |		V . | |
	skipping to change at page 12, line 18 ¶		skipping to change at page 12, line 18 ¶
	transmission and delivery. Notably this pertains to error and		transmission and delivery. Notably this pertains to error and
	delivery notices. Hence Source is best held accountable for the		delivery notices. Hence Source is best held accountable for the
	message content, even when they did not create any or most of it.		message content, even when they did not create any or most of it.
	2.2.2. Relay		2.2.2. Relay
	A mail Relay performs email transfer-service routing and store-and-		A mail Relay performs email transfer-service routing and store-and-
	forward by (re-)transmitting the message on towards its Recipient(s).		forward by (re-)transmitting the message on towards its Recipient(s).
	A Relay can add trace information. However it does not modify		A Relay can add trace information. However it does not modify
	existing envelope information or the message content semantics. It		existing envelope information or the message content semantics. It
	can modify message content syntax, such as a change from text to		can modify message content syntax, such as a change from binary to
	binary transfer-encoding form, only as required to meet the		text transfer-encoding form, only as required to meet the
	capabilities of the next hop in the MHS.		capabilities of the next hop in the MHS.
	A set of Relays composes a Mail Handling Service (MHS) network. This		A set of Relays composes a Mail Handling Service (MHS) network. This
	is above any underlying packet-switching network that they might be		is above any underlying packet-switching network that they might be
	using and below any gateways or other user-level Mediators.		using and below any gateways or other user-level Mediators.
	In other words, interesting email scenarios can involve three		In other words, interesting email scenarios can involve three
	distinct architectural layers of store-and-forward service:		distinct architectural layers of store-and-forward service:
	* User Mediators		* User Mediators
	* MHS Relays		* MHS Relays
	* Packet Switches		* Packet Switches
	with the bottom-most usually being the Internet's IP service. The		with the bottom-most usually being the Internet's IP service. The
	most basic email scenarios involve Relays and Switches.		most basic email scenarios involve Relays and Switches.
	Aborting a message transfer results in having the Relay become an		Aborting a message transfer results in having the Relay become an
	Originator and send an error message to the Bounce address. The		Originator and sending an error message to the Bounce address. The
	potential for looping is avoided by having this message, itself,		potential for looping is avoided by having this message, itself,
	contain no Bounce address.		contain no Bounce address.
	2.2.3. Gateway		2.2.3. Gateway
	A Gateway is a hybrid form of User and Relay that interconnects		A Gateway is a hybrid form of User and Relay that interconnects
	heterogeneous mail services. Its purpose is simply to emulate a		heterogeneous mail services. Its purpose is simply to emulate a
	Relay and the closer it comes to this, the better. However it		Relay and the closer it comes to this, the better. However it
	operates at the User level, because it MUST be able to modify message		operates at the User level, because it MUST be able to modify message
	content.		content.
	Differences between mail services can be as small as minor syntax		Differences between mail services can be as small as minor syntax
	variations, but usually encompass significant, semantic distinctions.		variations, but usually encompass significant, semantic distinctions.
	One difference could have the concept of an email address be a		One difference could have the concept of an email address being a
	hierarchical, machine-specific address, versus having it be a flat,		hierarchical, machine-specific address, versus having it be a flat,
	global name space. Another difference could be between text-only		global name space. Another difference could be between text-only
	content, versus multi-media. Hence the Relay function in a Gateway		content, versus multi-media. Hence the Relay function in a Gateway
	offers significant design challenges, to make the result be as		offers significant design challenges, to make the result be as
	seamless as possible. The most significant challenge is in ensuring		seamless as possible. The most significant challenge is in ensuring
	the user-to-user functionality that matches syntax and semantics of		the user-to-user functionality that matches syntax and semantics of
	independent email standards suites.		independent email standards suites.
	The basic test of a Gateway's adequacy is, of course, whether an		The basic test of a Gateway's adequacy is, of course, whether an
	Originator on one side of a Gateway can send a useful message to a		Originator on one side of a Gateway can send a useful message to a
	skipping to change at page 17, line 37 ¶		skipping to change at page 17, line 37 ¶
	of the sequence. Domain names are defined and operated through the		of the sequence. Domain names are defined and operated through the
	Domain Name Service (DNS) [RFC1034], [RFC1035], [RFC2181].		Domain Name Service (DNS) [RFC1034], [RFC1035], [RFC2181].
	When not part of a mailbox address, a domain name is used in Internet		When not part of a mailbox address, a domain name is used in Internet
	Mail to refer to the ADMD or the host that took action upon the		Mail to refer to the ADMD or the host that took action upon the
	message, such as providing the administrative scope for a message		message, such as providing the administrative scope for a message
	identifier, or performing transfer processing.		identifier, or performing transfer processing.
	3.3. Message Identifier		3.3. Message Identifier
	There are two standardized tags, for identifying messages: Message-ID		There are two standardized tags for identifying messages: Message-ID
	and ENVID.		and ENVID.
	3.3.1. Message-ID		3.3.1. Message-ID
	The Message-ID is a user-level tag, primarily used for threading and		The Message-ID is a user-level tag, primarily used for threading and
	for eliminating duplicates. [RFC2822]. Any actor within the		for eliminating duplicates [RFC2822]. Any actor within the
	originating ADMD might assign the Message-ID, although it is		originating ADMD might assign the Message-ID, although it is
	typically created by an actor within the Originating ADMD.. The		typically created by an actor within the Originating ADMD.. The
	recipient's ADMD is the intended consumer of the Message-ID, although		recipient's ADMD is the intended consumer of the Message-ID, although
	any actor along the transfer path might use it. Internet Mail		any actor along the transfer path might use it. Internet Mail
	standards provide for a single Message-ID; however more than one is		standards provide for a single Message-ID; however more than one is
	sometimes assigned.		sometimes assigned.
	Like a mailbox address, a Message-ID has two distinct parts, divided		Like a mailbox address, a Message-ID has two distinct parts, divided
	by an at-sign ("@"). The right-hand side is globally interpreted and		by an at-sign ("@"). The right-hand side is globally interpreted and
	specifies the ADMD or host assigning the identifier. The left-hand		specifies the ADMD or host assigning the identifier. The left-hand
	skipping to change at page 19, line 13 ¶		skipping to change at page 19, line 13 ¶
	assessment that is marginally better than a heuristic, but the ID		assessment that is marginally better than a heuristic, but the ID
	certainly has no value on its own for strict formal reference or		certainly has no value on its own for strict formal reference or
	comparison. Hence it is not appropriate to use the Message-ID for		comparison. Hence it is not appropriate to use the Message-ID for
	any process that might be called "security".		any process that might be called "security".
	3.3.2. ENVID		3.3.2. ENVID
	The ENVID (envelope identifier) is a tag that is primarily for use		The ENVID (envelope identifier) is a tag that is primarily for use
	within Delivery Status Notifications (DSN), so that the Bounce		within Delivery Status Notifications (DSN), so that the Bounce
	Address (RFC2821.MailFrom) recipient can correlate the DSN with a		Address (RFC2821.MailFrom) recipient can correlate the DSN with a
	particular message. [RFC3461] The ENVID is therefore used from one		particular message [RFC3461]. The ENVID is therefore used from one
	message posting, until the directly-resulting message deliveries. It		message posting, until the directly-resulting message deliveries. It
	does not survive re-postings.		does not survive re-postings.
			The ENVID may also be used for message tracking purposes [RFC3885].
	The format of an ENVID is free-form. Although its creator might		The format of an ENVID is free-form. Although its creator might
	choose to impose structure on the string, none is imposed by Internet		choose to impose structure on the string, none is imposed by Internet
	standards. By implication, the scope of the string is defined by the		standards. By implication, the scope of the string is defined by the
	domain name of the Bounce Address.		domain name of the Bounce Address.
	4. Services and Standards		4. Services and Standards
	Internet Mail's architecture distinguishes among six basic types of		Internet Mail's architecture distinguishes among six basic types of
	functional components, arranged to support a store-and-forward		functional components, arranged to support a store-and-forward
	service architecture. As shown in Figure 5 these types can have		service architecture. As shown in Figure 5 these types can have
	skipping to change at page 22, line 8 ¶		skipping to change at page 23, line 8 ¶
	. +->| |<------+ | |		. +->| |<------+ | |
	...........>| rMUA +---------------------------+ |		...........>| rMUA +---------------------------+ |
	| +-----------------------------------+		| +-----------------------------------+
	+------+		+------+
	Figure 5: Protocols and Services		Figure 5: Protocols and Services
	4.1. Message Data		4.1. Message Data
	The purpose of the Mail Handling Service (MHS) is to exchange a		The purpose of the Mail Handling Service (MHS) is to exchange a
	message object among participants. , [RFC2822] [RFC0822] Hence all of		message object among participants [RFC2822], [RFC0822]. Hence all of
	its underlying mechanisms are merely in the service of getting that		its underlying mechanisms are merely in the service of getting that
	message from its Originator to its Recipients. A message can be		message from its Originator to its Recipients. A message can be
	explicitly labeled as to its nature. [RFC3458]		explicitly labeled as to its nature [RFC3458].
	A message comprises a transit handling envelope and the message		A message comprises a transit handling envelope and the message
	content. The envelope contains information used by the MHS. The		content. The envelope contains information used by the MHS. The
	content is divided into a structured header and the body. The header		content is divided into a structured header and the body. The header
	comprises transit trace information and end-user structured fields.		comprises transit trace information and end-user structured fields.
	The body may be unstructured simple lines of text, or it may be a		The body may be unstructured simple lines of text, or it may be a
	MIME tree of multi-media subordinate objects, called body-parts, or		MIME tree of multi-media subordinate objects, called body-parts, or
	attachments. [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289],		attachments [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289],
	[RFC2049].		[RFC2049].
	In addition, Internet Mail has a few conventions for special control		In addition, Internet Mail has a few conventions for special control
	data --		data --
	Delivery Status Notification (DSN):		Delivery Status Notification (DSN):
	A Delivery Status Notification (DSN) is a message that can be		A Delivery Status Notification (DSN) is a message that can be
	generated by the MHS (MSA, MTA or MDA) and sent to the		generated by the MHS (MSA, MTA or MDA) and sent to the
	RFC2821.MailFrom address. The mailbox for this is shown as		RFC2821.MailFrom address. The mailbox for this is shown as
	Bounces in Figure 5. DSNs provide information about message		Bounces in Figure 5. DSNs provide information about message
	transit, such as transmission errors or successful delivery.		transit, such as transmission errors or successful delivery
	[RFC3461]		[RFC3461].
	Message Disposition Notification (MDN):		Message Disposition Notification (MDN):
	A Message Disposition Notification (MDN) is a message that		A Message Disposition Notification (MDN) is a message that
	provides information about user-level, Recipient-side message		provides information about user-level, Recipient-side message
	processing, such as indicating that the message has been		processing, such as indicating that the message has been
	displayed [RFC3798] or the form of content that can be		displayed [RFC3798] or the form of content that can be
	supported. [RFC3297] It can be generated by an rMUA and is		supported [RFC3297]. It can be generated by an rMUA and is
	sent to the Disposition-Notification-To address(es). The		sent to the Disposition-Notification-To address(es). The
	mailbox for this is shown as Disp in Figure 5.		mailbox for this is shown as Disp in Figure 5.
	Message Filtering (SIEVE):		Message Filtering (SIEVE):
	SIEVE is a scripting language that permits specifying		SIEVE is a scripting language that permits specifying
	conditions for differential handling of mail, typically at the		conditions for differential handling of mail, typically at the
	time of delivery. [RFC3028] It can be conveyed in a variety of		time of delivery [RFC3028]. It can be conveyed in a variety of
	ways, as a MIME part. Figure 5 shows a Sieve specification		ways, as a MIME part. Figure 5 shows a Sieve specification
	going from the rMUA to the MDA. However filtering can be done		going from the rMUA to the MDA. However filtering can be done
	at many different points along the transit path and any one or		at many different points along the transit path and any one or
	more of them might be subject to Sieve directives, especially		more of them might be subject to Sieve directives, especially
	within a single ADMD. Hence the Figure shows only one		within a single ADMD. Hence the Figure shows only one
	relationship, for (relative) simplicity.		relationship, for (relative) simplicity.
	4.1.1. Envelope		4.1.1. Envelope
	Internet Mail has a fragmented framework for transit-related		Internet Mail has a fragmented framework for transit-related
	"handling" information. Information that is directly used by the MHS		"handling" information. Information that is directly used by the MHS
	is called the "envelope". It directs handling activities by the		is called the "envelope". It directs handling activities by the
	transfer service as is carried in transfer service commands. That		transfer service as is carried in transfer service commands. That
	is, The envelope exists in the transfer protocol SMTP [RFC2821].		is, the envelope exists in the transfer protocol SMTP [RFC2821].
	Trace information records handling activity and is recorded in the		Trace information records handling activity and is recorded in the
	message Header.		message Header.
	4.1.2. Header Fields		4.1.2. Header Fields
	Header fields are attribute name/value pairs covering an extensible		Header fields are attribute name/value pairs covering an extensible
	range of email service, user content and user transaction meta-		range of email service, user content and user transaction meta-
	information. The core set of header fields is defined in [RFC2822],		information. The core set of header fields is defined in [RFC2822],
	[RFC0822]. It is common to extend this set, for different		[RFC0822]. It is common to extend this set, for different
	skipping to change at page 23, line 43 ¶		skipping to change at page 24, line 43 ¶
	in [RFC4021]. An extensive set of existing header field		in [RFC4021]. An extensive set of existing header field
	registrations is provided in [RFC3864].		registrations is provided in [RFC3864].
	One danger with placing additional information in header fields is		One danger with placing additional information in header fields is
	that Gateways often alter or delete them.		that Gateways often alter or delete them.
	4.1.3. Body		4.1.3. Body
	The body of a message might simply be lines of ASCII text or it might		The body of a message might simply be lines of ASCII text or it might
	be hierarchically structured into a composition of multi-media body-		be hierarchically structured into a composition of multi-media body-
	part attachments, using MIME. [RFC2045], [RFC2046], [RFC2047],		part attachments, using MIME [RFC2045], [RFC2046], [RFC2047],
	[RFC4288], [RFC2049] MIME structures each body-part into a recursive		[RFC4288], [RFC2049]. MIME structures each body-part into a
	set of MIME header field meta-data and MIME Content sections.		recursive set of MIME header field meta-data and MIME Content
			sections.
	4.1.4. Identity References in a Message		4.1.4. Identity References in a Message
	For a message in transit, the core uses of identifiers combine into:		For a message in transit, the core uses of identifiers combine into:
	+-----------------------+----------------+---------------------+		+-----------------------+----------------+---------------------+
	| Layer | Field | Set By |		| Layer | Field | Set By |
	+-----------------------+----------------+---------------------+		+-----------------------+----------------+---------------------+
	| Message Body | MIME Header | Originator |		| Message Body | MIME Header | Originator |
	| Message header fields | From | Originator |		| Message header fields | From | Originator |
	| | Sender | Source |		| | Sender | Source |
	| | Reply-To | Originator |		| | Reply-To | Originator |
	| | To, CC, BCC | Originator |		| | To, CC, BCC | Originator |
	| | Message-ID | Source |		| | Message-ID | Source |
	| | Received | Source, Relay, Dest |		| | Received | Source, Relay, Dest |
	| | Return-Path | MDA, from MailFrom |		| | Return-Path | MDA, from MailFrom |
	| | Resent-* | Mediator |		| | Resent-* | Mediator |
	| SMTP | HELO | Latest Relay Client |		| | List-Id | Mediator Originator |
			| | List-* | Mediator Originator |
			| SMTP | HELO/EHLO | Latest Relay Client |
	| | ENVID | Source |		| | ENVID | Source |
	| | MailFrom | Source |		| | MailFrom | Source |
	| | RcptTo | Originator |		| | RcptTo | Originator |
	| IP | Source Address | Latest Relay Client |		| IP | Source Address | Latest Relay Client |
	+-----------------------+----------------+---------------------+		+-----------------------+----------------+---------------------+
	Layered Identities		Layered Identities
	The most common address-related fields are:		The most common address-related fields are:
	skipping to change at page 25, line 47 ¶		skipping to change at page 26, line 47 ¶
	RFC2821.HELO/.EHLO Set by: Source		RFC2821.HELO/.EHLO Set by: Source
	The MSA can specify its hosting domain identity for the SMTP HELO		The MSA can specify its hosting domain identity for the SMTP HELO
	or EHLO command operation.		or EHLO command operation.
	RFC3461.ENVID Set by: Source		RFC3461.ENVID Set by: Source
	The MSA can specify an opaque string, to be included in a DSN, as		The MSA can specify an opaque string, to be included in a DSN, as
	a means of assisting the Bounce address recipient in identifying		a means of assisting the Bounce address recipient in identifying
	the message that produced a DSN.		the message that produced a DSN, or message tracking.
	RFC2821.MailFrom Set by: Source		RFC2821.MailFrom Set by: Source
	This is an end-to-end string that specifies an email address for		This is an end-to-end string that specifies an email address for
	receiving return control information, such as "bounces". The name		receiving return control information, such as "bounces". The name
	of this field is misleading, because it is not required to specify		of this field is misleading, because it is not required to specify
	either the author or the agent responsible for submitting the		either the author or the agent responsible for submitting the
	message. Rather, the agent responsible for submission specifies		message. Rather, the agent responsible for submission specifies
	the RFC2821.MailFrom address. Ultimately the simple basis for		the RFC2821.MailFrom address. Ultimately the simple basis for
	deciding what address needs to be in the RFC2821.MailFrom is to		deciding what address needs to be in the RFC2821.MailFrom is to
	determine what address needs to be informed about transmission-		determine what address needs to be informed about transmission-
	skipping to change at page 26, line 47 ¶		skipping to change at page 27, line 47 ¶
	The identifier is in the form of a domain name; however the string		The identifier is in the form of a domain name; however the string
	usually is constructed by combining the two parts of an email		usually is constructed by combining the two parts of an email
	address and the result rarely is a true domain name, listed in the		address and the result rarely is a true domain name, listed in the
	domain name service -- although it can be.		domain name service -- although it can be.
	RFC2369.List-* Set by: Mediator Originator		RFC2369.List-* Set by: Mediator Originator
	[RFC2369] defines a collection of message header fields for use by		[RFC2369] defines a collection of message header fields for use by
	mailing lists. In effect they supply list-specific parameters for		mailing lists. In effect they supply list-specific parameters for
	common mailing list user operations. The identifiers for these		common mailing list user operations. The identifiers for these
	operations are for the list, itself, and the user-as-subscriber.		operations are for the list, itself, and the user-as-subscriber
	[RFC2369]		[RFC2369].
	RFC0791.SourceAddr Set by: The Client SMTP sending host immediately		RFC0791.SourceAddr Set by: The Client SMTP sending host immediately
	preceding the current receiving SMTP server.		preceding the current receiving SMTP server.
	[RFC0791] defines the basic unit of data transfer for the		[RFC0791] defines the basic unit of data transfer for the
	Internet, the IP Datagram. It contains a "Source Address" field		Internet, the IP Datagram. It contains a "Source Address" field
	that specifies the IP Address for the host (interface) from which		that specifies the IP Address for the host (interface) from which
	the datagram was sent. This information is set and provided by		the datagram was sent. This information is set and provided by
	the IP layer, and is therefore independent of mail-level		the IP layer, and is therefore independent of mail-level
	mechanisms. As such, it is often taken to be authoritative,		mechanisms. As such, it is often taken to be authoritative,
	skipping to change at page 36, line 22 ¶		skipping to change at page 37, line 22 ¶
	Received header field, to indicate the transition from original		Received header field, to indicate the transition from original
	posting to resubmission.		posting to resubmission.
	5.3. Mailing Lists		5.3. Mailing Lists
	Mailing lists have explicit email addresses and they re-post messages		Mailing lists have explicit email addresses and they re-post messages
	to a list of subscribed members. The Mailing List Actor performs a		to a list of subscribed members. The Mailing List Actor performs a
	task that can be viewed as an elaboration of the Re-Director role.		task that can be viewed as an elaboration of the Re-Director role.
	In addition to sending the new message to a potentially large number		In addition to sending the new message to a potentially large number
	of new Recipients, the Mediator can modify content, such as deleting		of new Recipients, the Mediator can modify content, such as deleting
	attachments, formatting conversion, and adding list-specific		attachments, converting the format, and adding list-specific
	comments. In addition, archiving list messages is common. Still the		comments. In addition, archiving list messages is common. Still the
	message retains characteristics of being "from" the original		message retains characteristics of being "from" the original
	Originator.		Originator.
	Identities relevant to a mailing list processor, when submitting a		Identities relevant to a mailing list processor, when submitting a
	message, include:		message, include:
	RFC2919.List-Id Set by: Mediator Originator		RFC2919.List-Id Set by: Mediator Originator
	RFC2369.List-* Set by: Mediator Originator		RFC2369.List-* Set by: Mediator Originator
	skipping to change at page 38, line 36 ¶		skipping to change at page 39, line 36 ¶
	These usually retain their original addresses.		These usually retain their original addresses.
	RFC2821.MailFrom Set by: Originator Source or Mediator Source		RFC2821.MailFrom Set by: Originator Source or Mediator Source
	The agent responsible for gatewaying the message can choose to		The agent responsible for gatewaying the message can choose to
	specify a new address to receive handling notices.		specify a new address to receive handling notices.
	RFC2822.Received Set by: Mediator Dest		RFC2822.Received Set by: Mediator Dest
	The Gateway can record a Received header field, to indicate the		The Gateway can record a Received header field, to indicate the
	transition from original posting to the new messaging		transition from the original posting environment to the new
	environment.		messaging environment.
	5.5. Boundary Filter		5.5. Boundary Filter
	Organizations often enforce security boundaries by subjecting		Organizations often enforce security boundaries by subjecting
	messages to analysis, for conformance with the organization's safety		messages to analysis, for conformance with the organization's safety
	policies. An example is detection of content classed as spam or a		policies. An example is detection of content classed as spam or a
	virus. A Filter might alter the content, to render it safe, such as		virus. A Filter might alter the content, to render it safe, such as
	by removing content deemed unacceptable. Typically these actions		by removing content deemed unacceptable. Typically these actions
	will result in the addition of content that records the actions.		will result in the addition of content that records the actions.
	skipping to change at page 39, line 31 ¶		skipping to change at page 40, line 31 ¶
	6.2. IANA Considerations		6.2. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7. References		7. References
	7.1. Normative		7.1. Normative
	[RFC0791] Postel, J., "Internet Protocol", 1981 September.		[RFC0791] Postel, J., "Internet Protocol", 1981 September.
	[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
	RFC 821, August 1982.
	[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
	text messages", STD 11, RFC 822, August 1982.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",		[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
	STD 53, RFC 1939, May 1996.		STD 53, RFC 1939, May 1996.
	[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
	October 1996.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, November 1996.		Bodies", RFC 2045, November 1996.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)		[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
	Part Three: Message Header Extensions for Non-ASCII Text",		Part Three: Message Header Extensions for Non-ASCII Text",
	skipping to change at page 40, line 27 ¶		skipping to change at page 41, line 19 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	Specification", RFC 2181, July 1997.		Specification", RFC 2181, July 1997.
	[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax		[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
	for Core Mail List Commands and their Transport through		for Core Mail List Commands and their Transport through
	Message Header Fields", RFC 2369, July 1998.		Message Header Fields", RFC 2369, July 1998.
	[RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998.
	[RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP		[RFC2645] "On-Demand Mail Relay (ODMR) SMTP with Dynamic IP
	Addresses", RFC 2645, August 1999.		Addresses", RFC 2645, August 1999.
	[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,		[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
	April 2001.		April 2001.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,		[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.		April 2001.
	[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field		[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
	skipping to change at page 41, line 38 ¶		skipping to change at page 42, line 28 ¶
	Internet Mail Extensions (MIME) Part Four: Registration		Internet Mail Extensions (MIME) Part Four: Registration
	Procedures", BCP 13, RFC 4289, December 2005.		Procedures", BCP 13, RFC 4289, December 2005.
	[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",		[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
	RFC 4409, April 2006.		RFC 4409, April 2006.
	[RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support		[RFC4550] Maes, S., , S., and Isode Ltd., "Internet Email to Support
	Diverse Service Environments (Lemonade) Profile",		Diverse Service Environments (Lemonade) Profile",
	June 2006.		June 2006.
	7.2. Descriptive		7.2. Informative
	[ID-spamops]		[ID-spamops]
	Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and		Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and
	E. Allman, "Email Submission Between Independent		E. Allman, "Email Submission Between Independent
	Networks", draft-spamops-00 (work in progress),		Networks", draft-hutzler-spamops-06 (work in progress),
	March 2004.		May 2007.
			[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
			RFC 821, August 1982.
			[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
			text messages", STD 11, RFC 822, August 1982.
	[RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4",		[RFC1733] Crispin, M., "Distributed Electronic Models in IMAP4",
	December 1994.		December 1994.
	[RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects",		[RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects",
	RFC 1767, March 1995.		RFC 1767, March 1995.
			[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
			October 1996.
			[RFC2442] "The Batch SMTP Media Type", RFC 2442, November 1998.
	[RFC3801] Vaudreuil, G. and G. Parsons, "", RFC 3801, June 2004.		[RFC3801] Vaudreuil, G. and G. Parsons, "", RFC 3801, June 2004.
			[RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for
			Message Tracking", RFC 3885, September 2004.
	[RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for		[RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for
	Internet Mail: FFPIM", December 2005.		Internet Mail: FFPIM", December 2005.
	[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden,		[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden,
	"Tussle in Cyberspace: Defining Tomorrow's Internet",		"Tussle in Cyberspace: Defining Tomorrow's Internet",
	ACM SIGCOMM, 2002.		ACM SIGCOMM, 2002.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This work derives from a section in draft-hutzler-spamops.		This work derives from a section in draft-hutzler-spamops
	[ID-spamops] Discussion of the Source actor role was greatly		[ID-spamops]. Discussion of the Source actor role was greatly
	clarified during discussions in the IETF's Marid working group.		clarified during discussions in the IETF's Marid working group.
	Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful		Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful
	insight on the framework and details of the original drafts.		insight on the framework and details of the original drafts.
	Later reviews and suggestions were provided by Eric Allman, Nathaniel		Later reviews and suggestions were provided by Eric Allman, Nathaniel
	Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Willemien		Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch,
	Hoogendoorn, Tony Finch, Ned Freed, Eric Hall, Brad Knowles, John		Ned Freed, Eric Hall, Tony Hansen, Willemien Hoogendoorn, Brad
	Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg,		Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David
	Alexey Melnikov, der Mouse, S. Moonesamy, Chris Newman, Daryl Odnert,		MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Chris Newman,
	Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf,		Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos,
	Greg Vaudreuil.		Jochen Topf, Greg Vaudreuil.
	Diligent proof-reading was performed by Bruce Lilly.		Diligent proof-reading was performed by Bruce Lilly.
	Author's Address		Author's Address
	Dave Crocker		Dave Crocker
	Brandenburg InternetWorking		Brandenburg InternetWorking
	675 Spruce Drive		675 Spruce Drive
	Sunnyvale, CA 94086		Sunnyvale, CA 94086
	USA		USA
End of changes. 44 change blocks.
	91 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/