rfc9228xml2.original.xml		rfc9228.xml
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!--<!DOCTYPE rfc SYSTEM "RFC2629.dtd"[]>-->
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc strict="no"?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="2"?>
	<?rfc tocindent="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>
	<?rfc inline="yes"?>
	<?rfc topblock="yes" ?>
	<?rfc autobreaks="yes" ?>
	<rfc category="exp" docName="draft-crocker-email-deliveredto-10" ipr="trust20090
	2" submissionType="independent">
	<front>
	<title abbrev="react">Delivered-To Email Header Field</title>
	<author fullname="Dave Crocker" initials="D." surname="Crocker" role="ed		<!-- [CS] updated by Chris 03/01/22 -->
	itor">
	<organization>Brandenburg InternetWorking</organization>
	<address>
	<email>dcrocker@bbiw.net</email>
	</address>
	</author>
	<date year="2022"/>		<!DOCTYPE rfc [
	<area>Applications and Real-Time</area>		<!ENTITY nbsp "&#160;">
	<workgroup/>		<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
	<keyword>handling</keyword>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-crocker-email-del
	<keyword>email</keyword>		iveredto-10" number="9228" ipr="trust200902" submissionType="independent" catego
	<keyword>mhs</keyword>		ry="exp" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" updates="
	<keyword>recipient</keyword>		" obsoletes="" xml:lang="en" version="3">
	<keyword>transport</keyword>
	<keyword>delivery</keyword>
	<keyword>mda</keyword>
	<keyword>mta</keyword>
	<keyword>relay</keyword>
	<keyword>header</keyword>
	<abstract>		<!-- xml2rfc v2v3 conversion 3.12.2 -->
	<t>The address to which email is delivered might be different than a		<front>
	ny of the addresses shown in any of the		<title abbrev="Delivered-To Header Field">Delivered-To Email Header Field</t
			itle>
			<seriesInfo name="RFC" value="9228"/>
			<author fullname="Dave Crocker" initials="D." surname="Crocker" role="editor
			">
			<organization>Brandenburg InternetWorking</organization>
			<address>
			<email>dcrocker@bbiw.net</email>
			</address>
			</author>
			<date year="2022" month="April" />
			<keyword>handling</keyword>
			<keyword>email</keyword>
			<keyword>mhs</keyword>
			<keyword>recipient</keyword>
			<keyword>transport</keyword>
			<keyword>delivery</keyword>
			<keyword>mda</keyword>
			<keyword>mta</keyword>
			<keyword>relay</keyword>
			<keyword>header</keyword>
			<abstract>
			<t>The address to which email is delivered might be different than any of
			the addresses shown in any of the
	content header fields that were created by the email's author. F or example, the address used by the		content header fields that were created by the email's author. F or example, the address used by the
	email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not		email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not
	match any address in the To: or cc: fields. In addition before f inal delivery, handling can entail a		match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a
	sequence of submission/delivery events, using a sequence of diff erent destination addresses that		sequence of submission/delivery events, using a sequence of diff erent destination addresses that
	(eventually) lead to the recipient. As well, a receiving system' s delivery process can produce local		(eventually) lead to the recipient. As well, a receiving system' s delivery process can produce local
	address transformations.</t>		address transformations.</t>
			<t> It can be helpful for a message to have a common way to record each de
	<t> It can be helpful for a message to have a common way to record e		livery in such a sequence, noting each address used in the sequence to that reci
	ach delivery in such a sequence, and to		pient, such as for (1) analyzing the path a message has taken, (2) loop detectio
	note each address used in the sequence to that recipient, such a		n, or (3) formulating the author's address in a reply message. This document
	s for analyzing the path a message has
	taken, or for loop detection, or for formulating the author's ad
	dress in a reply message. This document
	defines a header field for this information.</t>		defines a header field for this information.</t>
			<t>Email handling information discloses details about the email infrastruc
	<t>Email handling information discloses details about the email infr		ture, as well as about a
	astructure, as well as about a
	particular recipient; this can raise privacy concerns.</t>		particular recipient; this can raise privacy concerns.</t>
			<t>A header field such as this is not automatically assured of widespread
	<t>A header field such as this is not automatically assured of wides		use. Therefore, this document is being
	pread use. Therefore this is being		published as an Experimental RFC, looking for constituency and f
	published as an Experiment, looking for constituency and for ope		or operational utility. This document was
	rational utility. The document is		produced through the Independent Submission Stream and was not s
	produced through the Independent RFC stream and was not subject		ubject to the IETF's approval process.</t>
	to the IETF's approval process.</t>		</abstract>
	</abstract>		</front>
	</front>		<middle>
			<section>
	<middle>		<name>Introduction</name>
	<section title="Introduction">		<t>The address to which email is delivered might be different than any of
	<t>The address to which email is delivered might be different than a		the addresses shown in any of the
	ny of the addresses shown in any of the		content header fields <xref target="RFC5322"/>, such as the To:
	content header fields <xref target="Mail-Fmt"/>, such as the To:		and cc: fields that were created by the
	and cc: fields that were created by the		author's Message User Agent (MUA) <xref target="RFC5598"/>.
	author's Mail User Agent (MUA) <xref target="Mail-Arch"/>. The a		The address used by the Message Handling
	ddress used by the Message Handling		Service (MHS) is provided separately, in envelope information, s
	Service (MHS) is provided separately, in envelope information, s		uch as through a "RCPT TO" command in
	uch as through an "RCPT TO" command in		<xref target="RFC5321"/>.</t>
	<xref target="SMTP"/>.</t>		<t>As noted in <xref target="RFC5598" section="4.3.3"></xref>, 'A transfer
			of responsibility from the MHS to a Recipient's environment (mailbox) is called
	<t>Delivery is a transition of responsibility for a message, from th		"delivery".'
	e MHS, over to an agent of the
	destination, as represented by the envelope address (<xref targe
	t="Mail-Arch">Section 4.3.3</xref>).
	That is, when the destination address is fully and successfully processed, and any additional processing		That is, when the destination address is fully and successfully processed, and any additional processing
	is by an agent working on behalf of that address, the message ha s been delivered. Rather than placing		is by an agent working on behalf of that address, the message ha s been delivered. Rather than placing
	the message into a recipient inbox, or otherwise completing the		the message into a recipient inbox or otherwise completing the h
	handling of the message, that agent		andling of the message, that agent
	might create additional processing, including to one or more, di		might create additional processing, including to one or more dif
	fferent addresses. Each transition of		ferent addresses.
			Each transition of
	responsibility, from the MHS to an agent of a current addressee, constitutes a distinct delivery. Given		responsibility, from the MHS to an agent of a current addressee, constitutes a distinct delivery. Given
	handling sequences that can include aliasing, mailing lists, and the like, the transit of a message from		handling sequences that can include aliasing, mailing lists, and the like, the transit of a message from
	its author to a final recipient might include a series of submis sion/delivery events. Also, the delivery		its author to a final recipient might include a series of submis sion/delivery events. Also, the delivery
	process at a receiving system can produce local (internal) addre ss transformations. </t>		process at a receiving system can produce local (internal) addre ss transformations. </t>
			<t>Header fields that provide information about handling can be used when
	<t>Header fields that provide information about handling can be used		assessing email traffic issues and
	when assessing email traffic issues and
	when diagnosing specific handling problems. To this end, it can be helpful for a message to have a		when diagnosing specific handling problems. To this end, it can be helpful for a message to have a
	common way of indicating each delivery in the handling sequence,		common way to indicate each delivery in the handling sequence an
	and to include each address that led to		d to include each address that led to
	the final delivery. This can aid in the analysis of a message's		the final delivery.
	transit handling. </t>		This can aid in the analysis of a message's transit handling. </t>
			<t>An additional use can be to aid in detecting a delivery sequence loop,
	<t>An additional use can as be an aid in detecting a delivery sequen		based on a specific address.
	ce loop, based on a specific address.
	With a problematic loop, the same copy of a message is delivered to the same email address more than		With a problematic loop, the same copy of a message is delivered to the same email address more than
	once. This is different from having different copies delivered t o the same address, such as happens when		once. This is different from having different copies delivered t o the same address, such as happens when
	a message is sent directly to an address, as well as via a maili ng list. It is also different from		a message is sent directly to an address, as well as via a maili ng list. It is also different from
	having two copies of the same message arrive at the same, ultima te destination address, having been		having two copies of the same message arrive at the same, ultima te destination address, having been
	originally posted to two different addresses. Further, this is d ifferent from noting when a message		originally posted to two different addresses. Further, this is d ifferent from noting when a message
	simply transits the same MTA more than once, which might be nece ssary, such as when it is processed		simply transits the same Message Transfer Agent (MTA) more than once, which might be necessary, such as when it is processed
	through a mailing list; an MTA services many addresses. </t>		through a mailing list; an MTA services many addresses. </t>
			<t>Delivering the same copy of a message more than once, to the same addre
	<t>Delivering the same copy of a message more than once, to the same		ss, is almost certainly not an
	address, is almost certainly not an
	intended activity. An example of a problematic arrangement would be to send a message to mailing list		intended activity. An example of a problematic arrangement would be to send a message to mailing list
	List-A, where List-A contains an entry for List-B, and List-B co ntains an entry for List-A. The message		List-A, where List-A contains an entry for List-B, and List-B co ntains an entry for List-A. The message
	will enter an infinite loop. Loop detection for email can be a c omplicated affair. The Delivered-To:		will enter an infinite loop. Loop detection for email can be a c omplicated affair. The Delivered-To:
	header field provides helpful information, with a definitive ind ication that this copy of a message has		header field provides helpful information, with a definitive ind ication that this copy of a message has
	(already) been delivered to a specific address.</t>		(already) been delivered to a specific address.</t>
			<t>When specifying new activity that is related to existing activity, ther
	<t>When specifying new activity that is related to existing activity		e is a choice of design approach:
	, there is a choice of design approach:		</t>
	<list style="symbols">		<ul spacing="normal">
	<t>Seeking to change (some) of the existing behavior</t>		<li>Seeking to change (some of) the existing behavior</li>
	<t>Adding to the activity without changing what is already b		<li>Adding to the activity without changing what is already being done</
	eing done</t>		li>
	<t>Calling for separate, new activity</t>		<li>Calling for separate, new activity</li>
	</list>On the average, attempting to change existing activities		</ul>
	is the least likely to obtain adoption;		<t>On the average, attempting to change existing activities is the least l
			ikely to obtain adoption;
	it can create operational confusion between old and new activiti es, which in turn creates resistance to		it can create operational confusion between old and new activiti es, which in turn creates resistance to
	adoption. Seeking new activity can make sense when that activity is sufficiently different and deemed		adoption. Seeking new activity can make sense when that activity is sufficiently different and deemed
	sufficiently beneficial. Adding to existing activity has the sel ling point of building upon an installed		sufficiently beneficial. Adding to existing activity has the sel ling point of building upon an installed
	base. The current specification builds upon an existing installe d base of Delivered-To: activity. It		base. The current specification builds upon an existing installe d base of Delivered-To: activity. It
	calls for little technical enhancement, but rather, it simply pr ovides for wider range of		calls for little technical enhancement; rather, it simply provid es for a wider range of
	application.</t>		application.</t>
			<t>Considerations: </t>
	<t>Considerations: <list style="symbols">		<ul spacing="normal">
	<t>Email handling information, such as this, provides inform		<li>Email handling information, such as this, provides information about
	ation about the email infrastructure, as		the email infrastructure, as
	well as about the recipient. Disclosure of this informat		well as about the recipient. Disclosure of this informat
	ion might engender privacy concerns.</t>		ion might engender privacy concerns.</li>
	<t>A specification, is not automatically assured of adoption		<li>A specification is not automatically assured of adoption or use. The
	or use. Therefore it is being published		refore, this document is being published
	as an Experiment, looking for extended constituency and		as an Experimental RFC, looking for extended constituenc
	for general operational utility.</t>		y and for general operational utility.</li>
	<t>This document was produced through the Independent RFC st		<li>This document was produced through the Independent RFC Stream and wa
	ream and was not subject to the IETF's		s not subject to the IETF's
	approval process.</t>		approval process.</li>
	</list></t>		</ul>
			</section>
	</section>		<section>
			<name>Background</name>
	<section title="Background">		<t>Ad hoc use of a Delivered-To: email header field appears to date back t
	<t>Ad hoc use of a "Delivered-To:" email header field appears to dat		o the 1990s, primarily for loop
	e back to the 1990s, primarily for loop		detection, although documentation is spotty and system specific.
	detection, although documentation is spotty and system-specific.		A listing of some implementations is
	A listing of some implementations is
	offered in <xref target="Prior"/>.</t>		offered in <xref target="Prior"/>.</t>
			<t>It appears that all uses include a string in the form of an email addre
	<t>It appears that all uses include a string in the form of an email		ss, although at least one example
	address, although at least one example
	has leading text that is a comment about the address. In some ca ses, the string appears to be the email		has leading text that is a comment about the address. In some ca ses, the string appears to be the email
	transport destination address, such as used in SMTP's "RCPT TO"		transport destination address, such as the address used in SMTP'
	command. In other cases, it appears to		s "RCPT TO" command.
			In other cases, it appears to
	be the result of some internal mapping at the receiving system, although tending to be a variant of the		be the result of some internal mapping at the receiving system, although tending to be a variant of the
	transport address.</t>		transport address.</t>
			<t>Email loop detection tends to be accomplished through a variety of diff
	<t>Email loop detection tends to be accomplished through a variety o		erent methods, such as counting
	f different methods, such as counting
	Received: header fields. These methods are often combined to gre ater effect. </t>		Received: header fields. These methods are often combined to gre ater effect. </t>
			<t>The Received: header field's 'for' clause is sometimes useful for discl
	<t>The Received: header field's 'for' clause is sometimes useful for		osing the recipient's address.
	disclosing the recipient's address.		However, the clause is not used reliably, and its semantics are
	However the clause is not used reliably and its semantics are no		not thoroughly defined. Also, it references
	t thoroughly defined. Also it references		an addressing value that is received but might be different from
	an addressing value that is received, but might be different fro		the value that is ultimately used (as
	m the value that is ultimately used (as		the result of a transformation).
	the result of a transformation.) That is, the value in a 'for' c		That is, the value in a 'for' clause might be a sufficient indicator of
	lause might be a sufficient indicator of
	delivery addressing, but it might not.</t>		delivery addressing, but it might not.</t>
			</section>
	</section>		<section>
			<name>Framework &amp; Terminology</name>
	<section title="Framework &amp; Terminology">		<t>Unless otherwise indicated, basic architecture and terminology used in
	<t>Unless otherwise indicated, basic architecture and terminology us		this document are taken from:</t>
	ed in this document are taken from:<list		<ul spacing="normal">
	style="symbols">		<li>
	<t><xref target="Mail-Arch"/></t>		<xref target="RFC5598"/></li>
	<t><xref target="SMTP"/></t>		<li>
	<t><xref target="Mail-Fmt"/></t>		<xref target="RFC5321"/></li>
	</list> and syntax is specified with: <list style="symbols">		<li>
	<t><xref target="ABNF"/></t>		<xref target="RFC5322"/></li>
	</list></t>		</ul>
			<t> and syntax is specified with: </t>
	<t>Normative language, is per <xref target="RFC8174"/>: <list>		<ul spacing="normal">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "S		<li>
	HALL NOT", "SHOULD", "SHOULD NOT",		<xref target="RFC5234"/></li>
	"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"		</ul>
	in this document are to be interpreted		<t>Normative language is per <xref target="RFC8174"/>: </t>
	as described in BCP 14 <xref target="RFC2119"/>		<t indent="3">
	<xref target="RFC8174"/> when, and only when, they appea		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	r in all capitals, as shown here.</t>		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	</list></t>		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
			"<bcp14>SHOULD NOT</bcp14>",
	</section>		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	<section title="Delivered-To">		are to be interpreted as described in BCP&nbsp;14
	<t>The "Delivered-To:" header field annotates an email delivery even		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
	t. The header field contains information		when, they appear in all capitals, as shown here.
	about the individual address used to effect that transition.<lis		</t>
	t style="symbols">		</section>
	<t>When a message is delivered, as a transition from control		<section>
	by the MHS to the recipient's store or		<name>Delivered-To</name>
	their agent, a Delivered-To: header field SHOULD be adde		<t>The Delivered-To: header field annotates an email delivery event. The h
	d, with the <spanx>addr-spec</spanx>		eader field contains information
	value containing the address that was used by the servic		about the individual address used to effect that transition.</t>
	e to reach the recipient.</t>		<ul spacing="normal">
	<t>If a receiving system's delivery process applies mappings		<li>When a message is delivered, as a transition from control by the MHS
	or transformations, from the address		to the recipient's store or
	used by the MHS, to a local value, this new value SHOULD		their agent, a Delivered-To: header field <bcp14>SHOULD<
	also be recorded into a separate		/bcp14> be added, with the <em>addr-spec</em>
	Delivered-To: field, when transit and processing using t		value containing the address that was used by the servic
	hat addresses successfully completes.		e to reach the recipient.</li>
	This ensures a detailed record of the sequence of handli		<li>If a receiving system's delivery process applies mappings or transfo
	ng addresses used for the message.</t>		rmations from the address
	<t>As with some other information, each additional Delivered		used by the MHS to a local value, this new value <bcp14>
	-To: header field MUST be placed at the		SHOULD</bcp14> also be recorded into a separate
			Delivered-To: field when transit and processing using th
			at address successfully complete.
			This ensures a detailed record of the sequence of handli
			ng addresses used for the message.</li>
			<li>As with some other information, each additional Delivered-To: header
			field <bcp14>MUST</bcp14> be placed at the
	current 'top' of the message's set of header fields -- t hat is, as the first header field, in a		current 'top' of the message's set of header fields -- t hat is, as the first header field, in a
	fashion similar to the trace fields specified in <xref t
	arget="SMTP"/>, such as in its Section		fashion similar to the trace fields specified in <xref t
	4.1.1.4. This produces a sequence of Delivered-To: heade		arget="RFC5321"/> (for example, <xref target="RFC5321" section="4.1.1.4"/>). Thi
	r fields that represent the sequence of		s produces a sequence of Delivered-To: header fields that represent the sequence
			of
	deliveries, with the first being at the 'bottom' of the sequence and the final one being at the		deliveries, with the first being at the 'bottom' of the sequence and the final one being at the
	top.</t>		top.</li>
	<t>As with other fields placed incrementally in this way, wi		<li>As with other fields placed incrementally in this way, with each add
	th each added at the current top, the		ed at the current top, the
	Delivered-To: header field MUST NOT be reordered with re		Delivered-To: header field <bcp14>MUST NOT</bcp14> be re
	spect to other Delivered-To: fields and		ordered with respect to other Delivered-To: fields and
	those other fields. This is intended to preserve the fie lds as representing the message handling		those other fields. This is intended to preserve the fie lds as representing the message handling
	sequence.</t>		sequence.</li>
	</list></t>		</ul>
			<t>The Delivered-To: header field is added at the time of delivery, when r
	<t>The Delivered-To: header field is added at the time of delivery,		esponsibility for a message
	when responsibility for a message		transitions from the Message Handling Service (MHS) to an agent
	transitions from the Message Handling (Transport) Service (MHS)		of the specified individual
	to an agent of the specified individual
	recipient address. The field can also be added as a result of in ternal system processing, to note		recipient address. The field can also be added as a result of in ternal system processing, to note
	address transformations.</t>		address transformations.</t>
			<aside><t>Note:
	<t>		The presence of an existing Delivered-To: header field, for the same add
	<list style="hanging">		ress,
	<t hangText="Note: ">The presence of an existing Delivered-		typically indicates a handling loop for this instance of
	To: header field, for the same address,		the message.</t></aside>
	typically indicates a handling loop for this instance of		<t>The syntax of the header field is: </t>
	the message.</t>		<sourcecode type="abnf"><![CDATA["Delivered-To:" FWS addr-spec FWS CRLF ;
	</list>		addr-spec is from [Mail-Fmt]
	</t>		]]></sourcecode>
			<t>The field records information about a single address, for one recipient
	<t>The syntax of the header field is: <figure>		. See <xref target="Security"/>
	<artwork type="ABNF">"Delivered-To:" FWS addr-spec FWS CRLF
	; addr-spec is from [Mail-Fmt]</artwork>
	</figure></t>
	<t>The field records information about a single address, for one rec
	ipient. See [<xref target="Security"/>]
	for the privacy-related concerns about divulging addresses.</t>		for the privacy-related concerns about divulging addresses.</t>
			</section>
	</section>		<section>
			<name>Multi-Delivery Example</name>
	<section title="Multi-delivery Example">		<t>The Delivered-To: header field can be used to document a sequence of de
	<t>The Delivered-To: header field can be used to document a sequence		liveries of a message. Each time
	of deliveries of a message. Each time
	an address is fully processed, a Delivered-To: header field is a dded, recording a handling sequence,		an address is fully processed, a Delivered-To: header field is a dded, recording a handling sequence,
	with the most recent one being towards the 'top' of the sequence of header fields.</t>		with the most recent one being towards the 'top' of the sequence of header fields.</t>
			<t>This example demonstrates a message traveling from its original posting
	<t>This example demonstrates a message traveling from its original p		, through a remote group mailing
	osting, through a remote group mailing
	list, on through an independent personal aliasing mechanism, and then reaching final delivery at yet		list, on through an independent personal aliasing mechanism, and then reaching final delivery at yet
	another independent email provider. <list style="numbers">		another independent email provider. </t>
	<t>Origination @ com.example <list style="empty">		<ol spacing="normal" type="1"><li>
	<t>The message, as submitted. The destination addres		<t>Origination at com.example </t>
	s is the same as the value in the		<t indent="3">
			The message, as submitted. The destination address is the same as th
			e value in the
	message's To: header field.</t>		message's To: header field.</t>
	</list>		<!-- Timestamp updated per author email dated 2/19/2022 7:34 AM -->
	<figure>		<artwork><![CDATA[From: Ann Author <aauthor@com.example>
	<artwork><![CDATA[From: Ann Author <aauthor@com.exam		Date: Mon, 25 Jan 2021 18:29:06 -0500
	ple>
	Date: Mon, 25 Jan 2021 18:29:00 -0500
	To: list@org.example		To: list@org.example
	Subject: [list] Sending through a list and alias		Subject: [list] Sending through a list and alias
	Sender: Ann Author <aauthor@com.example>]]></artwork>		Sender: Ann Author <aauthor@com.example>
	</figure></t>		]]></artwork>
	<t>List @ org.example <list style="empty">		</li>
	<t>As delivered, with one Delivered-To: header field		<li>
	, to the list processing module, which		<t>List processing at org.example </t>
	will then re-submit the message for further tran		<t indent="3">As delivered, with one Delivered-To: header field, to
	sport to the list member		the list processing module, which
			will then resubmit the message for further trans
			port to the list member
	"Recipient-alumn@edu.example".</t>		"Recipient-alumn@edu.example".</t>
	</list>		<artwork><![CDATA[Delivered-To: list@org.example
	<figure>
	<artwork><![CDATA[Delivered-To: list@org.example
	Received: by submit.org.example with SMTP id i17so17480689ljn.1		Received: by submit.org.example with SMTP id i17so17480689ljn.1
	for <list@org.example> from mail.com.example;		for <list@org.example> from mail.com.example;
	Mon, 25 Jan 2021 15:29:19 -0800 (PST)		Mon, 25 Jan 2021 15:29:19 -0800 (PST)
	Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)		Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
	From: Ann Author <aauthor@com.example>		From: Ann Author <aauthor@com.example>
	Date: Mon, 25 Jan 2021 18:29:06 -0500		Date: Mon, 25 Jan 2021 18:29:06 -0500
	To: list@org.example		To: list@org.example
	Subject: [list] Sending through a list and alias		Subject: [list] Sending through a list and alias
	Sender: Ann Author <aauthor@com.example>]]></artwork>		Sender: Ann Author <aauthor@com.example>
	</figure></t>		]]></artwork>
	<t>Alias @ edu.example <list style="empty">		</li>
	<t>The message, as delivered with two Delivered-To:		<li>
	header fields, to the alias processing		<t>Alias processing at edu.example </t>
			<t indent="3">
			The message, as delivered with two Delivered-To: header fields, to t
			he alias processing
	module, which sends the message on to "theRecipi ent@example.net".</t>		module, which sends the message on to "theRecipi ent@example.net".</t>
	</list>		<artwork><![CDATA[Delivered-To: Recipient-alumn@edu.example
	<figure>
	<artwork><![CDATA[Delivered-To: Recipient-alumn@edu.
	example
	Received: from mail.org.example		Received: from mail.org.example
	by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)		by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
	Received: by submit.org.example;		Received: by submit.org.example;
	Mon, 25 Jan 2021 23:29:21 +0000 (UTC)		Mon, 25 Jan 2021 23:29:21 +0000 (UTC)
	Delivered-To: list@org.example		Delivered-To: list@org.example
	Received: by submit.org.example with SMTP id i17so17480689ljn.1		Received: by submit.org.example with SMTP id i17so17480689ljn.1
	for <list@org.example> from mail.com.example;		for <list@org.example> from mail.com.example;
	Mon, 25 Jan 2021 15:29:19 -0800 (PST)		Mon, 25 Jan 2021 15:29:19 -0800 (PST)
	Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)		Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
	From: Ann Author <aauthor@com.example>		From: Ann Author <aauthor@com.example>
	Date: Mon, 25 Jan 2021 18:29:06 -0500		Date: Mon, 25 Jan 2021 18:29:06 -0500
	To: list@org.example		To: list@org.example
	Subject: [list] Sending through a list and alias		Subject: [list] Sending through a list and alias
	Sender: list-bounces@org.example]]></artwork>		Sender: list-bounces@org.example
	</figure></t>		]]></artwork>
	<t>Delivery @ example.net <list style="empty">		</li>
	<t>The message, as finally delivered with three Deli		<li>
	vered-To: header fields, to the		<t>Final delivery to the recipient at example.net </t>
			<t indent="3">
			The message, as finally delivered with three Delivered-To: header fi
			elds, to the
	recipient at "theRecipient@example.net".</t>		recipient at "theRecipient@example.net".</t>
	</list>		<artwork><![CDATA[Delivered-To: theRecipient@example.net
	<figure>
	<artwork><![CDATA[Delivered-To: theRecipient@example
	.net
	Received: from mail.edu.example (mail.edu.example [4.31.198.45])		Received: from mail.edu.example (mail.edu.example [4.31.198.45])
	by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)		by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
	Delivered-To: Recipient-alumn@edu.example		Delivered-To: Recipient-alumn@edu.example
	Received: from mail.org.example		Received: from mail.org.example
	by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)		by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
	Received: by submit.org.example;		Received: by submit.org.example;
	Mon, 25 Jan 2021 23:29:21 +0000 (UTC)		Mon, 25 Jan 2021 23:29:21 +0000 (UTC)
	Delivered-To: list@org.example		Delivered-To: list@org.example
	Received: by submit.org.example with SMTP id i17so17480689ljn.1		Received: by submit.org.example with SMTP id i17so17480689ljn.1
	for <list@org.example> from mail.com.example;		for <list@org.example> from mail.com.example;
	Mon, 25 Jan 2021 15:29:19 -0800 (PST)		Mon, 25 Jan 2021 15:29:19 -0800 (PST)
	Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)		Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
	From: Ann Author <aauthor@com.example>		From: Ann Author <aauthor@com.example>
	Date: Mon, 25 Jan 2021 18:29:06 -0500		Date: Mon, 25 Jan 2021 18:29:06 -0500
	To: list@org.example		To: list@org.example
	Subject: [list] Sending through a list and alias		Subject: [list] Sending through a list and alias
	Sender: list-bounces@org.example]]></artwork>		Sender: list-bounces@org.example
	</figure></t>		]]></artwork>
	</list></t>		</li>
	</section>		</ol>
			</section>
	<section title="Security Considerations" anchor="Security">		<section anchor="Security">
	<t>As with Received: header fields, the presence of a Delivered-To:		<name>Security Considerations</name>
	header field discloses handling		<t>As with Received: header fields, the presence of a Delivered-To: header
			field discloses handling
	information and, possibly, personal information.</t>		information and, possibly, personal information.</t>
			<t>Security and privacy are essential, if challenging, topics for email in
	<t>Security and privacy are essential, if challenging, topics for em		general and for the handling of
	ail in general and for the handling of
	metadata in particular. The purpose of this section is to note p oints of potential concern, rather than		metadata in particular. The purpose of this section is to note p oints of potential concern, rather than
	to provide details for mitigation. The basic mechanism described here has a long history of use, with no		to provide details for mitigation. The basic mechanism described here has a long history of use, with no
	history of being problematic. However the expanded use described here might create new scenarios that		history of being problematic. However, the expanded use describe d here might create new scenarios that
	are problematic.</t>		are problematic.</t>
			<t>An issue specific to this mechanism is disclosure of a sequence of addr
	<t>An issue specific to this mechanism is disclosure of a sequence o		esses, applied to the same
	f addresses, applied to the same		recipient, if a message goes through a series of recipient addre
	recipient, if a message goes through a series of recipient addre		ss replacements. This document calls for
	ss replacements. The document calls for
	each of these addresses to be recorded in a separate Delivered-T o: field. This does not disclose		each of these addresses to be recorded in a separate Delivered-T o: field. This does not disclose
	addresses of other recipients, but it does disclose a address-tr ansformation handling path for the		addresses of other recipients, but it does disclose an address-t ransformation handling path for the
	recipient.</t>		recipient.</t>
			<t>This disclosure is most likely to be a concern when a recipient manuall
	<t>Where this disclosure is most likely to be a concern is when a re		y forwards a message and
	cipient manually forwards a message and
	includes all of the original header fields. This will expose, to a later recipient, any intermediate		includes all of the original header fields. This will expose, to a later recipient, any intermediate
	addresses used for getting the original message to the original recipient. Such a disclosure is likely		addresses used for getting the original message to the original recipient. Such a disclosure is likely
	to be unintended and might be (highly) problematic. Note that a basic version of this unintended		to be unintended and might be (highly) problematic. Note that a basic version of this unintended
	disclosure has long existed, by virtue of a later recipient's se eing Received: header fields, but		disclosure has long existed, by virtue of a later recipient's se eing Received: header fields, but
	especially any with a 'for' clause. However a Delivered-To: head er field sequence can disclose		especially any with a 'for' clause. However, a Delivered-To: hea der field sequence can disclose
	significantly more recipient-specific handling detail.</t>		significantly more recipient-specific handling detail.</t>
			<t>An issue that is entirely implementation specific -- and therefore out
	<t>An issue that is entirely implementation specific -- and therefor		of scope for this document -- is
	e out of scope to this document -- is
	that in some systems, a message that is for multiple (local) rec ipients is stored as a single, shared		that in some systems, a message that is for multiple (local) rec ipients is stored as a single, shared
	version. Supporting Delivered-To:, while maintaining recipient p rivacy, creates a challenge in this		version. Supporting Delivered-To:, while maintaining recipient p rivacy, creates a challenge in this
	case, since exposing different recipient addresses to other reci pients can be problematic.</t>		case, since exposing different recipient addresses to other reci pients can be problematic.</t>
			</section>
			<section>
			<name>IANA Considerations</name>
			<t>IANA has registered the Delivered-To: header field as below, per <xref
			target="RFC3864"/> in the "Provisional Message Header Field Names" registry: </t
			>
			<dl newline="false" spacing="normal">
			<dt>Header Field Name:</dt>
			<dd> Delivered-To</dd>
			<dt>Protocol:</dt>
			<dd> mail</dd>
			<dt>Status:</dt>
			<dd>Provisional</dd>
			<dt>Author/Change controller:</dt>
			<dd>Dave Crocker</dd>
			<dt>Specification document(s):</dt>
			<dd> *** This document ***</dd>
			<dt>Related information:</dt>
			<dd>None.</dd>
			</dl>
			</section>
			<section>
			<name>Experimental Goals</name>
			<t>Specific feedback is sought concerning:</t>
			<ul spacing="normal">
			<li>Technical issues in recording the Delivered-To: field into a message
			, through its entire
			submission/delivery sequence</li>
			<li>Market interest in the uses described here</li>
			<li>Utility for the purposes described here, or for other uses</li>
			</ul>
			<t> So the questions to answer for this Experimental RFC are:</t>
			<ul spacing="normal">
			<li>Is there demonstrated interest by MSA/MTA/MDA (Message Submission Ag
			ent / Message Transfer Agent / Message Delivery Agent) developers?</li>
			<li>If the capability is implemented and the header field generated, is
			it used by operators or
			MUAs?</li>
			<li>Does the presence of the header field create any operational problem
			s?</li>
			<li>Does the presence of the header field demonstrate additional securit
			y issues?</li>
			<li>What specific changes to the document are needed?</li>
			<li>What other comments will aid in use of this mechanism?</li>
			</ul>
			<t>Please send comments to ietf-smtp@ietf.org.</t>
			</section>
			</middle>
			<back>
	</section>		<displayreference target="RFC5234" to="ABNF"/>
			<displayreference target="RFC5598" to="Mail-Arch"/>
	<section title="IANA Considerations">		<displayreference target="RFC5322" to="Mail-Fmt"/>
	<t>Registration of the "Delivered-To:" header field is requested, pe		<displayreference target="RFC5321" to="SMTP"/>
	r <xref target="RFC3864"/>: <list>
	<t><list style="hanging" >
	<t hangText="Header field name:"> Delivered-To</t>
	<t hangText="Applicable protocol:"> mail</t>
	<t hangText="Status:">Provisional</t>
	<t hangText="Author/Change controller:">Dave Crocker
	</t>
	<t hangText="Specification document(s):"> *** This d
	ocument ***</t>
	<t hangText="Related information:">None.</t>
	</list></t>
	</list>
	</t>
	</section>
	<section title="Experimental Goals">
	<t>Specific feedback is sought concerning:<list style="symbols">
	<t>Technical issues in recording the Delivered-To: field int
	o a message, through its entire
	submission/delivery sequence</t>
	<t>Market interest in the uses described here</t>
	<t>Utility for the purposes described here, or for other use
	s</t>
	</list> So the questions to answer for this Experimental documen
	t are:<list style="symbols">
	<t>Is there demonstrated interest by MSA/MTA/MDA developers?
	</t>
	<t>If the capability is implemented and the header field gen
	erated, is it used by operators or
	MUAs?</t>
	<t>Does the presence of the header field create any operatio
	nal problems?</t>
	<t>Does the presence of the header field demonstrate additio
	nal security issues?</t>
	<t>What specific changes to the document are needed?</t>
	<t>What other comments will aid in use of this mechanism?</t
	>
	</list>Please send comments to ietf-smtp@ietf.org.</t>
	</section>
	</middle>
	<back>
	<references title="Normative References">
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/
	rfc2119">
	<front>
	<title> Key words for use in RFCs to Indicate Requirement Le
	vels </title>
	<author initials="S." surname="Bradner" fullname="S. Bradner
	">
	<organization/>
	</author>
	<date year="1997" month="March"/>
	<abstract>
	<t> In many standards track documents several words are
	used to signify the requirements in the
	specification. These words are often capitalized. Th
	is document defines these words as they
	should be interpreted in IETF documents. This docume
	nt specifies an Internet Best Current
	Practices for the Internet Community, and requests d
	iscussion and suggestions for
	improvements. </t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="ABNF">
	<front>
	<title>Augmented BNF for Syntax Specifications: ABNF</title>
	<author fullname="D. Crocker" initials="D." surname="Crocker
	">
	<organization>Brandenburg InternetWorking</organization>
	</author>
	<author surname="Overell" initials="P." fullname="P. Overell
	">
	<organization>THUS plc</organization>
	</author>
	<date year="2008" month="January"/>
	</front>
	<seriesInfo name="RFC" value="5234"/>
	</reference>
	<!-- <reference anchor="Emoji-List">
	<front>
	<title>Full Emoji List, v13.0</title>
	<author>
	<organization>Unicode Consortium</organization>
	<address>
	<phone>+1-408-401-8915</phone>
	<uri>https://home.unicode.org/</uri>
	</address>
	</author>
	<date/>
	</front>
	<seriesInfo name="WEB" value="https://unicode.org/emoji/charts/f
	ull-emoji-list.html"
	/>
	</reference>-->
	<reference anchor="Mail-Fmt">
	<front>
	<title>Internet Message Format</title>
	<author fullname="Peter W. Resnick" initials="P." role="edi
	tor" surname="Resnick">
	<organization> Qualcomm Incorporated </organization>
	</author>
	<date month="October" year="2008"/>
	</front>
	<seriesInfo name="RFC" value="5322"/>
	</reference>
	<reference anchor="Mail-Arch">
	<front>
	<title>Internet Mail Architecture</title>
	<author fullname="D. Crocker" initials="D." surname="Crocker
	">
	<organization>Brandenburg InternetWorking</organization>
	</author>
	<date year="2009" month="July"/>
	</front>
	<seriesInfo name="RFC" value="5598"/>
	</reference>
	<!-- <reference anchor="Mail-Hdrs">
	<front>
	<title>Common Internet Message Headers</title>
	<author fullname="J. Palme" initials="J." surname="Palme">
	<organization>Stockholm University/KTH</organization>
	</author>
	<date month="February" year="1997"/>
	</front>
	<seriesInfo name="RFC" value="2076"/>
	</reference>-->
	<!--<reference anchor="MIME">
	<front>
	<title>Multipurpose Internet Mail Extensions (MIME) Part One
	: Format of Internet
	Message Bodies</title>
	<author fullname="N. Freed" initials="N." surname="Freed">
	<organization>Innosoft</organization>
	</author>
	<author fullname="N. Borenstein" initials="N." surname="Bore
	nstein">
	<organization>First Virtual</organization>
	</author>
	<date month="November" year="1996"/>
	</front>
	<seriesInfo name="RFC" value="2045"/>
	</reference>-->
	<!--<reference anchor="MIME-Enc">
	<front>
	<title>MIME (Multipurpose Internet Mail Extensions) Part Thr
	ee: Message Header
	Extensions for Non-ASCII Text</title>
	<author fullname="K. Moore" initials="K." surname="Moore">
	<organization>University of Tennessee</organization>
	</author>
	<date month="November" year="1996"/>
	</front>
	<seriesInfo name="RFC" value="2047"/>
	</reference>-->
	<!-- <reference anchor="IANA">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section
	in RFCs</title>
	<author fullname="M. Cotton" initials="" surname="M. Cotton"
	/>
	<author fullname="B. Leiba" initials="" surname="B. Leiba"/>
	<author fullname="T. Narten" initials="" surname="T. Narten"
	/>
	<date year="2017"/>
	</front>
	<seriesInfo name="I-D"
	value="draft-leiba-cotton-iana-5226bis-11"/>
	</reference>-->
	<reference anchor="RFC3864" target="https://www.rfc-editor.org/info/
	rfc3864">
	<front>
	<title>Registration Procedures for Message Header Fields</ti
	tle>
	<author initials="G." surname="Klyne" fullname="G. Klyne">
	<organization/>
	</author>
	<author initials="M." surname="Nottingham" fullname="M. Nott
	ingham">
	<organization/>
	</author>
	<author initials="J." surname="Mogul" fullname="J. Mogul">
	<organization/>
	</author>
	<date year="2004" month="September"/>
	<abstract>
	<t> This specification defines registration procedures f
	or the message header fields used by
	Internet mail, HTTP, Netnews and other applications.
	This document specifies an Internet
	Best Current Practices for the Internet Community, a
	nd requests discussion and suggestions
	for improvements. </t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="90"/>
	<seriesInfo name="RFC" value="3864"/>
	<seriesInfo name="DOI" value="10.17487/RFC3864"/>
	</reference>
	<reference anchor="SMTP" target="https://www.rfc-editor.org/info/rfc
	5321">
	<front>
	<title>Simple Mail Transfer Protocol</title>
	<author initials="J." surname="Klensin" fullname="J. Klensin
	">
	<organization/>
	</author>
	<date year="2008" month="October"/>
	<abstract>
	<t> This document is a specification of the basic protoc
	ol for Internet electronic mail
	transport. It consolidates, updates, and clarifies s
	everal previous documents, making all or
	parts of most of them obsolete. It covers the SMTP e
	xtension mechanisms and best practices
	for the contemporary Internet, but does not provide
	details about particular extensions.
	Although SMTP was designed as a mail transport and d
	elivery protocol, this specification
	also contains information that is important to its u
	se as a "mail submission" protocol for
	"split-UA" (User Agent) mail reading systems and mob
	ile environments. [STANDARDS-TRACK] </t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5321"/>
	<seriesInfo name="DOI" value="10.17487/RFC5321"/>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/
	rfc8174">
	<front>
	<title> Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
	Words </title>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>
	<date year="2017" month="May"/>
	<abstract>
	<t> RFC 2119 specifies common key words that may be used
	in protocol specifications. This
	document aims to reduce the ambiguity by clarifying
	that only UPPERCASE usage of the key
	words have the defined special meanings. </t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	</references>
	<references title="Informative References">
	<reference anchor="Prior">
	<front>
	<title>The Delivered-To Message Header Field</title>
	<author fullname="V Dukhovni" initials="V." surname="Dukhovn
	i">
	<organization>Bloomberg LP</organization>
	</author>
	<author surname="J. Levine" initials="J." fullname="J. Levin
	e">
	<organization>Standcore LLC</organization>
	</author>
	<date day="16" month="August" year="2021"/>
	</front>
	<seriesInfo name="I-D" value="draft-duklev-deliveredto-00"/>
	</reference>
	</references>		<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.2119.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5234.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5322.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5598.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.3864.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5321.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8174.xml"/>
			</references>
			<references>
			<name>Informative References</name>
	<section title="Acknowledgements">		<!-- draft-duklev-deliveredto (I-D Exists) "Long way" to fix author initials --
			>
			<reference anchor="Prior">
			<front>
			<title>The Delivered-To Message Header Field</title>
			<author fullname="Viktor Dukhovni">
			<organization>Bloomberg LP</organization>
			</author>
			<author fullname="John Levine">
			<organization>Standcore LLC</organization>
			</author>
			<date month="February" day="6" year="2022" />
			</front>
			<seriesInfo name="Internet-Draft" value="draft-duklev-deliveredto-01" />
			</reference>
	<t>Even a simple, narrow specification can elicit a remarkable range		</references>
	and intensity of debate. In spite of		</references>
			<section numbered="false">
			<name>Acknowledgements</name>
			<t>Even a simple, narrow specification can elicit a remarkable range and i
			ntensity of debate. In spite of
	the current document's being a case of that challenge, useful di scussion has taken place, first in the		the current document's being a case of that challenge, useful di scussion has taken place, first in the
	IETF's emailcore working group mailing list, and then on the lon g-standing ietf-smtp mailing list.</t>		IETF's emailcore working group mailing list, and then on the lon g-standing ietf-smtp mailing list.</t>
			<!-- Stéphane Bortzmeyer added per author email dated 2/19/2022 7:34 AM -->
	<t>Helpful information and suggestions were provided by: Anonymous,		<t>Helpful information and suggestions were provided by Anonymous,
	Richard Clayton, Viktor Dukhovni, Adrian		<contact fullname="Stéphane Bortzmeyer"/>,
	Farrel, Ned Freed, John Klensin, Barry Leiba, Brandon Long, Geor		<contact fullname="Richard Clayton"/>, <contact fullname="Viktor Dukhovni"/>, <c
	ge Michaelson, Michael Peddemors, Phil		ontact fullname="Adrian Farrel"/>, <contact fullname="Ned Freed"/>, <contact ful
	Pennock, Pete Resnick, Sam Varshavchik, Alessandro Vesely, Tim W		lname="John Klensin"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Br
	icinski.</t>		andon Long"/>, <contact fullname="George Michaelson"/>, <contact fullname="Micha
			el Peddemors"/>, <contact fullname="Phil Pennock"/>, <contact fullname="Pete Res
	</section>		nick"/>, <contact fullname="Sam Varshavchik"/>, <contact fullname="Alessandro Ve
			sely"/>, and <contact fullname="Tim Wicinski"/>.</t>
	</back>		</section>
			</back>
	</rfc>		</rfc>
End of changes. 50 change blocks.
	614 lines changed or deleted		385 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/