< draft-crocker-email-arch-00.txt		draft-crocker-email-arch-01.txt >
	MARID / SMTP D. Crocker		MARID / SMTP D. Crocker
	Internet-Draft Brandenburg InternetWorking		Internet-Draft Brandenburg InternetWorking
	Expires: November 7, 2004 May 09, 2004		Expires: January 1, 2005 July 3, 2004
	Internet Mail Architecture		Internet Mail Architecture
	draft-crocker-email-arch-00		draft-crocker-email-arch-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	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
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	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."
	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 7, 2004.		This Internet-Draft will expire on January 1, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	Over its thirty year history, Internet mail has undergone significant		Over its thirty year history, Internet mail has undergone significant
	changes in scale and complexity. The first standardized architecture		changes in scale and complexity. The first standardized architecture
	for email specified a simple split between the user world and the		for email specified a simple split between the user world and the
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 8 ¶
	Transfer Agents (MTA). Over time each of these has divided into		Transfer Agents (MTA). Over time each of these has divided into
	multiple, specialized modules. Public discussion and agreement about		multiple, specialized modules. Public discussion and agreement about
	the nature of the changes to Internet mail has not kept pace, and		the nature of the changes to Internet mail has not kept pace, and
	abuses of the Internet mail service have brought these issues into		abuses of the Internet mail service have brought these issues into
	stark relief. This draft offers clarifications and enhancements, to		stark relief. This draft offers clarifications and enhancements, to
	provide a more consistent base for community discussion of email		provide a more consistent base for community discussion of email
	service problems and proposed email service enhancements.		service problems and proposed email service enhancements.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Service Overview . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Service Overview . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2 Discussion venue . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Document Changes . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Email Identities . . . . . . . . . . . . . . . . . . . . . . 5		1.3 Discussion venue . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1 Mailbox Addresses . . . . . . . . . . . . . . . . . . . . . 5		2. Email Actor Roles . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.1 Global Standards for Local-Part . . . . . . . . . . . . . . 5		2.1 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.2 Scope of Email Address Use . . . . . . . . . . . . . . . . . 5		2.2 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.2 Domain Names . . . . . . . . . . . . . . . . . . . . . . . . 6		2.3 Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.3 Identity Reference Convention . . . . . . . . . . . . . . . 6		3. Email Identities . . . . . . . . . . . . . . . . . . . . . . . 8
	3. Email System Architecture . . . . . . . . . . . . . . . . . 6		3.1 Mailbox Addresses . . . . . . . . . . . . . . . . . . . . . . 8
	3.1 Architectural Components . . . . . . . . . . . . . . . . . . 7		3.2 Domain Names . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1.1 Mail User Agent (MUA) . . . . . . . . . . . . . . . . . . . 7		3.3 Message Identifers . . . . . . . . . . . . . . . . . . . . . . 10
	3.1.2 Mail Submission Agent (MSA) . . . . . . . . . . . . . . . . 9		3.4 Identity Reference Convention . . . . . . . . . . . . . . . . 10
	3.1.3 Mail Transfer Agent (MTA) . . . . . . . . . . . . . . . . . 11		4. Email System Architecture . . . . . . . . . . . . . . . . . . 10
	3.1.4 Mail Delivery Agent (MDA) . . . . . . . . . . . . . . . . . 11		4.1 Architectural Components . . . . . . . . . . . . . . . . . . . 11
	3.2 Operational Configuration . . . . . . . . . . . . . . . . . 12		4.2 Operational Configuration . . . . . . . . . . . . . . . . . . 19
	3.3 Layers of Identity References . . . . . . . . . . . . . . . 13		4.3 Layers of Identity References . . . . . . . . . . . . . . . . 20
	4. Message Data . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Message Data . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.1 Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.1 Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.2 Message Headers . . . . . . . . . . . . . . . . . . . . . . 13		5.2 Message Headers . . . . . . . . . . . . . . . . . . . . . . . 21
	4.3 Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5.3 Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	5. Two Levels of Store-And-Forward . . . . . . . . . . . . . . 14		6. Two Levels of Store-And-Forward . . . . . . . . . . . . . . . 21
	5.1 MTA Relaying . . . . . . . . . . . . . . . . . . . . . . . . 14		6.1 MTA Relaying . . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.2 MUA Forwarding . . . . . . . . . . . . . . . . . . . . . . . 14		6.2 MUA Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 22
	5.2.1 MUA Basic Forwarding . . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	5.2.2 MUA Re-Sending . . . . . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	5.2.3 MUA Reply . . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 34
	5.2.4 MUA Gateways . . . . . . . . . . . . . . . . . . . . . . . . 17		A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
	5.2.5 MUA Alias Handling . . . . . . . . . . . . . . . . . . . . . 18		Intellectual Property and Copyright Statements . . . . . . . . 35
	5.2.6 MUA Mailing Lists . . . . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . 21
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . 23
	A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . 24
	1. Introduction		1. Introduction
	Over its thirty year history, Internet mail has undergone significant		Over its thirty year history, Internet mail has undergone significant
	changes in scale and complexity. The first standardized architecture		changes in scale and complexity. The first standardized architecture
	for email specified a simple split between the user world and the		for email specified a simple split between the user world and the
	transmission world, in the form of Mail User Agents (MUA) and Mail		transmission world, in the form of Mail User Agents (MUA) and Mail
	Transfer Agents (MTA). Over time each of these has sub-divided into		Transfer Agents (MTA). Over time each of these has sub-divided into
	more specialized modules.		more specialized modules.
	The basic style and use of names, addresses and message structure		The basic style and use of names, addresses and message structure
	have remained remarkably constant. However each has benefited from		have remained remarkably constant. However each has benefited from
	significant elaborations. Public discussion and agreement about the		significant elaborations. Public discussion and agreement about the
	nature of these changes has not kept pace, and abuses of the Internet		nature of these changes has not kept pace, and abuses of the Internet
	mail service have brought these issues into stark relief.		mail service have brought these issues into stark relief.
	The current draft seeks to:		The current draft seeks to:
	1. document changes that have taken place in refining the email		1. Document changes that have taken place in refining the email
	model		model
	2. clarify functional roles for the architectural components		2. Clarify functional roles for the architectural components
	3. clarify identity-related issues, across the email service		3. Clarify identity-related issues, across the email service
	4. provide a common venue for further defining and citing modern		4. Provide a common venue for further defining and citing modern
	Internet mail architecture		Internet mail architecture
	1.1 Service Overview		1.1 Service Overview
	End-to-end Internet mail exchange is accomplished by using a		End-to-end Internet mail exchange is accomplished by using a
	standardized infrastructure comprising:		standardized infrastructure comprising:
	1. an email object		1. An email object
	2. global addressing		2. Global addressing
	3. a connected sequence of point-to-point transfer mechanisms		3. A connected sequence of point-to-point transfer mechanisms
	4. no prior arrangement between originator and recipient		4. No prior arrangement between originator and recipient
	5. no prior arrangement between point-to-point transfer services,		5. No prior arrangement between point-to-point transfer services,
	over the open Internet		over the open Internet
	The end-to-end portion of the service is the message. Broadly the		The end-to-end portion of the service is the message. Broadly the
	message, itself, is divided between handling control information and		message, itself, is divided between handling control information and
	user message payload.		user message payload.
	A precept to the design of Internet mail is to permit		A precept to the design of Internet mail is to permit
	interoperability with no prior, direct administrative arrangement		interoperability with no prior, direct administrative arrangement
	between the participants. That is, all participants rely on having		between the participants. That is, all participants rely on having
	the core services be universally supported, either directly or		the core services be universally supported, either directly or
	through gateways that translate between Internet mail standards and		through gateways that translate between Internet mail standards and
	other email conventions.		other email conventions.
	For localized environments (edge networks) prior, administrative		For localized environments (edge networks) prior, administrative
	arrangement can include access control, routing and lookup service		arrangement can include access control, routing and lookup service
	configuration. One change to local environments, occurring in recent		configuration. In recent years one change to local environments is
	years, is an increased requirement for authentication or, at least,		an increased requirement for authentication or, at least,
	accountability. In these cases, the server performs explicit		accountability. In these cases, the server performs explicit
	validation of the client's identity.		validation of the client's identity.
	1.2 Discussion venue		1.2 Document Changes
			The major changes from the previous version of this document are:
			Actors: Addition of the User/Relay/Provider construct of actors.
			Labeling of these roles has also been added to the tables showing
			architectural function. The distinction of Actors, versus
			architectural system components, is not typical for discussions of
			email. Therefore it is likely that the construct needs
			refinement. In particular, please review the table assignments.
			MDA/MS/MUA: The construct of the Message Store has been added. This
			change is intended to reflect the consensus view from online
			discussion, rather than being the editor's view, which has in any
			event changed... However it is likely that it will need
			significant revision or replacement. Please review it carefully!
			Message Identifiers: Discussion of message identifiers has been added
			to the section on Email Identities.
			1.3 Discussion venue
	NOTE: This document is the work of a single person, about a topic		NOTE: This document is the work of a single person, about a topic
	with considerable diversity of views. It is certain to be		with considerable diversity of views. It is certain to be
	incomplete and inaccurate. Some errors simply need to be		incomplete and inaccurate. Some errors simply need to be
	reported; they will get fixed. Others need to be discussed by the		reported; they will get fixed. Others need to be discussed by the
	community, because the real requirement is to develop common		community, because the real requirement is to develop common
	community views. To this end, please treat the draft as a		community views. To this end, please treat the draft as a
	touchstone for public discussion.		touchstone for public discussion.
	Discussion about this document should be directed to the:		Discussion about this document should be directed to the:
	<mailto:ietf-smtp@imc.org>		<mailto:ietf-smtp@imc.org>
			mailing list. The <http://www.imc.org/ietf-smtp/index.htm> is the
	mailing list. Located at <http://www.imc.org/ietf-smtp/index.html>		most active, long-standing venue for discussing email architecture.
	the ietf-smtp mailing list is the most active, long-standing venue		Although this list is primarily for discussing only the SMTP
	for discussing email architecture. Although this list is primarily		protocol, it is recommended that discussion of this draft take place
	for discussing only the SMTP protocol, it is recommended that		on that mailing list. This list tends to attend to end-to-end
	discussion of this draft take place on that mailing list. This list		infrastructure and architecture issues more than other email-related
	tends to attend to end-to-end infrastructure and architecture issues		mailing lists.
	more than other email-related mailing lists.
	o The <mailto:ietf-822@imc.org> list also is pertinent		o The <mailto:ietf-822@imc.org> list also is pertinent
	<http://www.imc.org/ietf-smtp/index.html>. However it's focus is		<http://www.imc.org/ietf-822/index.html>. However it's focus is
	on the message, itself, so that transfer issues are typically		on the message, itself, so that transfer issues are typically
	excluded. In addition, this list has not be very active recently.		excluded. In addition, this list has not be very active recently.
	o A currently active mailing list, likely to impact Internet mail		o A currently active mailing list, likely to impact Internet mail
	architecture, is <mailto:ietf-mxcomp@imc.org>. This list is		architecture, is <mailto:ietf-mxcomp@imc.org>. This list is
	devoted to matters of spam control, so that underlying matters of		devoted to matters of spam control, so that underlying matters of
	Internet mail architecture are probably best deferred to a more		Internet mail architecture are probably best deferred to a more
	general list, such as ietf-smtp.		general list, such as ietf-smtp.
	o Also currently active is the <mailto:lemonade@ietf.org>, which is		o Also currently active is the <mailto:lemonade@ietf.org>, which is
	considering enhancements for interaction between thin MUAs and		considering enhancements for interaction between thin MUAs and
	MSAs.		MSAs.
	2. Email Identities		2. Email Actor Roles
			Discussion of email architecture requires distinguishing different
			actors within the service, and being clear about the job each
			performs in the overall handling of mail. For this level of
			discussion "the service" has the task of performing a single,
			end-to-end transfer. Protracted, iterative exchanges, such as those
			used for collaboration over time, are beyond the scope of (this
			version of) this document. Actors often will be associated with
			entirely independent organizations from other actors participating in
			an end-to-end email transfer.
			The following depicts the relationships among participants in
			Internet Mail. Although related to a technical architecture, its
			focus is on participant responsibilities, rather than functional
			modules. Hence the labels used are different than for classic email
			architecture. This figure depicts the relationships among the
			actors. It shows the Submitter as distinct from the Originator,
			although it is common for them to be the same actor. The figure also
			shows multiple Relays in the sequence. It is legal to have only one,
			and for intra-organization mail services, this is common.
			User (Originator, Author)
			| -+
			Submitter | Provider
			| -+
			| -+
			Relay |
			| | | Provider
			| Relay |
			| | -+
			| | -+
			| | -+ |
			| User (Forwarder) | |
			| [ Intermediate ] | |Provider
			| [ Recipient ] | |
			| [ Originator ] | Provider |
			| [ Submitter ] | |
			| | -+ |
			| Relay |
			| | -+
			| | -+
			Relay |
			| | Provider
			User (Recipient) |
			-+
			2.1 User
			Users are customers of the email relaying service. They represent
			the sources and sinks of that service.
			Three types of users are distinguished:
			2.1.1 Originator
			Also called "Author", this is a user-level participant responsible
			for creating original content and requesting its transmission. The
			email service operates to send and deliver mail among Originators and
			Recipients.
			2.1.2 Submitter
			The Submitter is responsible for ensuring that a message is valid for
			posting and then submitting it into the mail transfer service. It
			primarily serves the Originator and often it is the same entity.
			The Submitter has the responsibility for any additional
			originator-related administrative tasks associated with message
			transmission and delivery. Notably this pertains to error and
			delivery notices.
			It may be helpful to think of the Submitter as more like the editor
			or publisher of a periodical, rather than simply the administrative
			assistant for the Originator. Hence, the Submitter is best held
			accountable for the message content, even when they did not create
			any or most of it.
			2.1.3 Recipient
			The Recipient is a consumer of delivered content. The recipient is
			specified as an addressee, in the envelope.
			2.1.4 Forwarder
			Email often transits intermediate, user-level points, called
			Forwarders. The task of a Forwarder is to perform additional
			processing, such as replacing one target address for one or more
			others, and then submitting the message for further transmission.
			Examples are recipient-controlled aliasing and, of course, mailing
			list redistribution services. A Forwarder performs a natural
			sequence of email steps:
			o Service the mailbox specified in the envelope and accept arriving
			messages.
			o Reformulate message content and addressing, according to the
			policies of the administrator of the Forwarder. Request (further)
			message transmission. Note that an Intermediate Originator
			operates with dual allegiance, notably its operating authority,
			such as the mailing list administrator, as well as the "original"
			originator.
			o Perform the usual Submitter tasks.
			2.2 Relay
			A mail relay performs email transfer-service routing and
			store-and-forward. It (re-)transmits the message on towards it
			recipient(s). A basic transfer operation is between a client and a
			server Relay. A set of Relays composes a mail handling service
			network. This is above any underlying packet-switching network that
			they might be using.
			2.3 Provider
			Providers operate component services. As shown in the Figure, it is
			possible for Providers to host services for other Providers. Common
			examples are:
			Enterprise Service Providers: Operating an organization's internal
			data and/or mail operations.
			Internet Service Providers: Operating underlying data communication
			services that, in turn, are used by one or more Relays and Users.
			It is not their job to perform email functions, but to provide an
			environment in which those functions can be performed.
			Mail Service Providers: Operate email services, such as for
			end-users, or mailing lists.
			Operational pragmatics often dictate that Providers be involved in
			detailed administration and enforcement issues, to help insure the
			health of the overall Internet Mail service.
			3. Email Identities
	Internet mail uses two forms of identity. The most common is the		Internet mail uses two forms of identity. The most common is the
	mailbox address <addr-spec> [RFC2822]. The other form is the <domain		mailbox address <addr-spec> [RFC2822]. The other form is the <domain
	name> [RFC1034].		name> [RFC1034].
	2.1 Mailbox Addresses		3.1 Mailbox Addresses
	An addr-spec has two distinct parts, divided by an at-sign ("@").		An addr-spec has two distinct parts, divided by an at-sign ("@").
	The right-hand side contains a globally interpreted name for an		The right-hand side contains a globally interpreted name for an
	administrative domain. This domain name might refer to an entire		administrative domain. This domain name might refer to an entire
	organization, or to a collection of machines integrated into a		organization, or to a collection of machines integrated into a
	homogeneous service, or to a single machine. Domain names are		homogeneous service, or to a single machine. Domain names are
	defined and operated through the DNS [RFC1034], [RFC1035].		defined and operated through the DNS [RFC1034], [RFC1035].
	The left-hand side of the at-sign contains a string that is globally		The left-hand side of the at-sign contains a string that is globally
	opaque and is called the <local-part>. It is to be interpreted only		opaque and is called the <local-part>. It is to be interpreted only
	by the entity specified in the address's right-hand side. All other		by the entity specified in the address's right-hand side. All other
	entities must treat the local-part as a uninterpreted, literal string		entities must treat the local-part as a uninterpreted, literal string
	and must preserve all of its original details. As such, its		and must preserve all of its original details. As such, its
	distribution is equivalent to sending a "cookie" that is only		distribution is equivalent to sending a "cookie" that is only
	interpreted upon being returned to its originator.		interpreted upon being returned to its originator.
	2.1.1 Global Standards for Local-Part		3.1.1 Global Standards for Local-Part
			It is common for sites to have local conventions for sub-structure to
			the left-hand side of an addr-spec. This permits sub-addressing,
			such as for distinguishing different discussion groups by the same
			participant. However it must be stressed that these conventions are
			strictly private to the user's organization and must not be
			interpreted by any domain except the one listed in the right-hand
			side of the add-spec.
	A small class of addresses have an elaboration on basic email		A small class of addresses have an elaboration on basic email
	addressing, with a standardized, global schema for the local-part.		addressing, with a standardized, global schema for the local-part.
	These are conventions between originating end-systems and recipient		These are conventions between originating end-systems and recipient
	gateways, and they are invisible to the public email transfer		gateways, and they are invisible to the public email transfer
	infrastructure. When an originator is explicitly sending via a		infrastructure. When an originator is explicitly sending via a
	gateway out of the Internet, there are coding conventions for the		gateway out of the Internet, there are coding conventions for the
	local-part, so that the originator can formulate instructions for the		local-part, so that the originator can formulate instructions for the
	gateway. Standardized examples of this are the telephone numbering		gateway. Standardized examples of this are the telephone numbering
	formats for VPIM [RFC2421], such as "+16137637582@vpim.example.com",		formats for VPIM [RFC2421], such as "+16137637582@vpim.example.com",
	and iFax [RFC2304], such as "FAX=+12027653000/		and iFax [RFC2304], such as "FAX=+12027653000/
	T33S=1387@ifax.example.com".		T33S=1387@ifax.example.com".
	2.1.2 Scope of Email Address Use		3.1.2 Scope of Email Address Use
	Email addresses are being used far beyond their original email		Email addresses are being used far beyond their original email
	transfer and delivery role. In practical terms, email strings have		transfer and delivery role. In practical terms, email strings have
	become a common form of user identity on the Internet. What is		become a common form of user identity on the Internet. What is
	essential, then, is to be clear about the nature and role of an		essential, then, is to be clear about the nature and role of an
	identity string in a particular context and to be clear about the		identity string in a particular context and to be clear about the
	entity responsible for setting that string.		entity responsible for setting that string.
	2.2 Domain Names		3.2 Domain Names
	A domain name is a global reference to an Internet resource, such as		A domain name is a global reference to an Internet resource, such as
	a host, a service or a network. A name usually maps to an IP		a host, a service or a network. A name usually maps to one or more
	Address. A domain name can be administered to refer to individual		IP Addresses. A domain name can be administered to refer to
	users, but this is not common practice. The name is structure as a		individual users, but this is not common practice. The name is
	hierarchical sequence of sub-names, separated by dots (".").		structure as a hierarchical sequence of sub-names, separated by dots
			(".").
	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 a node that took action upon the message, such as		mail to refer to a node that took action upon the message, such as
	providing the administrative scope for a message identifier, or		providing the administrative scope for a message identifier, or
	performing transfer processing.		performing transfer processing.
	2.3 Identity Reference Convention		3.3 Message Identifers
	In this document, fields containing identity references are labeled		Message identifiers have two distinct parts, divided by an at-sign
	in a two-part, dotted notation, that cites document defining them and		("@"). The right-hand side contains a globally interpreted name for
	the field containing them. Hence, <RFC2822.From> is the From field		the administrative domain assigning the identifier. The left-hand
	in an email content header, and <RFC2821.MailFrom> is the address in		side of the at-sign contains a string that is globally opaque and
	the SMTP "Mail From" command.		serves to uniquely identify the message within the domain referenced
			on the right-hand side. The duration of uniqueness for the message
			identifier is undefined.
	3. Email System Architecture		The identifier may be assigned by the user or by any component of the
			system along the path. Although Internet mail standards provide for
			a single identifier, more than one is sometimes assigned.
			3.4 Identity Reference Convention
			In this document, fields references to identities are labeled in a
			two-part, dotted notation. The first part cites the document
			defining the identity and the second defines the name of the
			identity. Hence, <RFC2822.From> is the From field in an email
			content header, and <RFC2821.MailFrom> is the address in the SMTP
			"Mail From" command.
			4. Email System Architecture
	NOTE: A discussion about any interesting system architecture is often		NOTE: A discussion about any interesting system architecture is often
	complicated by confusion between architecture versus		complicated by confusion between architecture versus
	implementation. An architecture defines the conceptual functions		implementation. An architecture defines the conceptual functions
	of a service, divided into discrete conceptual modules. An		of a service, divided into discrete conceptual modules. An
	implementation of that architecture may combine or separate		implementation of that architecture may combine or separate
	architectural components, as needed for a particular operational		architectural components, as needed for a particular operational
	environment. It is important not to confuse the engineering		environment. It is important not to confuse the engineering
	decisions that are made to implement a product, with the		decisions that are made to implement a product, with the
	architectural abstractions used to define conceptual functions.		architectural abstractions used to define conceptual functions.
	Modern Internet email architecture distinguishes four types of		Modern Internet email architecture distinguishes four types of
	components, arranged to support a store-and-forward service		components, arranged to support a store-and-forward service
	architecture:		architecture:
	+------ MUA originator (oMUA)		+-----------<-oMUA <-------------------------------+
	| |		| | < smtp, |
	RFC2822 | < submission, smtp		(envelope) V submission |
	| MSA		RFC2822 MSA <-------------------------+ |
	| | < smtp		MIME | < smtp | |
	| MTA		| MTA dsn |
	| | < smtp		| | < smtp | |
	| MTA		| MTA ->----------------------->+ |
	| | < smtp		| | < smtp |
	| .		| . |
	| .		| . |
	| .		| . |
	| |		| V |
	| MTA		| MTA |
	| | < smtp		| | < local, smtp, lmtp |
	| MTA		| MDA <-------------------------+ |
	| | < smtp		| | | | |
	| MDA		| MS-1 | < local, | |
	| | < pop, imap		| | | | < pop, sieve |
	| |		| | | | < imap, | |
	+------ MUA recipient (rMUA)		| | MS-2 < smtp, or | mdn
			| | | < web | |
			V | V | |
			+---------> rMUA ->--------------------------+-----+
	Software implementations of these architectural components often		Software implementations of these architectural components often
	compress them, such as having the same software do MSA, MTA and MDA		compress them, such as having the same software do MSA, MTA and MDA
	functions. However the requirements for each of these components of		functions. However the requirements for each of these components of
	the architecture are becoming more extensive. So, their separation		the architecture are becoming more extensive. So, their separation
	is increasingly common.		is increasingly common.
	3.1 Architectural Components		4.1 Architectural Components
	3.1.1 Mail User Agent (MUA)		4.1.1 Mail User Agent (MUA)
	An <MUA> works on behalf of end-users and end-user applications. It		An <MUA> works on behalf of end-users and end-user applications. It
	is their "representative" within the email service.		is their "representative" within the email service.
	At the origination side of the service, the <oMUA> is used to create		At the origination side of the service, the <oMUA> is used to create
	a message and perform initial "submission" into the transfer		a message and perform initial "submission" into the transfer
	infrastructure, via an <MSA>. It may also perform any creation- and		infrastructure, via an <MSA>. It may also perform any creation- and
	posting-time archival. An MUA outbox is part of the origination-side		posting-time archival. An MUA outbox is part of the origination-side
	MUA.		MUA.
	The inbox and other folders are part of the recipient-side <rMUA>		The recipient-side <rMUA> works on behalf of the end-user to process
	that works on behalf of the end-user to process received mail. This		received mail. This includes generating user-level return control
	includes generating user-level return control messages, display and		messages, display and disposition of the received message, and
	disposition of the received message, and closing or expanding the		closing or expanding the user communication loop, by initiating
	user communication loop, by initiating replies and forwarding new		replies and forwarding new messages.
	messages.
	An MUA may, itself, have a distributed architecture, such as		An MUA may, itself, have a distributed architecture, such as
	implementing a "thin" user interface module on a limited end-user		implementing a "thin" user interface module on a limited end-user
	device, with the bulk of the MUA functionality operated remotely on a		device, with the bulk of the MUA functionality operated remotely on a
	more capable server. An example of such an architecture might use		more capable server. An example of such an architecture might use
	IMAP [RFC3501] for most of the interactions between an MUA client and		IMAP [RFC3501] for most of the interactions between an MUA client and
	an MUA server.		an MUA server.
	A special class of MUA functions perform message forwarding, as		A special class of MUA functions perform message forwarding, as
	discussed in the MUA Forwarding (Section 5.2) section.		discussed in the [2] section.
	Identity fields set by the MUA include:		Identity fields set by the MUA include:
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| Identity | Role |		| Identity | Actor | Description |
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| RFC2822.From | Names and addresses for |		| RFC2822.From | Originator | Names and addresses |
	| | author(s) of the message |		| | | for author(s) of |
	| | content are listed in the From |		| | | the message content |
	| | header |		| | | are listed in the |
	| RFC2822.Reply-To | If a message recipient sends a |		| | | From header |
	| | message that would otherwise |		| RFC2822.Reply-To | Originator | If a message |
	| | use the RFC2822.From field |		| | | recipient sends a |
	| | information in the original |		| | | message that would |
	| | message, they are to use the |		| | | otherwise use the |
	| | contents of the |		| | | RFC2822.From field |
	| | RFC2822.Reply-To field instead. |		| | | information in the |
	| | In other words, this field is a |		| | | original message, |
	| | direct override of the From |		| | | they are to use the |
	| | field, for responses from |		| | | contents of the |
	| | recipients. |		| | | RFC2822.Reply-To |
	| RFC2822.Sender | This specifies the address |		| | | field instead. In |
	| | responsible for submission into |		| | | other words, this |
	| | the transfer service. For |		| | | field is a direct |
	| | efficiency, this field should |		| | | override of the |
	| | be omitted if it contains the |		| | | From field, for |
	| | same address as RFC2822.From. |		| | | responses from |
	| | However this does not mean |		| | | recipients. |
	| | there is no Sender specified. |		| RFC2822.Sender | Submitter | This specifies the |
	| | Rather, it means that that |		| | | address responsible |
	| | header is virtual and that the |		| | | for submission into |
	| | address in the From field must |		| | | the transfer |
	| | be used. Specification of the |		| | | service. For |
	| | error return addresses (the |		| | | efficiency, this |
	| | "bounces" address, contained in |		| | | field should be |
	| | RFC2821.MailFrom) is made by |		| | | omitted if it |
	| | the Sender. Typically the |		| | | contains the same |
	| | bounce address is the same as |		| | | address as |
	| | the Sender address. However |		| | | RFC2822.From. |
	| | some usage scenarios require it |		| | | However this does |
	| | to be different. |		| | | not mean there is |
	| RFC2822.To, RFC2822.CC | These specify MUA recipient |		| | | no Sender |
	| | addresses. The distinction |		| | | specified. Rather, |
	| | between To and CC is |		| | | it means that that |
	| | subjective. Generally, a To |		| | | header is virtual |
	| | addressee is considered primary |		| | | and that the |
	| | and is expected to take action |		| | | address in the From |
	| | on the message. A CC addressee |		| | | field must be used. |
	| | typically receives a copy only |		| | | Specification of |
	| | for their information. |		| | | the error return |
	| RFC2822.BCC | A message might be copied to an |		| | | addresses (the |
	| | addressee who is not to be |		| | | "bounces" address, |
	| | disclosed to the RFC2822.TO or |		| | | contained in |
	| | RFC2822.CC recipients. The BCC |		| | | RFC2821.MailFrom) |
	| | header indicates a message copy |		| | | is made by the |
	| | to such a recipient. Typically, |		| | | Sender. Typically |
	| | the field lists no addresses or |		| | | the bounce address |
	| | only lists the address of the |		| | | is the same as the |
	| | single recipient receiving the |		| | | Sender address. |
	| | copy. This ensures that even |		| | | However some usage |
	| | other BCC recipients do not |		| | | scenarios require |
	| | know of each other. |		| | | it to be different. |
	+---------------------------------+---------------------------------+		| RFC2822.To, | Recipient | These specify MUA |
			| RFC2822.CC | | recipient |
			| | | addresses. The |
			| | | distinction between |
			| | | To and CC is |
			| | | subjective. |
			| | | Generally, a To |
			| | | addressee is |
			| | | considered primary |
			| | | and is expected to |
			| | | take action on the |
			| | | message. A CC |
			| | | addressee typically |
			| | | receives a copy |
			| | | only for their |
			| | | information. |
			| RFC2822.BCC | Recipient | A message might be |
			| | | copied to an |
			| | | addressee who is |
			| | | not to be disclosed |
			| | | to the RFC2822.TO |
			| | | or RFC2822.CC |
			| | | recipients. The BCC |
			| | | header indicates a |
			| | | message copy to |
			| | | such a recipient. |
			| | | Typically, the |
			| | | field lists no |
			| | | addresses or only |
			| | | lists the address |
			| | | of the single |
			| | | recipient receiving |
			| | | the copy. This |
			| | | ensures that even |
			| | | other BCC |
			| | | recipients do not |
			| | | know of each other. |
			| | | An MUA will |
			| | | typically make |
			| | | separate postings |
			| | | for TO and CC |
			| | | recipients, versus |
			| | | BCC recipients. The |
			| | | former will see no |
			| | | indication that any |
			| | | BCCs were sent, |
			| | | whereas the latter |
			| | | have a BCC field |
			| | | present. It might |
			| | | be empty, contain a |
			| | | comment, or contain |
			| | | one or more BCC |
			| | | addresses, |
			| | | depending upon the |
			| | | preferences or the |
			| | | Originator. |
			+----------------------+----------------------+---------------------+
	Table 1: Message Identities		Table 1: Message Identities
	3.1.2 Mail Submission Agent (MSA)		4.1.2 Mail Submission Agent (MSA)
	An <MSA> accepts the message submission from the oMUA and conditions		An <MSA> accepts the message submission from the oMUA and conditions
	it for insertion into the global email transfer network, according to		it for insertion into the global email transfer network, according to
	the policies of the hosting network and the requirements of Internet		the policies of the hosting network and the requirements of Internet
	standards. It implements a server function to MUAs and a client		standards. It implements a server function to MUAs and a client
	function to MTAs (or MDAs).		function to MTAs (or MDAs).
	Examples of MSA-styled functions, in the world of paper mail, might		Examples of MSA-styled functions, in the world of paper mail, might
	range across the very different capabilities of administrative		range across the very different capabilities of administrative
	assistants, postal drop boxes, and post office front-counter		assistants, postal drop boxes, and post office front-counter
	skipping to change at page 10, line 7 ¶		skipping to change at page 15, line 17 ¶
	The MUA/MSA interface can be implemented within single host and use		The MUA/MSA interface can be implemented within single host and use
	private conventions for their interactions. Historically,		private conventions for their interactions. Historically,
	standards-based MUA/MSA interactions have used SMTP [RFC2821].		standards-based MUA/MSA interactions have used SMTP [RFC2821].
	However a recent alternative is SUBMISSION [RFC2476]. Although		However a recent alternative is SUBMISSION [RFC2476]. Although
	SUBMISSION derives from SMTP, it operates on a separate TCP port, and		SUBMISSION derives from SMTP, it operates on a separate TCP port, and
	will typically impose distinct requirements, such as access		will typically impose distinct requirements, such as access
	authorization.		authorization.
	Identities set by the MSA include:		Identities set by the MSA include:
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| Identity | Role |		| Identity | Actor | Description |
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| RFC2821.HELO or RFC2821.EHLO | The MSA may specify its hosting |		| RFC2821.HELO or | Submitter | The MSA may specify |
	| | domain identity for the SMTP |		| RFC2821.EHLO | | its hosting domain |
	| | HELO or EHLO command operation. |		| | | identity for the |
	| RFC2821.MailFrom | This is an end-to-end string |		| | | SMTP HELO or EHLO |
	| | that specifies an email address |		| | | command operation. |
	| | for receiving return control |		| RFC2821.MailFrom | Submitter | This is an |
	| | information, such as "bounces". |		| | | end-to-end string |
	| | The name of this field is |		| | | that specifies an |
	| | misleading, because it is not |		| | | email address for |
	| | required to specify either the |		| | | receiving return |
	| | author or the agent responsible |		| | | control |
	| | for submitting the message. |		| | | information, such |
	| | Rather, the agent responsible |		| | | as "bounces". The |
	| | for submission specifies the |		| | | name of this field |
	| | RFC2821.MailFrom address. |		| | | is misleading, |
	| | Ultimately the simple basis for |		| | | because it is not |
	| | deciding what address needs to |		| | | required to specify |
	| | be in the RFC2821.MailFrom is |		| | | either the author |
	| | to determine what address needs |		| | | or the agent |
	| | to be informed about |		| | | responsible for |
	| | transmission-level problems |		| | | submitting the |
	| | (and, possibly, successes.) |		| | | message. Rather, |
	| RFC2821.Rcpt-To | This specifies the MUA inbox |		| | | the agent |
	| | address of a recipient. The |		| | | responsible for |
	| | string might not be visible in |		| | | submission |
	| | the message content headers. |		| | | specifies the |
	| | For example, the message |		| | | RFC2821.MailFrom |
	| | destination address headers, |		| | | address. Ultimately |
	| | such as RFC2822.To, might |		| | | the simple basis |
	| | specify a mailing list address, |		| | | for deciding what |
	| | while the RFC2821.Rcpt-To |		| | | address needs to be |
	| | address specifies a member of |		| | | in the |
	| | that list. |		| | | RFC2821.MailFrom is |
	| RFC2821.Received | An MSA may record a Received |		| | | to determine what |
	| | header, to indicate initial |		| | | address needs to be |
	| | submission trace information, |		| | | informed about |
	| | including originating host and |		| | | transmission-level |
	| | MSA host domain names and/or IP |		| | | problems (and, |
	| | Addresses. |		| | | possibly, |
	+---------------------------------+---------------------------------+		| | | successes.) |
			| RFC2821.Rcpt-To | Recipient | This specifies the |
			| | | MUA inbox address |
			| | | of a recipient. The |
			| | | string might not be |
			| | | visible in the |
			| | | message content |
			| | | headers. For |
			| | | example, the |
			| | | message destination |
			| | | address headers, |
			| | | such as RFC2822.To, |
			| | | might specify a |
			| | | mailing list |
			| | | address, while the |
			| | | RFC2821.Rcpt-To |
			| | | address specifies a |
			| | | member of that |
			| | | list. |
			| RFC2821.Received | Submitter | An MSA may record a |
			| | | Received header, to |
			| | | indicate initial |
			| | | submission trace |
			| | | information, |
			| | | including |
			| | | originating host |
			| | | and MSA host domain |
			| | | names and/or IP |
			| | | Addresses. |
			+----------------------+----------------------+---------------------+
	Table 2: MSA Identities		Table 2: MSA Identities
	3.1.3 Mail Transfer Agent (MTA)		4.1.3 Mail Transfer Agent (MTA)
	An <MTA> relays a message to another other MTA or to an <MDA>, in a		An <MTA> relays a message to another other MTA or to an <MDA>, in a
	point-to-point exchange. Relaying is performed by a sequence of		point-to-point exchange. Relaying is performed by a sequence of
	MTAs, until the message reaches its destination MDA. Hence an MTA		MTAs, until the message reaches its destination MDA. Hence an MTA
	implements both client and server MTA functionality.		implements both client and server MTA functionality.
	The basic store-and-forward functionality of an MTA is similar to		The basic functionality of an MTA is similar to that of a packet
	that of a packet switch or router. However email objects are		switch or IP router. That is, it does email store-and-forward email,
	typically much larger than the payload of a packet or datagram, and		with a routing decision determining where the next-hop destination
	the end-to-end latencies are typically much higher. Contrary to		shall be. The primary "routing" mechanism for Internet mail is the
	typical packet switches (and Instant Messaging services) Internet		DNS MX record [RFC1035]. As with most "link layer" mechanisms
	mail MTAs typically store messages in a manner that allows recovery		Internet mail's SMTP supports a basic level of reliability, by virtue
	across services interruptions, such as host system shutdown.		of providing for retransmission after al transfer failure. However
			the degree of persistence by an MTA can be highly variable.
			However email objects are typically much larger than the payload of a
			packet or datagram, and the end-to-end latencies are typically much
			higher. Contrary to typical packet switches (and Instant Messaging
			services) Internet mail MTAs typically store messages in a manner
			that allows recovery across services interruptions, such as host
			system shutdown.
	Internet mail primarily uses SMTP [RFC2821], [RFC0821] to effect		Internet mail primarily uses SMTP [RFC2821], [RFC0821] to effect
	point-to-point transfers between peer MTAs. Other transfer		point-to-point transfers between peer MTAs. Other transfer
	mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]		mechanisms include Batch SMTP [RFC2442] and ODMR [RFC2645]
	An important characteristic of MTA-MTA communications, over the open		An important characteristic of MTA-MTA communications, over the open
	Internet, is that they do not require prior arrangement between the		Internet, is that they do not require prior arrangement between the
	independent administrations operating the different MTAs. Given the		independent administrations operating the different MTAs. Given the
	importance of spontaneity and serendipity in the world of human		importance of spontaneity and serendipity in the world of human
	communications, this lack of prearrangement, between the		communications, this lack of prearrangement, between the
	participants, is a core benefit of Internet mail and remains a core		participants, is a core benefit of Internet mail and remains a core
	requirement for it.		requirement for it.
	3.1.4 Mail Delivery Agent (MDA)		Identities set by the MTA include:
			+----------------------+----------------------+---------------------+
			| Identity | Actor | Description |
			+----------------------+----------------------+---------------------+
			| RFC2821.HELO | Relay | The MTA may specify |
			| | | its hosting domain |
			| | | identity for the |
			| | | SMTP HELO or EHLO |
			| | | command operation. |
			| RFC2821.Return-Path | Originator | The MDA records the |
			| | | RFC2821.MailFrom |
			| | | address into an |
			| | | RFC2822 header |
			| | | named Return-Path. |
			| RFC2822.Received | Relay | An MTA must record |
			| | | a Received header, |
			| | | to indicate trace |
			| | | information, |
			| | | including source |
			| | | host and receiving |
			| | | host domain names |
			| | | and/or IP |
			| | | Addresses. |
			+----------------------+----------------------+---------------------+
			Table 3: MTA Identities
			4.1.4 Mail Delivery Agent (MDA)
	The <MDA> delivers email to the recipient's inbox.		The <MDA> delivers email to the recipient's inbox.
	An MDA can provide distinctive, address-based functionality, made		An MDA can provide distinctive, address-based functionality, made
	possible by its detailed knowledge of the properties of the		possible by its detailed knowledge of the properties of the
	destination address. This knowledge might also be present earlier in		destination address. This knowledge might also be present earlier in
	an MTA relaying sequence that ends with the MDA, such as at an		an MTA relaying sequence that ends with the MDA, such as at an
	organizational gateway. However it is required for the MDA, if only		organizational gateway. However it is required for the MDA, if only
	because the MDA must know where to store the message. This knowledge		because the MDA must know where to store the message. This knowledge
	is used to achieve differential handling of messages.		is used to achieve differential handling of messages.
	skipping to change at page 12, line 5 ¶		skipping to change at page 18, line 34 ¶
	Using Internet protocols, delivery is effected with POP [RFC1939],		Using Internet protocols, delivery is effected with POP [RFC1939],
	IMAP [RFC3501]. SMTP permits "push" delivery to the recipient		IMAP [RFC3501]. SMTP permits "push" delivery to the recipient
	system, at the imitative of the upstream email service. POP is used		system, at the imitative of the upstream email service. POP is used
	for "pull" delivery at the initiative of the recipient system.		for "pull" delivery at the initiative of the recipient system.
	Notably, SMTP and POP effect a transfer of message control from the		Notably, SMTP and POP effect a transfer of message control from the
	email service to the recipient host. In contrast, IMAP provides		email service to the recipient host. In contrast, IMAP provides
	on-going, interactive access to a message store, and does not effect		on-going, interactive access to a message store, and does not effect
	a transfer of message control to the end-user host. Instead, control		a transfer of message control to the end-user host. Instead, control
	stays with the message store host that is being access by the user.		stays with the message store host that is being access by the user.
	Identities set by the MSA include:		Identities set by the MDA include:
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| Identity | Role |		| Identity | Actor | Description |
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| RFC2821.HELO or RFC2821.EHLO | The MTA may specify its hosting |		| RFC2821.HELO or | Relay | The MDA may specify |
	| | domain identity for the SMTP |		| RFC2821.EHLO | | its hosting domain |
	| | HELO or EHLO command operation. |		| | | identity for the |
	| RFC2822.Received | An MTA must record a Received |		| | | SMTP HELO or EHLO |
	| | header, to indicate trace |		| | | command operation. |
	| | information, including source |		| RFC2822.Received | h | An MTA must record |
	| | host and receiving host domain |		| | | a Received header, |
	| | names and/or IP Addresses. |		| | | to indicate trace |
	+---------------------------------+---------------------------------+		| | | information, |
			| | | including source |
			| | | host and receiving |
			| | | host domain names |
			| | | and/or IP |
			| | | Addresses. |
			+----------------------+----------------------+---------------------+
	Table 3: MTA Identities		Table 4: MDA Identities
	3.2 Operational Configuration		4.1.5 Message Store
			An MUA's uses a long-term Message Store (MS). A rich set of choices
			for the use of that store derives from permitting more than one to be
			associated with a single user, demonstrated as MS-1 and MS-2 in the
			Figure. MS-1 is shown as being remote from the MUA and MS-2 as being
			local. Further the relationship between two message store may vary.
			Between the MDA and the MUA, these choices are supported by a wide
			variety of protocol options.
			The operational relationship among two MSs can be:
			Online: Only a remote MS is used, with messages being accessible only
			when the MUA is attached to the MS, and the MUA repeatedly fetches
			all or part of a message, from one session to the next.
			Offline: The MS is local to the user, and messages are moved from any
			remote store, rather than (also) being retained there.
			Disconnected: A remote MS and a local MS synchronize all or parts of
			their contents, while connected. The user may make changes while
			disconnected, and the two stores are re-synchronized upon
			reconnection.
			4.2 Operational Configuration
	Mail service components can be arranged into numerous organizational		Mail service components can be arranged into numerous organizational
	structures, each with independent software and administration. One		structures, each with independent software and administration. One
	common arrangement is to distinguish:		common arrangement is to distinguish:
	1. an open, core, global email transfer infrastructure		1. an open, core, global email transfer infrastructure
	2. independent transfer services in networks at the edge of the core		2. independent transfer services in networks at the edge of the core
	3. end-user services		3. end-user services
	skipping to change at page 12, line 51 ¶		skipping to change at page 20, line 17 ¶
	participants in email transfer.		participants in email transfer.
	On the other hand, real-world operations of Internet mail		On the other hand, real-world operations of Internet mail
	environments do impose boundaries such as access control at		environments do impose boundaries such as access control at
	organizational firewalls to the Internet. It should be noted that		organizational firewalls to the Internet. It should be noted that
	the current Internet Mail architecture offers no special constructs		the current Internet Mail architecture offers no special constructs
	for these configuration choices. The current design of Internet mail		for these configuration choices. The current design of Internet mail
	is for a seamless, end-to-end store-and-forward sequence. It is		is for a seamless, end-to-end store-and-forward sequence. It is
	possible that the architectural enhancement will not require new		possible that the architectural enhancement will not require new
	protocols, but rather will require clarification of best practises,		protocols, but rather will require clarification of best practises,
	as exemplified by a recent effort [I-D.hutzler-spamops]		as exemplified by a recent effort [ID-spamops]
	3.3 Layers of Identity References		4.3 Layers of Identity References
	For a message in transit, the core identity fields combine into		For a message in transit, the core identity fields combine into
	+-----------------+--------------+-------------------+		+-----------------+--------------+-----------------------------+
	| Layer | Field | Set By |		| Layer | Field | Set By |
	+-----------------+--------------+-------------------+		+-----------------+--------------+-----------------------------+
	| Message Content | MIME Headers | Author |		| Message Content | MIME Headers | Originator |
	| Message Headers | From | Author |		| Message Headers | From | Originator |
	| | Sender | Agent of Author |		| | Sender | Submitter |
	| | Reply-To | Author |		| | Reply-To | Originator |
	| | To, CC, BCC | Author |		| | To, CC, BCC | Originator |
	| | Received | MSA, MTA, MDA |		| | Received | Submitter, Relay, Recipient |
	| | Return-Path | MDA from MailFrom |		| | Return-Path | MDA from MailFrom |
	| SMTP | HELO | Latest MTA Client |		| SMTP | HELO | Latest Relay Client |
	| | MailFrom | Agent of Author |		| | MailFrom | Submitter |
	| | RCPT-TO | MSA |		| | RCPT-TO | Submitter |
	| IP | IP Address | Latest MTA Client |		| IP | IP Address | Latest Relay Client |
	+-----------------+--------------+-------------------+		+-----------------+--------------+-----------------------------+
	4. Message Data		5. Message Data
	4.1 Envelope		5.1 Envelope
	Information that is directly used or produced by the email transfer		Information that is directly used or produced by the email transfer
	service is called the "envelope". It controls and records handling		service is called the "envelope". It controls and records handling
	activities by the transfer service. Internet mail has a fragmented		activities by the transfer service. Internet mail has a fragmented
	framework for handling this "handling" information. The envelope		framework for handling this "handling" information. The envelope
	exists partly in the transfer protocol SMTP [RFC2821] and partly in		exists partly in the transfer protocol SMTP [RFC2821] and partly in
	the message object [RFC2822].		the message object [RFC2822].
	Direct envelope addressing information, and optional transfer		Direct envelope addressing information, as well as optional transfer
	directives, are carried in-band by MTAs. All other envelope		directives, are carried in-band by MTAs. All other envelope
	information, such as trace records, is carried within the content		information, such as trace records, is carried within the content
	headers. Upon delivery, SMTP-level envelope information is typically		headers. Upon delivery, SMTP-level envelope information is typically
	encoded within additional content headers, such as Return-Path and		encoded within additional content headers, such as Return-Path and
	Received (From and For).		Received (From and For).
	4.2 Message Headers		5.2 Message Headers
	Headers are attribute/value pairs covering an extensible range of		Headers are attribute/value pairs covering an extensible range of
	email service, user content and user transaction meta-information.		email service, user content and user transaction meta-information.
	The core set of headers is defined in [RFC2822], [RFC0822]. It is		The core set of headers is defined in [RFC2822], [RFC0822]. It is
	common to extend this set, for different applications. A complete		common to extend this set, for different applications. A complete
	set of registered headers is being developed through [ID-HDR-Reg].		set of registered headers is being developed through [ID-hdr-reg].
	One danger with placing additional information in headers is that		One danger with placing additional information in headers is that
	gateways often alter or delete them.		gateways often alter or delete them.
	4.3 Body		5.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 structured into a composition of multi-media, body-part		be structured into a composition of multi-media, body-part
	attachments, using MIME [RFC2045], [RFC2046], [RFC2047], [RFC2048],		attachments, using MIME [RFC2045], [RFC2046], [RFC2047], [RFC2048],
	and [RFC2049]. It should be noted that MIME structures each		and [RFC2049]. It should be noted that MIME structures each
	body-part into a recursive set of MIME Header meta-data and MIME		body-part into a recursive set of MIME Header meta-data and MIME
	Content sections.		Content sections.
	5. Two Levels of Store-And-Forward		6. Two Levels of Store-And-Forward
	Basic email transfer is accomplished with an asynchronous		Basic email transfer is accomplished with an asynchronous
	store-and-forward communication infrastructure. This means that		store-and-forward communication infrastructure. This means that
	moving a message from an originator to a recipient involves a		moving a message from an originator to a recipient involves a
	sequence of independent transmissions through some number of		sequence of independent transmissions through some number of
	intermediaries, called MTAs. A very different task is the user-level		intermediaries, called MTAs. A very different task is the user-level
	process of re-posting a message through a new submission process,		process of re-posting a message through a new submission process,
	after final delivery for an earlier transfer sequence. Such		after final delivery for an earlier transfer sequence. Such
	MUA-based re-posting shares some functionality with basic MTA		MUA-based re-posting shares some functionality with basic MTA
	relaying, but it enjoys a degree of freedom with both addressing and		relaying, but it enjoys a degree of freedom with both addressing and
	content that is not available to MTAs.		content that is not available to MTAs.
	The primary "routing" mechanism for Internet mail is the DNS MX		The primary "routing" mechanism for Internet mail is the DNS MX
	record [RFC1035]. It is an advertisement, by a recipient domain, of		record [RFC1035]. It is an advertisement, by a recipient domain, of
	hosts that are able to relay mail to it, within the portion of the		hosts that are able to relay mail to it, within the portion of the
	Internet served by this instance of the DNS.		Internet served by this instance of the DNS.
	5.1 MTA Relaying		6.1 MTA Relaying
	MTAs relay mail. They are like packet-switches and IP routers.		MTAs relay mail. They are like packet-switches and IP routers.
	Their job is to make routing assessments and to move the message		Their job is to make routing assessments and to move the message
	payload data closer to the recipient. It is not their job to		payload data closer to the recipient. It is not their job to
	reformulate the payload or to change addresses in the envelope or the		reformulate the payload or to change addresses in the envelope or the
	content.		content.
	5.2 MUA Forwarding		6.2 MUA Forwarding
	Forwarding is performed by MUAs that take a received message and		As discussed in <Forwarder> section, forwarding is performed by MUAs
	submit it back to the transfer service, for delivery to one or more		that take a received message and submit it back to the transfer
	different addresses. A forwarded message may appear identical to a		service, for delivery to one or more different addresses. A
	relayed message, such as for Alias forwarders, or it may have minimal		forwarded message may appear identical to a relayed message, such as
	similarity, as with a Reply.		for Alias forwarders, or it may have minimal similarity, as with a
			Reply.
	5.2.1 MUA Basic Forwarding		6.2.1 MUA Basic Forwarding
	The simplest type of forwarding involves creating an entirely new		The simplest type of forwarding involves creating an entirely new
	message, with new content, that includes the original message between		message, with new content, that includes the original message between
	Originator-1 and Recipient-1. However this forwarded communication		Originator-1 and Recipient-1. However this forwarded communication
	is between Recipient-1 (who could also be called Originator-2) and a		is between Recipient-1 (who could also be called Originator-2) and a
	new recipient, Recipient-2. The forwarded message is therefore		new recipient, Recipient-2. The forwarded message is therefore
	independent of the original message exchange and creates a new		independent of the original message exchange and creates a new
	message dialogue.		message dialogue.
	5.2.2 MUA Re-Sending		6.2.2 MUA Re-Sending
	A recipient may wish to declare that an alternate addressee should		A recipient may wish to declare that an alternate addressee should
	take on responsibility for a message, or otherwise become involved in		take on responsibility for a message, or otherwise become involved in
	the original communication. They do this through a user-level		the original communication. They do this through a user-level
	forwarding function, called re-sending. The act of re-sending, or		forwarding function, called re-sending. The act of re-sending, or
	re-directing, splices a communication between Originator-1 and		re-directing, splices a communication between Originator-1 and
	Recipient-1, to become a communication between Originator-1 and new		Recipient-1, to become a communication between Originator-1 and new
	Recipient-2. In this case, the content of the new message is the old		Recipient-2. In this case, the content of the new message is the old
	message, including preservation of the essential aspects of the		message, including preservation of the essential aspects of the
	original message's origination information.		original message's origination information.
	Identities specified in a resent message include		Identities specified in a resent message include
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| Identity | Role |		| Identity | Actor | Description |
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| RFC2822.From | Names and email addresses for |		| RFC2822.From | Originator | Names and email |
	| | the original author(s) of the |		| | | addresses for the |
	| | message content are retained. |		| | | original author(s) |
	| | The free-form (display-name) |		| | | of the message |
	| | portion of the address might be |		| | | content are |
	| | modified to provide informal |		| | | retained. The |
	| | reference to the agent |		| | | free-form |
	| | responsible for the |		| | | (display-name) |
	| | redirection. |		| | | portion of the |
	| RFC2822.Reply-To | If this field is present in the |		| | | address might be |
	| | original message, it should be |		| | | modified to provide |
	| | retained in the Re-sent |		| | | informal reference |
	| | message. |		| | | to the agent |
	| RFC2822.Sender | This field is expected to |		| | | responsible for the |
	| | contain the original Sender |		| | | redirection. |
	| | value. |		| RFC2822.Reply-To | Originator | If this field is |
	| RFC2822.TO, RFC2822.CC, | These specify the original |		| | | present in the |
	| RFC2822.BCC | message recipients. |		| | | original message, |
	| RFC2822.Resent-From | The address of the original |		| | | it should be |
	| | recipient who is redirecting |		| | | retained in the |
	| | the message. Otherwise, the |		| | | Re-sent message. |
	| | same rules apply for the |		| RFC2822.Sender | Submitter | This field is |
	| | Resent-From field as for an |		| | | expected to contain |
	| | original RFC2822.From field |		| | | the original Sender |
	| RFC2822.Resent-Sender | The address of the agent |		| | | value. |
	| | responsible for re-submitting |		| RFC2822.TO, | Recipient | These specify the |
	| | the message. For efficiency, |		| RFC2822.CC, | | original message |
	| | this field should be omitted if |		| RFC2822.BCC | | recipients. |
	| | it contains the same address as |		| RFC2822.Resent-From | Intermediate | The address of the |
	| | RFC2822.Resent-From. However |		| | Originator | original recipient |
	| | this does not mean there is no |		| | | who is redirecting |
	| | Resend-Sender specified. |		| | | the message. |
	| | Rather, it means that that |		| | | Otherwise, the same |
	| | header is virtual and that the |		| | | rules apply for the |
	| | address in the Resent-From |		| | | Resent-From field |
	| | field must be used. |		| | | as for an original |
	| | Specification of the error |		| | | RFC2822.From field |
	| | return addresses (the "bounces" |		| RFC2822.Resent-Sende | Intermediate | The address of the |
	| | address, contained in |		| r | Submitter | agent responsible |
	| | RFC2821.MailFrom) is made by |		| | | for re-submitting |
	| | the Resent-Sender. Typically |		| | | the message. For |
	| | the bounce address is the same |		| | | efficiency, this |
	| | as the Resent-Sender address. |		| | | field should be |
	| | However some usage scenarios |		| | | omitted if it |
	| | require it to be different. |		| | | contains the same |
	| RFC2822.Resent-To, | The addresses of the new |		| | | address as |
	| RFC2822.Resent-cc, | recipients who will now be able |		| | | RFC2822.Resent-From |
	| RFC2822.Resent-bcc | to reply to the original |		| | | . However this does |
	| | author. |		| | | not mean there is |
	| RFC2821.MailFrom | The agent responsible for |		| | | no Resend-Sender |
	| | re-submission |		| | | specified. Rather, |
	| | (RFC2822.Resent-Sender) is also |		| | | it means that that |
	| | responsible for specifying the |		| | | header is virtual |
	| | new RFC2821.MailFrom address. |		| | | and that the |
	| RFC2821.Rcpt-to | This will contain the address |		| | | address in the |
	| | of a new recipient |		| | | Resent-From field |
	| RFC2822.Received | When re-sending a message, the |		| | | must be used. |
	| | submission agent may record a |		| | | Specification of |
	| | Received header, to indicate |		| | | the error return |
	| | the transition from original |		| | | addresses (the |
	| | posting to resubmission. |		| | | "bounces" address, |
	+---------------------------------+---------------------------------+		| | | contained in |
			| | | RFC2821.MailFrom) |
			| | | is made by the |
			| | | Resent-Sender. |
			| | | Typically the |
			| | | bounce address is |
			| | | the same as the |
			| | | Resent-Sender |
			| | | address. However |
			| | | some usage |
			| | | scenarios require |
			| | | it to be different. |
			| RFC2822.Resent-To, | Recipient | The addresses of |
			| RFC2822.Resent-cc, | | the new recipients |
			| RFC2822.Resent-bcc | | who will now be |
			| | | able to reply to |
			| | | the original |
			| | | author. |
			| RFC2821.MailFrom | Intermediate | The agent |
			| | Submitter | responsible for |
			| | | re-submission |
			| | | (RFC2822.Resent-Sen |
			| | | der) is also |
			| | | responsible for |
			| | | specifying the new |
			| | | RFC2821.MailFrom |
			| | | address. |
			| RFC2821.Rcpt-to | Recipient | This will contain |
			| | | the address of a |
			| | | new recipient |
			| RFC2822.Received | Intermediate | When re-sending a |
			| | Submitter | message, the |
			| | | submission agent |
			| | | may record a |
			| | | Received header, to |
			| | | indicate the |
			| | | transition from |
			| | | original posting to |
			| | | resubmission. |
			+----------------------+----------------------+---------------------+
	Table 5: ReSent Identities		Table 6: ReSent Identities
	5.2.3 MUA Reply		6.2.3 MUA Reply
	When a recipient formulates a response to a message, the new message		When a recipient formulates a response to a message, the new message
	is not typically viewed as being a "forwarding" of the original.		is not typically viewed as being a "forwarding" of the original.
	5.2.4 MUA Gateways		6.2.4 MUA Gateways
	Gateways perform the basic routing and transfer work of message		Gateways perform the basic routing and transfer work of message
	relaying, but they also make any message or address modifications		relaying, but they also make any message or address modifications
	that are needed to send the message into the next messaging		that are needed to send the message into the next messaging
	environment. When a gateway connects two differing messaging		environment. When a gateway connects two differing messaging
	services, its role is easy to identify and understand. When it		services, its role is easy to identify and understand. When it
	connects environments that have technical similarity, but may have		connects environments that have technical similarity, but may have
	significant administrative differences, it is easy to think that a		significant administrative differences, it is easy to think that a
	gateway is merely an MTA. The critical distinguish between an MTA		gateway is merely an MTA. The critical distinguish between an MTA
	and a gateway is that the latter modifies addresses and/or message		and a gateway is that the latter modifies addresses and/or message
	content.		content.
	A gateway may set any identity field available to a regular MUA.		A gateway may set any identity field available to a regular MUA.
	Identities typically set by gateways include		Identities typically set by gateways include
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| Identity | Role |		| Identity | Actor | Description |
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| RFC2822.From | Names and email addresses for |		| RFC2822.From | Originator | Names and email |
	| | the original author(s) of the |		| | | addresses for the |
	| | message content are retained. |		| | | original author(s) |
	| | As for all original addressing |		| | | of the message |
	| | information in the message, the |		| | | content are |
	| | gateway may translate addresses |		| | | retained. As for |
	| | in whatever way will allow them |		| | | all original |
	| | continue to be useful in the |		| | | addressing |
	| | target environment. |		| | | information in the |
	| RFC2822.Reply-To | The gateway should retain this |		| | | message, the |
	| | information, if it is |		| | | gateway may |
	| | originally present. The ability |		| | | translate addresses |
	| | to perform a successful reply |		| | | in whatever way |
	| | by a gatewayed recipient is a |		| | | will allow them |
	| | typical test of gateway |		| | | continue to be |
	| | functionality. |		| | | useful in the |
	| RFC2822.Sender | This may retain the original |		| | | target environment. |
	| | value or may be set to a new |		| RFC2822.Reply-To | Originator | The gateway should |
	| | address |		| | | retain this |
	| RFC2822.TO, RFC2822.CC, | These usually retain their |		| | | information, if it |
	| RFC2822.BCC | original addresses. |		| | | is originally |
	| RFC2821.MailFrom | The agent responsible for |		| | | present. The |
	| | gatewaying the message may |		| | | ability to perform |
	| | choose to specify a new address |		| | | a successful reply |
	| | to receive handling notices. |		| | | by a gatewayed |
	| RFC2822.Received | The gateway may record a |		| | | recipient is a |
	| | Received header, to indicate |		| | | typical test of |
	| | the transition from original |		| | | gateway |
	| | posting to the new messaging |		| | | functionality. |
	| | environment. |		| RFC2822.Sender | Submitter | This may retain the |
	+---------------------------------+---------------------------------+		| | | original value or |
			| | | may be set to a new |
			| | | address |
			| RFC2822.TO, | Recipient | These usually |
			| RFC2822.CC, | | retain their |
			| RFC2822.BCC | | original addresses. |
			| RFC2821.MailFrom | Submitter | The agent |
			| | | responsible for |
			| | | gatewaying the |
			| | | message may choose |
			| | | to specify a new |
			| | | address to receive |
			| | | handling notices. |
			| RFC2822.Received | Forwarder | The gateway may |
			| | | record a Received |
			| | | header, to indicate |
			| | | the transition from |
			| | | original posting to |
			| | | the new messaging |
			| | | environment. |
			+----------------------+----------------------+---------------------+
	Table 6: Gateway Identities		Table 7: Gateway Identities
	5.2.5 MUA Alias Handling		6.2.5 MUA Alias Handling
	A simple re-addressing facility that is available in most MDA		A simple re-addressing facility that is available in most MDA
	implementations is called Aliasing. It is performed just before		implementations is called Aliasing. It is performed just before
	placing a message into the specified recipient's inbox. Instead, the		placing a message into the specified recipient's inbox. Instead, the
	message is submitted back to the transfer service, for delivery to		message is submitted back to the transfer service, for delivery to
	one or more alternate addresses. Although implemented as part of the		one or more alternate addresses. Although implemented as part of the
	message delivery service, this facility is strictly a recipient user		message delivery service, this facility is strictly a recipient user
	function. In effect it resubmits the message to a new address, on		function. In effect it resubmits the message to a new address, on
	behalf of the listed recipient.		behalf of the listed recipient.
	What is most distinctive about this forwarding mechanism is how		What is most distinctive about this forwarding mechanism is how
	closely it compares to normal MTA store-and-forward. In reality its		closely it compares to normal MTA store-and-forward. In reality its
	only interesting difference is that it changes the RFC2821.RCPT-TO		only interesting difference is that it changes the RFC2821.RCPT-TO
	value. Notably it does not typically change the RFC2821.Mailfrom		value. Notably it does not typically change the RFC2821.Mailfrom
	An MDA that is re-posting a message to an alias typically changes		An MDA that is re-posting a message to an alias typically changes
	only envelope information:		only envelope information:
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| Identity | Role |		| Identity | Actor | Description |
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| RFC2822.TO, RFC2822.CC, | These retain their original |		| RFC2822.TO, | Recipient | These retain their |
	| RFC2822.BCC | addresses. |		| RFC2822.CC, | | original addresses. |
	| RFC2821.Rcpt-To | This field contains an alias |		| RFC2822.BCC | | |
	| | address. |		| RFC2821.Rcpt-To | Recipient | This field contains |
	| RFC2821.MailFrom | The agent responsible for |		| | | an alias address. |
	| | submission to an alias address |		| RFC2821.MailFrom | Intermediate | The agent |
	| | will usually retain the |		| | Submitter | responsible for |
	| | original address to receive |		| | | submission to an |
	| | handling notifications. The |		| | | alias address will |
	| | benefit of retaining the |		| | | usually retain the |
	| | original MailFrom value is to |		| | | original address to |
	| | ensure that the |		| | | receive handling |
	| | origination-side agent knows of |		| | | notifications. The |
	| | that there has been a delivery |		| | | benefit of |
	| | problem. On the other hand, the |		| | | retaining the |
	| | responsibility for the problem |		| | | original MailFrom |
	| | usually lies with the |		| | | value is to ensure |
	| | recipient, since the Alias |		| | | that the |
	| | mechanism is strictly under the |		| | | origination-side |
	| | recipient's control. |		| | | agent knows of that |
	| RFC2821.Received | The agent should record |		| | | there has been a |
	| | Received information, to |		| | | delivery problem. |
	| | indicate the delivery to the |		| | | On the other hand, |
	| | original address and submission |		| | | the responsibility |
	| | to the alias address. The trace |		| | | for the problem |
	| | of Received headers should |		| | | usually lies with |
	| | include everything from |		| | | the recipient, |
	| | original posting through final |		| | | since the Alias |
	| | delivery to the alias. |		| | | mechanism is |
	+---------------------------------+---------------------------------+		| | | strictly under the |
			| | | recipient's |
			| | | control. |
			| RFC2821.Received | Intermediate | The agent should |
			| | Recipient | record Received |
			| | | information, to |
			| | | indicate the |
			| | | delivery to the |
			| | | original address |
			| | | and submission to |
			| | | the alias address. |
			| | | The trace of |
			| | | Received headers |
			| | | should include |
			| | | everything from |
			| | | original posting |
			| | | through final |
			| | | delivery to the |
			| | | alias. |
			+----------------------+----------------------+---------------------+
	Table 7: Alias Identities		Table 8: Alias Identities
	5.2.6 MUA Mailing Lists		6.2.6 MUA Mailing Lists
	Mailing lists have explicit email addresses and forward messages to a		Mailing lists have explicit email addresses and forward messages to a
	list of subscribed members. Mailing list processing is a user-level		list of subscribed members. Mailing list processing is a user-level
	activity, outside of the core email transfer service. The mailing		activity, outside of the core email transfer service. The mailing
	list address is, therefore, associated with a distinct user-level		list address is, therefore, associated with a distinct user-level
	entity that can perform arbitrary actions upon the original message,		entity that can perform arbitrary actions upon the original message,
	before submitting it to the mailing list membership. Hence, mailing		before submitting it to the mailing list membership. Hence, mailing
	lists are similar to gateways.		lists are similar to gateways.
	Identities set by a mailing list processor, when submitting a		Identities set by a mailing list processor, when submitting a
	message, include:		message, include:
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| Identity | Role |		| Identity | Actor | Description |
	+---------------------------------+---------------------------------+		+----------------------+----------------------+---------------------+
	| RFC2919.List-id | This provides a global mailing |		| RFC2919.List-id | -- | This provides a |
	| | list naming framework that is |		| | | global mailing list |
	| | independent of particular |		| | | naming framework |
	| | hosts. Although [RFC2919] is a |		| | | that is independent |
	| | standards-track specification, |		| | | of particular |
	| | it has not gained significant |		| | | hosts. Although |
	| | adoption. |		| | | [RFC2919] is a |
	| RFC2369.List-* | [RFC2369] defines a collection |		| | | standards-track |
	| | of message headers for use by |		| | | specification, it |
	| | mailing lists. In effect, they |		| | | has not gained |
	| | supply list-specific parameters |		| | | significant |
	| | for common mailing list user |		| | | adoption. |
	| | operations. The identifiers for |		| RFC2369.List-* | Recipient | [RFC2369] defines a |
	| | these operations are for the |		| | | collection of |
	| | list, itself, and the |		| | | message headers for |
	| | user-as-subscriber. |		| | | use by mailing |
	| RFC2822.From | Names and email addresses for |		| | | lists. In effect, |
	| | the original author(s) of the |		| | | they supply |
	| | message content are specified. |		| | | list-specific |
	| RFC2822.Reply-To | Mailing lists have introduced |		| | | parameters for |
	| | an ambiguity for the Reply-To |		| | | common mailing list |
	| | field. Some List operations |		| | | user operations. |
	| | choose to force all replies to |		| | | The identifiers for |
	| | go to all list members. They |		| | | these operations |
	| | achieve this by placing the |		| | | are for the list, |
	| | list address into the |		| | | itself, and the |
	| | RFC2822.Reply-To field. Hence, |		| | | user-as-subscriber. |
	| | direct, "private" replies only |		| | | |
	| | to the original author cannot |		| RFC2822.From | Originator | Names and email |
	| | be achieved by using the MUA's |		| | | addresses for the |
	| | typical "reply to author" |		| | | original author(s) |
	| | function. If the author created |		| | | of the message |
	| | a Reply-To field, its |		| | | content are |
	| | information is lost. |		| | | specified. |
	| RFC2822.Sender | This will usually specify the |		| RFC2822.Reply-To | Originator | Mailing lists have |
	| | address of the agent |		| | | introduced an |
	| | responsible for mailing list |		| | | ambiguity for the |
	| | operations. However, some |		| | | Reply-To field. |
	| | mailing lists operate in a |		| | | Some List |
	| | manner very similar to a simple |		| | | operations choose |
	| | MTA relay, so that they |		| | | to force all |
	| | preserve as much of the |		| | | replies to go to |
	| | original handling information |		| | | all list members. |
	| | as possible, including the |		| | | They achieve this |
	| | original RFC2822.Sender field. |		| | | by placing the list |
	| RFC2822.TO, RFC2822.CC | These will usually contain the |		| | | address into the |
	| | original list of recipient |		| | | RFC2822.Reply-To |
	| | addresses. |		| | | field. Hence, |
	| RFC2821.MailFrom | This may contain the original |		| | | direct, "private" |
	| | address to be notified of |		| | | replies only to the |
	| | transmission issues, or the |		| | | original author |
	| | mailing list agent may set it |		| | | cannot be achieved |
	| | to contain a new notification |		| | | by using the MUA's |
	| | address. Typically, the value |		| | | typical "reply to |
	| | is set to a new address, so |		| | | author" function. |
	| | that mailing list members and |		| | | If the author |
	| | posters are not burdened with |		| | | created a Reply-To |
	| | transmission-related |		| | | field, its |
	| | notifications. |		| | | information is |
	| RFC2821.Rcpt-To | This contain the address of a |		| | | lost. |
	| | mailing list member. |		| RFC2822.Sender | Submitter | This will usually |
	| RFC2821.Received | An Mailing List Agent should |		| | | specify the address |
	| | record a Received header, to |		| | | of the agent |
	| | indicate the transition from |		| | | responsible for |
	| | original posting to mailing |		| | | mailing list |
	| | list forwarding. The Agent may |		| | | operations. |
	| | choose to have the message |		| | | However, some |
	| | retain the original set of |		| | | mailing lists |
	| | Received headers or may choose |		| | | operate in a manner |
	| | to remove them. In the latter |		| | | very similar to a |
	| | case, it should ensure that the |		| | | simple MTA relay, |
	| | original Received headers are |		| | | so that they |
	| | otherwise available, to ensure |		| | | preserve as much of |
	| | later accountability and |		| | | the original |
	| | diagnostic access to it. |		| | | handling |
	+---------------------------------+---------------------------------+		| | | information as |
			| | | possible, including |
			| | | the original |
			| | | RFC2822.Sender |
			| | | field. |
			| RFC2822.TO, | Intermediate | These will usually |
			| RFC2822.CC | Recipient | contain the |
			| | | original list of |
			| | | recipient |
			| | | addresses. |
			| RFC2821.MailFrom | Intermediate | This may contain |
			| | Submitter | the original |
			| | | address to be |
			| | | notified of |
			| | | transmission |
			| | | issues, or the |
			| | | mailing list agent |
			| | | may set it to |
			| | | contain a new |
			| | | notification |
			| | | address. Typically, |
			| | | the value is set to |
			| | | a new address, so |
			| | | that mailing list |
			| | | members and posters |
			| | | are not burdened |
			| | | with |
			| | | transmission-relate |
			| | | d notifications. |
			| RFC2821.Rcpt-To | Recipient | This contain the |
			| | | address of a |
			| | | mailing list |
			| | | member. |
			| RFC2821.Received | Intermediate | An Mailing List |
			| | Recipient | Agent should record |
			| | | a Received header, |
			| | | to indicate the |
			| | | transition from |
			| | | original posting to |
			| | | mailing list |
			| | | forwarding. The |
			| | | Agent may choose to |
			| | | have the message |
			| | | retain the original |
			| | | set of Received |
			| | | headers or may |
			| | | choose to remove |
			| | | them. In the latter |
			| | | case, it should |
			| | | ensure that the |
			| | | original Received |
			| | | headers are |
			| | | otherwise |
			| | | available, to |
			| | | ensure later |
			| | | accountability and |
			| | | diagnostic access |
			| | | to it. |
			+----------------------+----------------------+---------------------+
	Table 8: Mailing List Identities		Table 9: Mailing List Identities
	6. Security Considerations		7. Security Considerations
	This document does not specify any new Internet mail functionality.		This document does not specify any new Internet mail functionality.
	Consequently it should introduce no new security considerations.		Consequently it should introduce no new security considerations.
	However its discussion of the roles and responsibilities for		However its discussion of the roles and responsibilities for
	different mail service modules, and the information they create,		different mail service modules, and the information they create,
	highlights the considerable security considerations that must be		highlights the considerable security considerations that must be
	present when implementing any component of the Internet mail service.		present when implementing any component of the Internet mail service.
	7 References		8 References
	[I-D.hutzler-spamops]
	Hutzler, C., Crocker, D., Resnick, P., Sanderson, R. and
	E. Allman, "Email Submission Between Independent
	Networks", draft-hutzler-spamops-00 (work in progress),
	March 2004.
	[ID-HDR-Reg]		[ID-hdr-reg]
	"Registration of mail and MIME header fields",		"Registration of mail and MIME header fields",
	draft-klyne-hdrreg-mail-04.txt (work in progress), Apr		draft-klyne-hdrreg-mail-04.txt (work in progress), Apr
	2004.		2004.
	[ID-SPAMOPS]		[ID-marid-core]
	Hutzler, C., Crocker, D., Resnick, P., Sanders, R. and E.		Lyon, J. and M. Wong, "MTA Authentication Records in DNS",
	Allman, "Email Submission Between Independent Networks",		draft-ietf-marid-core-01.txt (work in progress), June
	I-D draft-hutzler-spamops-00.txt, March 2004.		2004.
			[ID-spamops]
			Hutzler, C., Crocker, D., Resnick, P., Sanderson, R. and
			E. Allman, "Email Submission Between Independent
			Networks", draft-spamops-00 (work in progress), March
			2004.
	[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC		[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
	821, August 1982.		821, August 1982.
	[RFC0822] Crocker, D., "Standard for the format of ARPA Internet		[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
	text messages", STD 11, RFC 822, August 1982.		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 22, line 37 ¶		skipping to change at page 33, line 25 ¶
	Internet Mail Extensions (MIME) Part Four: Registration		Internet Mail Extensions (MIME) Part Four: Registration
	Procedures", BCP 13, RFC 2048, November 1996.		Procedures", BCP 13, RFC 2048, November 1996.
	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Five: Conformance Criteria and		Extensions (MIME) Part Five: Conformance Criteria and
	Examples", RFC 2049, November 1996.		Examples", RFC 2049, November 1996.
	[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.
			[RFC2298] Fajman, R., "An Extensible Message Format for Message
			Disposition Notifications", RFC 2298, March 1998.
	[RFC2304] Allocchio, C., "Minimal FAX address format in Internet		[RFC2304] Allocchio, C., "Minimal FAX address format in Internet
	Mail", RFC 2304, March 1998.		Mail", RFC 2304, March 1998.
	[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.
	[RFC2421] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet		[RFC2421] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
	Mail - version 2", RFC 2421, September 1998.		Mail - version 2", RFC 2421, September 1998.
	skipping to change at page 23, line 23 ¶		skipping to change at page 34, line 15 ¶
	[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, April		[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
	2001.		2001.
	[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field		[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
	and Namespace for the Identification of Mailing Lists",		and Namespace for the Identification of Mailing Lists",
	RFC 2919, March 2001.		RFC 2919, March 2001.
			[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC
			3028, January 2001.
			[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
			Extension for Delivery Status Notifications (DSNs)", RFC
			3461, January 2003.
	[RFC3501] Crispin, M., "Internet Message Access Protocol - Version		[RFC3501] Crispin, M., "Internet Message Access Protocol - Version
	4rev1", RFC 3501, March 2003.		4rev1", RFC 3501, March 2003.
			[2] <Forwarder>
	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
	Phone: +1.408.246.8253		Phone: +1.408.246.8253
	EMail: dcrocker@brandenburg.com		EMail: dcrocker@brandenburg.com
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The Email Architecture section derives from draft-hutzler-spamops		The Email Architecture section derives from draft-hutzler-spamops
	[ID-SPAMOPS]. The text has been further elaborated.		[ID-spamops]. The text has been further elaborated.
			Discussion of the Submitter actor role was greatly clarified by
			[ID-marid-core]. Reference to this role has been written to align
			with that document's label and discussion.
	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 early drafts.		insight on the framework and details of early drafts. Additional
			review and suggestions have been provided by Nathaniel Borenstein,
			Chris Newman, Eric Hall, Tony Finch, Ed Bradford, Cyrus Daboo, Ned
			Freed.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the procedures with respect to rights in RFC documents can be
	standards-related documentation can be found in BCP-11. Copies of		found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 86 change blocks.
	539 lines changed or deleted		1015 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/