rfc9057xml2.original.xml   rfc9057.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?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-author-04" ipr="trust200902"
submissionType="IETF">
<front>
<title abbrev="Author">Email Author Header Field</title>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<date year="2021"/>
<area>Applications and Real-Time</area>
<keyword>domain</keyword> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-cr
<keyword>email</keyword> ocker-email-author-04" ipr="trust200902" submissionType="independent" obsoletes=
<keyword>security</keyword> "" updates="" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRe
<keyword>messaging</keyword> fs="true" version="3" number="9057">
<keyword>dkim</keyword> <!-- xml2rfc v2v3 conversion 3.7.0 -->
<keyword>spf</keyword> <front>
<keyword>authentication</keyword> <title abbrev="Email Author Header Field">Email Author Header Field</title>
<keyword>reporting</keyword> <seriesInfo name="RFC" value="9057"/>
<keyword>conformance</keyword> <author fullname="Dave Crocker" initials="D." surname="Crocker">
<keyword>author</keyword> <organization>Brandenburg InternetWorking</organization>
<keyword>origination</keyword> <address>
<keyword>original</keyword> <email>dcrocker@bbiw.net</email>
<keyword>from</keyword> </address>
<keyword>sender</keyword> </author>
<abstract> <date month="June" year="2021"/>
<t>Internet mail defines the From: header field to indicate the <area>Applications and Real-Time</area>
<keyword>domain</keyword>
<keyword>email</keyword>
<keyword>security</keyword>
<keyword>messaging</keyword>
<keyword>dkim</keyword>
<keyword>spf</keyword>
<keyword>authentication</keyword>
<keyword>reporting</keyword>
<keyword>conformance</keyword>
<keyword>author</keyword>
<keyword>origination</keyword>
<keyword>original</keyword>
<keyword>from</keyword>
<keyword>sender</keyword>
<abstract>
<t>Internet mail defines the From: header field to indicate the
author of the message's content and the Sender: field to author of the message's content and the Sender: field to
indicate who initially handled the message, on the author's indicate who initially handled the message on the author's
behalf. The Sender: field is optional, if it has the same behalf. The Sender: field is optional if it has the same
information as the From: field. This was not a problem, until information as the From: field. This was not a problem until
development of stringent protections on use of the From: field. development of stringent protections on use of the From: field.
It has prompted Mediators, such as mailing lists, to modify the It has prompted Mediators, such as mailing lists, to modify the
From: field, to circumvent mail rejection caused by those From: field to circumvent mail rejection caused by those
protections. In effect, the From: field has become dominated by protections. In effect, the From: field has become dominated by
its role as a handling identifier.</t> its role as a handling identifier.</t>
<t> The current specification augments the altered use of the From: <t> The current specification augments the altered use of the From:
field, by specifying the Author: field, which ensures field by specifying the Author: field, which ensures
identification of the original author of the message and is not identification of the original author of the message and is not
subject to modification by Mediators. This version is published subject to modification by Mediators. This document is published
as an Experiment, to assess community interest, functional as an Experimental RFC to assess community interest, functional
efficacy, and technical adequacy.</t> efficacy, and technical adequacy.</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section toc="default" numbered="true">
<section title="Introduction" toc="default"> <name>Introduction</name>
<t>Internet mail conducts asynchronous communication from an author <t>Internet mail conducts asynchronous communication from an author
to one or more recipients, and is used for ongoing dialogue to one or more recipients and is used for ongoing dialog
amongst them. Email has a long history of serving a wide range amongst them. Email has a long history of serving a wide range
of human uses and styles, within that simple framework, and the of human uses and styles, within that simple framework, and the
mechanisms for making email robust and safe serve that sole mechanisms for making email robust and safe serve that sole
purpose.</t> purpose.</t>
<t> Internet mail defines the content header's From: field to
<t> Internet mail defines the content header's From: field to
indicate the author of the message and the Sender: field to indicate the author of the message and the Sender: field to
indicate who initially handled the message, on the author's indicate who initially handled the message on the author's
behalf. <xref target="Mail-Fmt"/> The Sender: field is optional, behalf <xref target="RFC5322" format="default"/>. The Sender: fi
eld is optional
if it has the same information as the From: field. That is, when if it has the same information as the From: field. That is, when
the Sender: field is absent, the From: field has conflated the Sender: field is absent, the From: field has conflated
semantics, as both a handling identifier and a content creator semantics as both a handling identifier and a content creator
identifier. These fields were initially defined in <xref identifier. These fields were initially defined in <xref target=
target="RFC733"/> and making the redundant Sender: field "RFC0733" format="default"/>, and making the redundant Sender: field
optional was a small, obvious optimization, in the days of optional was a small, obvious optimization in the days of
slower communications, expensive storage and less powerful slower communications, expensive storage, and less powerful
computers.</t> computers.</t>
<t>The dual semantics was not a problem, until development of <t>The dual semantics were not a problem until development of
stringent protections on use of the From: field. It has prompted stringent protections on use of the From: field. It has prompted
Mediators, such as mailing lists, to modify the From: field, to Mediators, such as mailing lists, to modify the From: field to
circumvent receiver mail rejection, caused by those protections. circumvent receiver mail rejection caused by those protections.
This affects end-to-end usability of email, between the author This affects end-to-end usability of email between the author
and the final recipients, because mail received from the same and the final recipients, because mail received from the same
author is treated differently by the recipient's software, author is treated differently by the recipient's software,
depending on what path the message followed. </t> depending on what path the message followed. </t>
<t>By way of example, mail originating with: </t>
<t>By way of example, mail originating with: <figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>From: Example User &lt;user@example.com&gt;</artwo From: Example User <user@example.com>
rk> ]]></artwork>
</figure> which is sent directly to a recipient, will show the <t> which is sent directly to a recipient, will show the
author's display name correctly and can correctly analyze, author's display name correctly and can correctly analyze,
filter and aggregate mail from the author, based on their email filter, and aggregate mail from the author based on their email
address. However if the author sends through a mailing list, and address. However, if the author sends through a mailing list and
the mailing list conducts a common form of From: modification, the mailing list conducts a common form of From: modification
needed to bypass enforcement of stringent authentication needed to bypass enforcement of stringent authentication
policies, then the received message might instead have a From: policies, then the received message might instead have a From:
field showing: <figure> field showing: </t>
<artwork>From: Example User via Example List &lt;listname@li <artwork name="" type="" align="left" alt=""><![CDATA[
st.example.org&gt;</artwork> From: Example User via Example List <listname@list.example.org>
</figure> The change inserts an operational address, for the ]]></artwork>
Mediator, into the From: field, and distorts the field's <t> The change inserts an operational address, for the
display-name, as a means of recording the modification.</t> Mediator, into the From: field and distorts the field's
<t>In terms of email identification semantics, this is a profound display name as a means of recording the modification.</t>
change:<list style="symbols"> <t>In terms of email identification semantics, this is a profound
<t>The result is that the recipient's software will see the change:</t>
<ul spacing="normal">
<li>The result is that the recipient's software will see the
message as being from an entirely different author and message as being from an entirely different author and
will handle it separately, such as for sorting or will handle it separately, such as for sorting or
filtering. In effect, the recipient's software will see filtering.
In effect, the recipient's software will see
the same person's email as being from a different the same person's email as being from a different
address, for the person's actual address and each of the address; this includes the person's actual address and e
mailing lists that person's mail transits.</t> ach of the
<t>Mediators might create a Reply-To: field, with the mailing lists that person's mail transits.</li>
<li>Mediators might create a Reply-To: field with the
original From: field email address. This facilitates original From: field email address. This facilitates
getting replies back to the original author, but it does getting replies back to the original author, but it does
nothing to aid other processing or presentation, done by nothing to aid other processing or presentation done by
the recipient's Mail User Agent (MUA), based on what it the recipient's Mail User Agent (MUA) based on what it
believes is the author's address or original believes is the author's address or original
display-name. This Reply-To action represents another display name.
knock-on, collateral damage, by distorting the meaning This Reply-To action represents another
knock-on effect (e.g., collateral damage) by
distorting the meaning
of that header field, as well as creating an issue if of that header field, as well as creating an issue if
the field already exists.</t> the field already exists.</li>
</list></t> </ul>
<t>In effect, the From: field has become dominated by its role as a
<t>In effect, the From: field has become dominated by its role as a
handling identifier. The current specification augments this handling identifier. The current specification augments this
altered use of the From: field, by specifying the Author: field, altered use of the From: field by specifying the Author: field,
which identifies the original author of the message and is not which identifies the original author of the message and is not
subject to modification by Mediators.</t> subject to modification by Mediators.</t>
<t>While it might be cleanest to move towards more reliable use of
<t>While it might be cleanest to move towards more reliable use of
the Sender: field and then to target it as the focus of the Sender: field and then to target it as the focus of
authentication concerns, enhancement of existing standards works authentication concerns, enhancement of existing standards works
best with incremental additions, rather than with efforts at best with incremental additions, rather than with efforts at
replacement. To that end, this specification provides a means of replacement. To that end, this specification provides a means of
supplying author information that is not subject to modification supplying author information that is not subject to modification
by processes seeking to enforce stringent authentication.</t> by processes seeking to enforce stringent authentication.</t>
<t>This version is published as an Experimental RFC to assess community
<t>This version is published as an Experiment, to assess community interest, functional efficacy, and technical adequacy. See <xref
interest, functional efficacy, and technical adequacy. See <xref target="experiment" format="default"/>.</t>
target="experiment"/>.</t> </section>
<section numbered="true" toc="default">
</section> <name>Terminology</name>
<t>Terminology and architectural details in this document are
<section title="Terminology"> incorporated from <xref target="RFC5598" format="default"/>.</t>
<t>Terminology and architectural details in this document are <t>
incorporated from <xref target="Mail-Arch"/>.</t> Normative language, per <xref target="RFC8174" format="default"/>:
</t>
<t>Normative language, per <xref target="RFC8174"/>: <list> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
RECOMMENDED", "MAY", and "OPTIONAL" in this document are NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
to be interpreted as described in BCP 14 [RFC2119] RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
[RFC8174] when, and only when, they appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
capitals, as shown here.</t> be interpreted as
</list></t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<t>RFC EDITOR: Please remove for publication:<list> </t>
<t>Discussion of this draft is directed to the </section>
ietf-822@ietf.org mailing list.</t> <section numbered="true" toc="default">
</list></t> <name>Author Header Field</name>
<t>Author: is a new message header field being defined. It has the same
</section> syntax as the From: header field <xref target="RFC5322" format="
default"/>. As
<section title="Author Header Field">
<t>A new message header field is defined: Author:. It has the same
syntax as the From: header field <xref target="Mail-Fmt"/>. As
with the original and primary intent for the From: field, the with the original and primary intent for the From: field, the
Author: field is to contain the email address of the author of Author: field is intended to contain the email address of the au thor of
the message content. It also can contain the displayable human the message content. It also can contain the displayable human
name of the author.</t> name of the author.</t>
<t>The <xref target="RFC5234" format="default"/> for the field's syntax is
<t>The <xref target="ABNF"/> for the field's syntax is: <figure> : </t>
<artwork type="ABNF">author = "Author:" mailbox-list CRLF</a <sourcecode type="abnf"><![CDATA[
rtwork> author = "Author:" mailbox-list CRLF
</figure>which echos the syntax for the From: header field. </t> ]]></sourcecode>
<t>which echos the syntax for the From: header field. </t>
<t> This header field can be added as part of the original message <t> This header field can be added as part of the original message
creation process, or it can be added later, by a Mediator, to creation process, or it can be added later, by a Mediator, to
preserve the original author information from the From: preserve the original author information from the From:
field.</t> field.</t>
<t> The goal of the Author: field is to reflect information about
<t> The goal of the Author: field is to reflect information about the original author. However, it is possible that the author's
the original author. However it is possible that the author's MUA or Mail Submission Agent (MSA) will not create it but that
MUA or Mail Submission Agent (MSA) will not create it, but that
a Mediator might know it will be modifying the From: field and a Mediator might know it will be modifying the From: field and
wish to preserve author information. Hence it needs to be wish to preserve the author information. Hence, it needs to be
allowed to create the Author: field for this, if the field does allowed to create the Author: field for this if the field does
not already exist.</t> not already exist.</t>
<t>Processing of the Author: field follows these rules:</t>
<t>Processing of the Author: field follows these rules:<list <ul spacing="normal">
style="symbols"> <li>If an Author: field already exists, a new one <bcp14>MUST NOT</bcp14
<t>If an Author: field already exists, a new one MUST NOT be > be
created and the existing one MUST NOT be modified</t> created, and the existing one <bcp14>MUST NOT</bcp14> be
modified.</li>
<t>An author's MUA or MSA MAY create an Author: field, and <li>An author's MUA or MSA <bcp14>MAY</bcp14> create an Author: field, a
its value MUST be identical to the value in the From: nd
field</t> its value <bcp14>MUST</bcp14> be identical to the value
in the From:
<t>A Mediator MAY create an Author: field, if one does not field.</li>
already exist, and this new field's value MUST be <li>A Mediator <bcp14>MAY</bcp14> create an Author: field if one does no
identical to the value of the From: field, at the time t
already exist, and this new field's value <bcp14>MUST</b
cp14> be
identical to the value of the From: field at the time
the Mediator received the message (and before the the Mediator received the message (and before the
Mediator causes any changes to the From: field)</t> Mediator causes any changes to the From: field).</li>
</list> </ul>
</t> </section>
<section numbered="true" toc="default">
</section> <name>Discussion</name>
<t>The Author: header field, here, is intended for creation during
<section title="Discussion">
<t>The Author: header field, here, is intended for creation during
message generation or during mediation. It is intended for use message generation or during mediation. It is intended for use
by recipient MUAs, as they typically use the From: field. In by recipient MUAs, as they typically use the From: field. In
that regard, it would be reasonable for an MUA that would that regard, it would be reasonable for an MUA that would
normally organize, filter, or display information based on the normally organize, filter, or display information based on the
From: field to give the Author: header field preference.</t> From: field to give the Author: header field preference.</t>
<t>Original-From: is a similar header field, referenced in <xref <t>Original-From: is a similar header field referenced in <xref target="RF
target="RFC5703"/>. It is registered with IANA, which cites C5703" format="default"/>. It is registered with IANA, which cites
RFC5703 as the controlling source for the entry. However that <xref target="RFC5703" format="default"/> as the controlling sou
rce for the entry. However, that
document only has a minimal definition for the field. Also, the document only has a minimal definition for the field. Also, the
field is solely intended for use by Mediators, to preserve field is solely intended for use by Mediators to preserve
information from a modified From:. The current specification can information from a modified From: field. The current specificati
be used either during origination or during mediation.</t> on can
be used during either origination or mediation.</t>
<t>While the basic model of email header fields is highly <t>While the basic model of email header fields is highly
extensible, there well might be implementation and usability extensible, there well might be implementation and usability
considerations for carrying this field through to end-users, considerations for carrying this field through to end users,
such as via <xref target="IMAP"/>. </t> such as via <xref target="RFC3501" format="default"/>. </t>
<t>Obviously any security-related processing of a message needs to <t>Obviously, any security-related processing of a message needs to
distinguish From: from Author: and treat their information distinguish the From: field from the Author: field and treat the
ir information
accordingly.</t> accordingly.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>Any header field containing identification information is a <t>Any header field containing identification information is a
source of security and privacy concerns, especially when the source of security and privacy concerns, especially when the
information pertains to content authorship. Generally, the information pertains to content authorship. Generally, the
handling of the Author: header field needs to receive scrutiny handling of the Author: header field needs to receive scrutiny
and care, comparable to that given to the From: header field, and care, comparable to that given to the From: header field,
but preferably not in a way that defeats its utility.</t> but preferably not in a way that defeats its utility.</t>
<t>Given the semantics of this field, it is easy to believe that use <t>Given the semantics of the Author: header field, it is easy to believe that use
of this field will create a new attack vector for tricking of this field will create a new attack vector for tricking
end-users. However (and perhaps surprisingly) for all of the end users. However (and perhaps surprisingly), for all of the
real and serious demonstration of users' being tricked by real and serious demonstrations of users being tricked by
deceptive or false content in a message, there is no evidence deceptive or false content in a message, there is no evidence
that problematic content in a header field, which is providing that problematic content in a header field, which is providing
information about message's author, directly contributes to information about message's author, directly contributes to
differential and problematic behavior by the end user. (The differential and problematic behavior by the end user. (The
presents an obvious exercise for the reader, to find credible, presents an obvious exercise for the reader to find credible,
documented evidence.)</t> documented evidence.)</t>
</section> </section>
<section anchor="iana_considerations" toc="default" numbered="true">
<section anchor="iana_considerations" title="IANA Considerations" <name>IANA Considerations</name>
toc="default"> <t>IANA has registered the Author: header field, per
<xref target="RFC3864" format="default"/>, in the "Provision
<t>The IANA is request to register the Author header field, per al Message
<xref target="RFC3864"/>, into the Provisional Message Header Field Names" registry: </t>
Header Field Names Registry: <list>
<t>Header field name: Author</t>
<t>Applicable protocol: mail</t>
<t>Status: Provisional</t>
<t>Author/Change controller: Dave Crocker
&lang;dcrocker@bbiw.net&rang;</t>
<t>Specification document(s): *** This document ***</t>
</list>
</t>
</section>
<section title="Experimental Goals" anchor="experiment"> <dl newline="false" spacing="compact">
<t>Given that the semantics of this field echo the long-standing <dt>Header field name:</dt>
<dd>Author</dd>
<dt>Applicable protocol:</dt>
<dd>mail</dd>
<dt>Status:</dt>
<dd>Provisional</dd>
<dt>Author/Change controller:</dt>
<dd>Dave Crocker
&lt;dcrocker@bbiw.net&gt;</dd>
<dt>Specification document(s):</dt>
<dd>RFC 9057</dd>
</dl>
</section>
<section anchor="experiment" numbered="true" toc="default">
<name>Experimental Goals</name>
<t>Given that the semantics of this field echo the long-standing
From: header field, the basic mechanics of the field's creation From: header field, the basic mechanics of the field's creation
and use are well understood. Points of concern, therefore, are and use are well understood. Points of concern, therefore, are
with possible interactions with the existing From: field, with with possible interactions with the existing From: field,
anti-abuse systems, and with MUA behavior, along with basic anti-abuse systems, and MUA behavior, along with basic
market acceptance. So the questions to answer, while the header market acceptance. So the questions to answer while the header
field has experimental status are:<list style="symbols"> field has experimental status are:</t>
<t>Is there demonstrated interest by MUA developers?</t> <ul spacing="normal">
<t>If MUA developers add this capability, is it used by <li>Is there demonstrated interest by MUA developers?</li>
authors?</t> <li>If MUA developers add this capability, is it used by
<t>Does the presence of the Author field, in combination authors?</li>
with the From field, create any operational problems, <li>Does the presence of the Author: field, in combination
especially for recipients?</t> with the From: field, create any operational problems,
<t>Does the presence of the Author field demonstrate especially for recipients?</li>
additional security issues?</t> <li>Does the presence of the Author: field demonstrate
<t>Does the presence of the Author field engender additional security issues?</li>
<li>Does the presence of the Author: field engender
problematic behavior by anti-abuse software, such as problematic behavior by anti-abuse software, such as
defeating its utility?</t> defeating its utility?</li>
</list></t> </ul>
</section> </section>
</middle>
</middle> <back>
<displayreference target="RFC3501" to="IMAP"/>
<back> <displayreference target="RFC5322" to="Mail-Fmt"/>
<references title="Normative References"> <displayreference target="RFC5598" to="Mail-Arch"/>
<displayreference target="RFC5234" to="ABNF"/>
<reference anchor="RFC3864" <displayreference target="RFC0733" to="RFC733"/>
target="https://www.rfc-editor.org/info/rfc3864">
<front>
<title>Registration Procedures for Message Header
Fields</title>
<author initials="G." surname="Klyne" fullname="G. Klyne">
<organization/>
</author>
<author initials="M." surname="Nottingham"
fullname="M. Nottingham">
<organization/>
</author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization/>
</author>
<date year="2004" month="September"/>
<abstract>
<t> This specification defines registration procedures
for 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, and 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="Mail-Fmt">
<front>
<title>Internet Message Format</title>
<author fullname="Peter W. Resnick" initials="P."
role="editor" 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="ABNF">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor"
surname="Dave">
<organization>Brandenburg InternetWorking</organization>
</author>
<author fullname="Overell" initials="P." surname="Paul">
<organization>THUS plc.</organization>
</author>
<date month="January" year="2008"/>
</front>
<seriesInfo name="RFC" value="5234"/>
</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>
<!--<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>-->
</references>
<references title="Informative References">
<reference anchor="RFC733">
<front>
<title>Standard for the Format of ARPA Network Text
Messages</title>
<author fullname="D. Crocker" initials="D."
surname="Crocker">
<organization>The Rand Corporation</organization>
</author>
<author fullname="J. J. Vittal" initials="J.J."
surname="Vittal">
<organization>Bolt Beranek and Newman
Inc.</organization>
</author>
<author fullname="Kenneth T. Pogran" initials="K.T."
surname="Pogran">
<organization>Massachusets Institute of
Technology</organization>
</author>
<author fullname="D. Austin Henderson, Jr." initials="D.A."
surname="Henderson">
<organization>Bolt Beranek and Newman
Inc.</organization>
</author>
<date day="21" month="November" year="1977"/>
</front>
<seriesInfo name="RFC" value="733"/>
</reference>
<reference anchor="IMAP" <references>
target="https://www.rfc-editor.org/info/rfc3501">
<front>
<title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1</title>
<author initials="M." surname="Crispin"
fullname="M. Crispin">
<organization/>
</author>
<date year="2003" month="March"/>
<abstract>
<t> The Internet Message Access Protocol, Version 4rev1
(IMAP4rev1) allows a client to access and manipulate
electronic mail messages on a server. IMAP4rev1
permits manipulation of mailboxes (remote message
folders) in a way that is functionally equivalent to
local folders. IMAP4rev1 also provides the
capability for an offline client to resynchronize
with the server. IMAP4rev1 includes operations for
creating, deleting, and renaming mailboxes, checking
for new messages, permanently removing messages,
setting and clearing flags, RFC 2822 and RFC 2045
parsing, searching, and selective fetching of
message attributes, texts, and portions thereof.
Messages in IMAP4rev1 are accessed by the use of
numbers. These numbers are either message sequence
numbers or unique identifiers. IMAP4rev1 supports a
single server. A mechanism for accessing
configuration information to support multiple
IMAP4rev1 servers is discussed in RFC 2244.
IMAP4rev1 does not specify a means of posting mail;
this function is handled by a mail transfer protocol
such as RFC 2821. [STANDARDS-TRACK] </t>
</abstract>
</front>
<seriesInfo name="RFC" value="3501"/>
<seriesInfo name="DOI" value="10.17487/RFC3501"/>
</reference>
<reference anchor="RFC5703"> <name>References</name>
<front> <references>
<title>Sieve Email Filtering: MIME Part Tests, Iteration, <name>Normative References</name>
Extraction, Replacement, and Enclosure</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname="T. Hansen" initials="T." surname="Hansen"> FC.2119.xml"/>
<organization>AT&amp;T Laboratories</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.3864.xml"/>
<author surname="Daboo" initials="C." fullname="C. Daboo"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization>Apple Inc.</organization> FC.5322.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date month="October" year="2009"/> FC.5598.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="RFC" value="5703"/> FC.5234.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0733.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3501.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5703.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The idea for this field was prompted by discussions in the IETF's
DMARC Working Group, with participation from: <contact
fullname="Benny Lyne Amorsen"/>, <contact fullname="Kurt Anderson
"/>,
<contact fullname="Laura Atkins"/>, <contact fullname="Adrian Far
rel"/>,
<contact fullname="Murray S. Kucherawy"/>, <contact fullname="Mik
e Hammer"/>,
<contact fullname="John Levine"/>, <contact fullname="Alexey Meln
ikov"/>,
<contact fullname="Jesse Thompson"/>, and <contact fullname="Ales
sandro
Vesely"/>.</t>
</section>
<section title="Acknowledgements"> </back>
<t>The idea for this field was prompted by discussions in the IETF's
DMARC working group, with participation including: Benny Lyne
Amorsen, Kurt Anderson, Laura Atkins, Adrian Farrel, Murray S.
Kucherawy, Mike Hammer, John Levine, Alexey Melnikov, Jesse
Thompson, Alessandro Vesely. </t>
</section>
</back>
</rfc> </rfc>
 End of changes. 49 change blocks. 
436 lines changed or deleted 276 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/