One document matched: draft-crocker-email-arch-10.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc tocindent="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc editing="no" ?>
<rfc category="std" docName="draft-crocker-email-arch-10" ipr="full3978">
<front>
<title abbrev="EMail Architecture">Internet Mail Architecture</title>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<date day="24" month="February" year="2008" />
<area>Applications</area>
<workgroup>SMTP</workgroup>
<keyword>email, e-mail, service, mime, rfc2822, rfc 2822, rfc822, rfc 822,
rfc2821, rfc 2821, rfc821, rfc 821, architecture, mta, mua, msa, mda,
user, delivery, relay, header, gateway agent, gateway actor, sieve,
dsn, mdn, tussle, mhs, mail handling service, message transfer agent,
message user agent, mail submission agent, mail delivery agent</keyword>
<abstract>
<t>Over its thirty-five year history Internet Mail has undergone
significant changes in scale and complexity, as it has become a
global infrastructure service. The first standardized architecture
for networked email specified little more than a simple split
between the user world and the transmission world. Core aspects of
the service, such as the styles of mailbox address and basic message
format, have remained remarkably constant. However today's Internet
Mail is distinguished by many independent operators, many different
components for providing service to users and many others for
performing message transfer. Public discussion of the service often
lacks common terminology and a common frame of reference for these
components and their activities. Having a common reference model and
terminology facilitates discussion about problems with the service,
changes in policy, or enhancement to the service's functionality.
This document offers an enhanced Internet Mail architecture that
targets description of the existing service, in order to facilitate
clearer and more efficient technical, operations and policy
discussions about email. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Over its thirty-five year history Internet Mail has undergone
significant changes in scale and complexity, as it has become a
global infrastructure service. The changes have been evolutionary,
rather than revolutionary, reflecting a strong desire to preserve
its installed base of users and utility. Today, Internet Mail is
distinguished by many independent operators, many different
components for providing service to users and many other components
for performing message transfer. </t>
<t> Public collaboration on email technical, operations and policy
activities, including those responding to the challenges of email
abuse, has brought in a much wider range of participants than
email's technical community originally had. In order to do work on a
large, complex system, they need to share the same view of how it is
put together, as well as what terms to use to refer to the pieces
and their activities. Otherwise, it is difficult to know exactly
what another participant means. It is these differences in each
person's perspective that motivates this document, to describe the
realities of the current system. Internet mail is the subject of
ongoing technical, operations and policy work, and the discussions
often are hindered by different models of email service design and
different meanings for the same terms. This architecture document
seeks to facilitate clearer and more efficient technical, operations
and policy exchanges about email. </t>
<t>This document offers an enhanced Internet Mail architecture to
reflect the current service. In particular it: </t>
<t>
<list>
<t>
<list style="symbols">
<t>Documents refinements to the email model</t>
<t>Clarifies functional roles for the architectural
components</t>
<t>Clarifies identity-related issues, across the email
service</t>
<t>Defines terminology for architectural components and
their interactions</t>
</list>
</t>
</list>
</t>
<section title="Background">
<t>The first standardized architecture for networked email specified
a simple split between the user world, in the form of <iref
item="MUA" />
<iref item="Mail User Agent" />
<iref item="UA" />
<iref item="User Agent" /> Mail User Agents (MUA), and the
transmission world, in the form of the <iref item="MHS" />
<iref item="Mail Handling Service" /> Mail Handling Service (MHS)
composed of <iref item="MTA" />
<iref item="Mail Transfer Agent" /> Mail Transfer Agents (MTA).
The MHS is responsible for accepting a message from one User and
delivering it to one or more others, creating a virtual
MUA-to-MUA exchange environment. </t>
<t>As shown in <xref target="Basic" /> this defines two logical
"layers" of interoperability. One is directly between Users. The
other is between the neighboring components, along the transfer
path. In addition, there is interoperability between the layers,
first when a message is posted from the User to the MHS and later
when it is delivered from the MHS to the User. </t>
<t>The operational service has evolved sub-divisions for each of
these layers into more specialized modules. Core aspects of the
service, such as mailbox addressing and message format style,
have remained remarkably constant. So the original distinction
between user-level concerns and transfer-level concerns is
retained, but with an elaboration to each level of the
architecture. The term <iref item="Internet Mail" /><iref
item="Mail" />"Internet Mail" is used to refer to the entire
collection of user and transfer components and services. </t>
<t>For Internet Mail the term <iref item="end-to-end" />
"end-to-end" usually refers to a single posting and the set of
deliveries directly resulting from its single transiting of the
MHS. A common exception is with group dialogue that is mediated
via a mailing list, so that two postings occur before intended
recipients receive an Author's message, as discussed in <xref
target="Mediator" />. In fact some uses of email consider the
entire email service -- including Author and Recipient -- as a
subordinate component. For these services "end-to-end" refers to
points outside of the email service. Examples are voicemail over
email <xref target="RFC3801" />, EDI over email <xref
target="RFC1767" /> and facsimile over email <xref
target="RFC4142" />. </t>
<figure anchor="Basic" title="Basic Internet Mail Service Model">
<?rfc needLines="28" ?>
<artwork name="Basic Internet Mail Service Model"><![CDATA[
+--------+
+---------------->| User |
| +--------+
| ^
+--------+ | +--------+ .
| User +--+--------->| User | .
+--------+ | +--------+ .
. | ^ .
. | +--------+ . .
. +-->| User | . .
. +--------+ . .
. ^ . .
. . . .
V . . .
+---+----------------+------+------+---+
| . . . . |
| +...............>+ . . |
| . . . |
| +......................>+ . |
| . . |
| +.............................>+ |
| |
| Mail Handling Service (MHS) |
+--------------------------------------+]]></artwork>
</figure>
</section>
<section anchor="Service" title="Service Overview">
<t><iref item="Mail exchange" />End-to-end Internet Mail exchange is
accomplished by using a standardized infrastructure comprising:</t>
<t>
<list>
<t>
<list style="symbols">
<t>An email object</t>
<t>Global addressing</t>
<t>An asynchronous sequence of point-to-point transfer
mechanisms</t>
<t>No prior arrangement between Author and Recipient</t>
<t>No prior arrangement between point-to-point transfer
services, over the open Internet</t>
<t>No requirement for Author and Recipient to be online
at the same time. </t>
</list>
</t>
</list>
</t>
<t>The end-to-end portion of the service is the email object, called
a message. Broadly the message, itself, distinguishes between
control information for handling, versus the author's message
content. </t>
<t>A precept to the design of mail over the open Internet is
permitting user-to-user and MTA-to-MTA interoperability to take
place with no prior, direct arrangement between the independent
administrative authorities responsible for handling a message.
That is, all participants rely on the
core<!-- grammar; reads better by changing 'having be' to 'being' -->
services being universally supported and accessible, either
directly or through gateways that translate between Internet Mail
and email environments that conform to other standards. Given the
importance of spontaneity and serendipity in the world of human
communications, this lack of prearrangement between participants
is a core benefit of Internet Mail and remains a core requirement
for it. </t>
<t>Within localized networks at the edge of the public Internet,
prior administrative arrangement often is required and can
include access control, routing constraints and information query
service configuration. In recent years one change to local
environments is an increased requirement for authentication or,
at least, accountability. In these cases a server performs
explicit validation of the client's identity. </t>
</section>
<section title="Document Conventions">
<t>In this document, references to structured fields of a message
use a two-part dotted notation. The first part cites the document
that contains the specification for the field and the second is
the name of the field. Hence <RFC2822.From> is the
From: field in an email content header and
<RFC2821.MailFrom> is the address in the SMTP "Mail
From" command. </t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 <xref target="RFC2119" />. </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="Discussion venue: ">
<iref item="Discussion of document" />Please direct
discussion about this document to the IETF-SMTP
mailing list <eref
target="http://www.imc.org/ietf-smtp" />. </t>
</list>
</t>
</list>
</t>
</section>
<section title="Changes to Previous Version">
<t>
<list style="hanging">
<t hangText="INSTRUCTIONS TO THE RFC EDITOR: ">Remove this
sub-section prior to publication.</t>
</list>
</t>
<t>Many small editing changes, for wordsmithing improvements to make
details more consistent. This section documents the nature and
basis for changes with significant impact.</t>
<t>
<list style="hanging">
<t hangText="Originator->Author: "> The term "Originator" is
used by RFC 2822 more broadly than just the From: field,
which specifically defines who the author of the content
is. I believe this distinguishes two constructs, one for
the content author and one for the first agency that
handles the message, in terms of the transfer service. So
the change from "Originator" to "Author" seems pretty
straightforward. The challenge is in using the term
Originator, as defined in RFC 2822 and applying it to the
system's architecture. </t>
<t hangText="Source->Originator: "> This change is more of a
challenge. We need the "Originator" term and construct, but
the architecture is already complex enough. Hence, adding a
new construct seems like a very poor resolution. The
document has used "Source" as an MHS term for the MSA set
of functions. While one could argue against re-labeling it
as Originator, I believe this is a reasonable choice and
likely to be comfortable for community use, since "Source"
does not have an established history. </t>
<t hangText="Bounce->Return: ">'bounce address' is not
accurate, because the address is used for more than that,
but it *is* as established term within portions of the
broader email community. I also believe the extensive
discussion on this point, last year, justifies the change.</t>
<t>The problem with saying "Bounce" is that is not merely
linguistically impure, it is plain wrong and has already
caused serious problems. Witness SPF. Frankly, we need to
fix RFC2821, but that's a separate battle to fight and not
one for this forum.</t>
<t>Although not a verbatim use of "Reverse Path", the related
term that seems to work publicly is "Return Address". It is
already established in the bricks-and-mortar postal world
and seems to have some acceptance within parts of the email
community. (I've done a draft white paper on authentication
for the Messaging Anti-Abuse Working Group and the
membership had some debate about this vocabulary choice and
converged on agreeing to it.)</t>
<t hangText="Is the envelope part of the message?">I don't
remember whether we resolved this. For a variety of
reasons, I believe the message includes its envelope, and
am encouraged to find RFC2822upd says: <list>
<t>In the context of electronic mail, messages are
viewed as having an envelope and contents. The
envelope contains whatever information is needed to
accomplish transmission and delivery. (See
[I‑D.klensin‑rfc2821bis] (Klensin, J., “Simple Mail
Transfer Protocol,” November 2007.) for a discussion
of the envelope.) The contents comprise the object to
be delivered to the recipient. This specification
applies only to the format and some of the semantics
of message contents.</t>
</list></t>
<t>rfc2821bis says: <list>
<t>SMTP transports a mail object. A mail object contains
an envelope and content.</t>
</list> I think these justify having the term 'message' as
including the object. </t>
<t hangText="Examples of 'new' messages: ">Section <xref
target="msgid" />contains a list of examples, discussing
scenarios that might or might not be viewed as creating a
"new" message, rather than retaining an existing one. The
list has been expanded.</t>
</list>
</t>
</section>
</section>
<section anchor="Actors" title="Responsible Actor Roles">
<t>Internet Mail is a highly distributed service, with a variety of
actors serving different roles. These divide into 3 basic types: </t>
<t><list>
<t>
<list style="symbols">
<t>User</t>
<t>Mail Handling Service (MHS)</t>
<t>ADministrative Management Domain (ADMD)</t>
</list>
</t>
</list>Although related to a technical architecture, the focus on
Actors concerns participant responsibilities, rather than on
functionality of modules. Hence the labels used are different than
for classic email architecture diagrams. </t>
<section anchor="Users" title="User Actors">
<t>Users are the sources and sinks of messages. They can be humans,
organizations or processes. They can have an exchange that
iterates and they can expand or contract the set of users
participating in a set of exchanges. In Internet Mail there are
three types of user-level Actors: </t>
<t><list>
<t>
<list style="symbols">
<t>Authors</t>
<t>Recipients</t>
<t>Mediators</t>
</list>
</t>
</list>From the User-level perspective all mail transfer
activities are performed by a monolithic Mail Handling Service
(MHS), even though the actual service can be provided by many
independent organizations. Users are customers of this unified
service. </t>
<figure anchor="UAs" title="Relationships Among User Actors">
<preamble>The following figure depicts the flow of messages
among<!-- reference reads better by changing 'following' to 'following figure' -->
Actors: </preamble>
<?rfc needLines="28" ?>
<artwork name="Relationships Among User Actors"><![CDATA[
+------------+
| |<---------------------------+
| Author |<----------------+ |
| |<----+ | |
+-+---+----+-+ | | |
| | | | | |
| | V | | |
| | +---------+-+ | |
| | | Recipient | | |
| | +-----------+ | |
| | | |
| | +--------+ | |
| | | | | |
| V V | | |
| +-----------+ +-+-------+-+ |
| | Mediator +--->| Recipient | |
| +-----------+ +-----------+ |
| |
| +-----------------------------+ |
| | +----------+ | |
| | | | | |
V V V | | |
+-----------+ +-----------+ +---+-+-+---+
| Mediator +--->| Mediator +--->| Recipient |
+-----------+ +-----------+ +-----------+]]></artwork>
</figure>
<section title="Author">
<t><iref item="Author" />
<iref item="Actor" subitem="Author" /> This is the user-level
participant responsible for creating the message, its contents
and its list of recipient addresses. The MHS operates to send
and deliver mail among Authors and Recipients. As described
below, the MHS has a "Source" role that correlates with the
user-level Author role. </t>
</section>
<section title="Recipient">
<t><iref item="Recipient" />
<iref item="Actor" subitem="Recipient" />The Recipient is a
consumer of delivered message content. As described below, the
MHS has a "Dest[ination]" role that correlates with the
user-level Recipient role. </t>
<t>A Recipient can close the user-level communication loop by
creating and submitting a new message that replies to an
Author. An example of an automated form of reply is the
Message Disposition Notification (MDN), <iref
item="Message Disposition Notification" />
<iref item="MDN" /> which informs the Author about the
Recipient's handling of the message. (See <xref target="Data"
/>.)</t>
</section>
<section anchor="Return" title="Return Handler">
<t>
<iref item="Return Handler" />
<iref item="Actor" subitem="Return Handler" /> The Return
Handler -- also called "Bounce Handler" -- receives and
services notifications generated by the MHS, as a result of
efforts to transfer or deliver the message. Notices can be
about failures or completions and are sent to an address that
is specified by the Source. This Return handling address (also
known as a Return address) might have no visible
characteristics in common with the address of the Author or
Source. </t>
</section>
<section anchor="Mediator" title="Mediator">
<t>
<iref item="Mediator" />
<iref item="Actor" subitem="Mediator" /> A Mediator receives,
aggregates, reformulates and redistributes messages as part of
a potentially-protracted, higher-level exchange among Users.
It is easy to confuse this user-level activity with the
underlying MHS transfer exchanges. However they serve very
different purposes and operate in very different ways.
Mediators are considered extensively in <xref
target="Mediators" />. </t>
<t>When mail is delivered to a receiving mediator specified in
the RFC2821.RcptTo command, the MHS handles it the same way as
for any other Recipient. That is, the MHS only sees posting
and delivery sources and sinks and does not see (later)
re-posting as a continuation of a process. Hence when
submitting messages, the Mediator is an Author. </t>
<t>The distinctive aspects of a Mediator are, therefore, above
the MHS. A Mediator preserves the Author information of the
message it reformulates, but may make meaningful changes to
the content. Hence the MHS sees a new message, but Users
receive a message that is interpreted as primarily being from
-- or, at least, initiated by -- the author of the original
message. The role of a Mediator permits distinct, active
creativity, rather than being limited to the more constrained
job of merely connecting together other participants. Hence it
is really the Mediator that is responsible for the new
message. </t>
<t>A Mediator's task can be complex and contingent, such
as<!-- grammar; reads better by changing 'by modifying' to 'modifying' -->
modifying and adding content or regulating which users are
allowed to participate and when. The popular example of this
role is a group mailing list. A sequence of Mediators may even
perform a series of formal steps, such as reviewing, modifying
and approving a purchase request. </t>
<t>Because a Mediator originates messages, it can also receive
replies. So a Mediator really is a full-fledged User. </t>
<t>
<list style="hanging">
<t hangText="Gateway: ">
<iref item="Gateway" /> A Gateway is a particularly
interesting form of Mediator. It is a hybrid of User and
Relay that interconnects heterogeneous mail services.
Its goal is to emulate a Relay, and a detailed
discussion is in <xref target="mhs-gateway" />. </t>
</list>
</t>
</section>
</section>
<section anchor="MHS" title="Mail Handling Service (MHS) Actors">
<iref item="MHS" />
<iref item="Mail Handling System" />
<iref item="MHS" subitem="Actors" />
<iref item="Actors" subitem="MHS" />
<t>The Mail Handling Service (MHS) has the task of performing a
single, end-to-end transfer on behalf of the Author and reaching
the Recipient address(es) specified in the original
RFC2821.RcptTo commands. Mediated or protracted, iterative
exchanges, such as those used for collaboration over time, are
part of the User-level service, and are not part of this
transfer-level Handling Service. </t>
<figure anchor="MHSs" title="Relationships Among MHS Actors">
<preamble>The following figure depicts the relationships
among<!-- reference reads better by changing 'following' to 'following figure' -->
transfer participants in Internet Mail. It shows the Source as
distinct from the Author, and Dest[ination] as distinct from
Recipient, although it is common for each pair to be the same
actor. Transfers typically entail one or more Relays. However
direct delivery from the Source to Destination is possible.
For intra-organization mail services, it is common to have
only one Relay. </preamble>
<?rfc needLines="28" ?>
<artwork name="Relationships Among MHS Actors"><![CDATA[
+------------+ +-----------+
| Author | +--------+ | Recipient |
+-----+------+ +....>| Return | +-----------+
| . +--------+ ^
| . ^ |
//===================================================\\
|| | . | Mail Handling | ||
|| | . | Service (MHS) | ||
V . | |
+---------+ . ^ +----+---+
| | . | | |
| Origin +....+ +-<------------+ Dest |
| | | | |
+----+----+ | +--------+
| | ^
| +-------------->-+-<-------------+ |
V | | | |
+-------+-+ +----+----+ +-+---+---+
| Relay +-->...-->| Relay +------->| Relay |
+---------+ +----+----+ +---------+
|
V
+---------+
| Gateway +-->...
+---------+]]></artwork>
</figure>
<section title="Originator">
<t><iref item="Originator" /><iref item="Actor"
subitem="Originator" />The Originator role is responsible
for ensuring that a message is valid for posting and then
submitting it to a Relay. Validity includes conformance with
Internet Mail standards, as well as with local operational
policies. The Originator can simply review the message for
conformance and reject it if there are errors, or it can
create some or all of the necessary information. </t>
<t>The Originator operates with dual "allegiance". It serves the
Author and often it is the same entity. However its role in
assuring validity means that it MUST also represent the local
operator of the MHS, that is, the local ADministrative
Management Domain (ADMD). </t>
<t>The Originator also has the responsibility for any
post-submission, Author-related administrative tasks
associated with message transmission and delivery. Notably
this pertains to error and delivery notices. Hence Source is
best held accountable for the message content, even when they
did not create any or most of it. </t>
</section>
<section title="Relay" anchor="relay">
<t><iref item="Relay" /><iref item="Actor" subitem="Relay" />A
mail Relay performs email transfer-service routing and
store-and-forward by (re-)transmitting the message on towards
its Recipient(s). A Relay can add trace information. However
it does not modify existing envelope information or the
message content semantics. It can modify message content
syntax, such as a change from binary to
text<!-- changing binary to text is common; changing text to binary is rare; change 'text to binary' to 'binary to text' -->
transfer-encoding form, only as required to meet the
capabilities of the next hop in the MHS. </t>
<t>A set of Relays composes a Mail Handling Service (MHS)
network. This is above any underlying packet-switching network
that they might be using and below any gateways or other
user-level Mediators. </t>
<t>In other words, interesting email scenarios can involve three
distinct architectural layers of store-and-forward service:</t>
<t><list>
<t>
<list style="symbols">
<t>User Mediators</t>
<t>MHS Relays</t>
<t>Packet Switches</t>
</list>
</t>
</list> with the bottom-most usually being the Internet's IP
service. The most basic email scenarios involve Relays and
Switches. </t>
<t>Aborting a message transfer results in having the Relay become
an Author and sending an error message to the Return address.
The potential for looping is avoided by having this message,
itself, contain no Return address. </t>
</section>
<section anchor="mhs-gateway" title="Gateway">
<t>
<iref item="Gateway" />
<iref item="Actor" subitem="Gateway" /> A Gateway is a hybrid
form of User and Relay that interconnects heterogeneous mail
services. Its purpose is simply to emulate a Relay and the
closer it comes to this, the better. However it operates at
the User level, because it MUST be able to modify message
content. </t>
<t>Differences between mail services can be as small as minor
syntax variations, but usually encompass significant, semantic
distinctions. One difference could have the concept of an
email address being a hierarchical,
machine-specific<!-- grammar; reads better by changing 'be' to 'being' -->
address, versus having it be a flat, global name space.
Another difference could be between text-only content, versus
multi-media. Hence the Relay function in a Gateway offers
significant design challenges, to make the result be as
seamless as possible. The most significant challenge is in
ensuring the user-to-user functionality that matches syntax
and semantics of independent email standards suites. </t>
<t>The basic test of a Gateway's adequacy is, of course, whether
an Author on one side of a Gateway can send a useful message
to a Recipient on the other side, without requiring changes to
any of the components in the Author's or Recipient's mail
services, other than adding the Gateway. To each of these
otherwise independent services, the Gateway will appear to be
a "native" participant. However the ultimate test of a
Gateway's adequacy is whether the Author and Recipient can
sustain a dialogue. In particular can a Recipient's MUA
automatically formulate a valid Reply that will reach the
initial Author?</t>
</section>
</section>
<section anchor="Administrative" title="Administrative Actors">
<t>Actors often are associated with different organizations, each
with its own administrative authority. This operational
independence, coupled with the need for interaction between
groups, provides the motivation for distinguishing among <iref
item="Administrative Actors" /><iref item="Actor"
subitem="Administrative" />ADministrative Management Domains
(ADMD). Each ADMD can have vastly different operating policies
and trust-based decision-making. An obvious example is the
distinction between mail that is exchanged within a single
organization, versus mail that is exchanged between independent
organizations. The rules for handling these two types of traffic
tend to be quite different. That difference requires defining the
boundaries of each, and this requires the ADMD construct. </t>
<t>Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be an independent ADMD. This
independence of administrative decision-making defines boundaries
that distinguish different portions of the Internet Mail service.
Examples include an end-user operating their desktop client, a
department operating a local Relay, an IT department operating an
enterprise Relay and an ISP operating a public shared email
service. These can be configured into many combinations of
administrative and operational relationships, with each ADMD
potentially having a complex arrangement of functional
components. <xref target="ADMD" /> depicts relationships among
ADMDs. The benefit of having the ADMD construct is to facilitate
discussion about designs and operations that need to distinguish
between "internal" issues and "external" ones. </t>
<t>The architectural impact of needing to have boundaries between
ADMD's is discussed in <xref target="Tussle" />. Most significant
is that the entities communicating across ADMD boundaries will
typically have an added burden to enforce organizational policies
concerning "external" communications. At a more mundane level,
routing mail between ADMDs can be an issue, such as needing to
route mail for partners over specially-trusted paths. </t>
<t>Basic types of ADMDs include -- </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="Edge: "><iref item="Edge Actor" /><iref
item="Actor" subitem="Edge" />Independent transfer
services, in networks at the edge of the open
Internet Mail service. </t>
<t hangText="User: "><iref item="User Actor" /><iref
item="Actor" subitem="User" />End-user services.
This might be subsumed under the Edge service, such
as is common for web-based email access. </t>
<t hangText="Transit: "><iref item="Transit Actor"
/><iref item="Actor" subitem="Transit" />These
are Mail Service Providers (MSP) offering value-added
capabilities for Edge ADMDs, such as aggregation and
filtering. </t>
</list>
</t>
</list>
</t>
<figure anchor="ADMD" title="ADMD Example">
<preamble>Note that Transit services are quite different from
packet-level switching operation. Whereas end-to-end packet
transfers usually go through intermediate routers, email
exchange across the open Internet is often directly between
the Boundary MTAs of Edge ADMDs, at the email level. This
further highlights the differences discussed in <xref
target="relay" /></preamble>
<?rfc needLines="15" ?>
<artwork
name="ADministrative Management Domain (ADMD)
Example"><![CDATA[
+-------+ +-------+ +-------+
| ADMD1 | | ADMD3 | | ADMD4 |
| ----- | | ----- | | ----- |
| | +---------------------->| | | |
| User | | |-Edge--+--->|-User |
| | | | +---------+ +--->| | | |
| V | | | ADMD2 | | +-------+ +-------+
| Edge--+---+ | ----- | |
| | | | | |
+-------+ +----|-Transit-+---+
| |
+---------+]]></artwork>
</figure>
<t>Edge networks can use proprietary email standards internally.
However the distinction between Transit network and Edge network
transfer services is primarily significant because it highlights
the need for concern over interaction and protection between
independent administrations. In particular this distinction calls
for additional care in assessing transitions of responsibility,
as well as the accountability and authorization relationships
among participants in email transfer. </t>
<t>The interactions between functional components within an ADMD are
subject to the policies of that domain. Policies can cover such
things as:<list style="symbols">
<t>Reliability</t>
<t>Access control</t>
<t>Accountability</t>
<t>Content evaluation and modification</t>
</list> They can be implemented in different functional
components, according to the needs of the ADMD. For example see
<xref target="RFC5068" />. </t>
<t>User, Edge and Transit services can be offered by providers that
operate component services or sets of services. Further it is
possible for one ADMD to host services for other ADMDs.</t>
<t>Common ADMD examples are -- </t>
<t>
<list>
<t>Enterprise Service Providers: </t>
<t>
<list>
<t>Operating an organization's internal data and/or mail
services. </t>
</list>
</t>
</list>
<list>
<t>Internet Service Providers: </t>
<t>
<list>
<t>Operating underlying data communication services
that, in turn, are used by one or more Relays and
Users. It is not necessarily their job to perform
email functions, but they can, instead, provide an
environment in which those functions can be
performed. </t>
</list>
</t>
</list>
<list>
<t>Mail Service Providers: </t>
<t>
<list>
<t>Operating email services, such as for end-users, or
mailing lists. </t>
</list>
</t>
</list>
</t>
<t>Operational pragmatics often dictate that providers be involved
in detailed administration and enforcement issues, to help ensure
the health of the overall Internet Mail Service. This can include
operators of lower-level packet services. </t>
</section>
</section>
<section title="Identities">
<t>Internet Mail uses three forms of identity: mailbox, domain name and
message-id. Each is required to be globally unique. </t>
<section title="Mailbox">
<t>
<list>
<t>"A mailbox sends and receives mail. It is a conceptual
entity which does not necessarily pertain to file storage."
<xref target="RFC2822" />
</t>
</list> A mailbox is specified as an Internet Mail address
<addr-spec>. It has two distinct parts, divided by
an at-sign ("@"). The right-hand side is a globally interpreted
domain name that is associated with an ADMD. Domain Names are
discussed in <xref target="DNS" />. Formal Internet Mail
addressing syntax can support source routes, to indicate the path
through which a message should be sent. Although legal, the use
of source routes is not part of the modern Internet Mail service
and it is not discussed further. </t>
<t>The portion to the left of the at-sign contains a string that is
globally opaque and is called the <local-part>. It
is to be interpreted only by the entity specified by the
address's right-hand side domain name. All other entities MUST
treat the local-part as a uninterpreted literal string and MUST
preserve all of its original details. As such its public
distribution is equivalent to sending a Web browser "cookie" that
is only interpreted upon being returned to its Author. </t>
<section title="Global Standards for Local-Part">
<t>It is common for sites to have local structuring conventions
for the left-hand side <local-part> of an
<addr-spec>. This permits sub-addressing, such
as for distinguishing different discussion groups used by the
same participant. However it is worth stressing that these
conventions are strictly private to the user's organization
and SHOULD NOT be interpreted by any domain except the one
listed in the right-hand side of the addr-spec. The exceptions
are those specialized services conforming to standardized
conventions, as noted below. </t>
<t>There are a few types of addresses that have an elaboration on
basic email addressing, with a standardized, global schema for
the local-part. These are conventions between authoring
systems and Recipient Gateways, and they are invisible to the
public email transfer infrastructure. When an Author is
explicitly sending via a Gateway out of the Internet, there
are coding conventions for the local-part, so that the Author
can formulate instructions for the Gateway. Standardized
examples of this are the telephone numbering formats for VPIM
<xref target="RFC3801" />, such as
"+16137637582@vpim.example.com", and iFax <xref
target="RFC3192" />, such as
"FAX=+12027653000/T33S=1387@ifax.example.com". </t>
</section>
<section title="Scope of Email Address Use">
<t>Email addresses are being used far beyond their original email
transfer and delivery role. In practical terms, an email
address string has become the common identifier for
representing online identity. What is 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 entity
responsible for setting that string. For example, see: <xref
target="identref" />, <xref target="mda" />, <xref
target="Mediators" />. </t>
</section>
</section>
<section anchor="DNS" title="Domain Names">
<t>A domain name is a global reference to an Internet resource, such
as a host, a service or a network. A domain name usually maps to
one or more IP Addresses. Conceptually the name might encompass
an entire organization, a collection of machines integrated into
a homogeneous service, or only a single machine. A domain name
can be administered to refer to individual users, but this is not
common practice. The name is structured as a hierarchical
sequence of sub-names, separated by dots ("."), with the top of
the hierarchy being on the right-end of the sequence. Domain
names are defined and operated through the Domain Name System
(DNS) <xref target="RFC1034" />, <xref target="RFC1035" />, <xref
target="RFC2181" />. </t>
<t>When not part of a mailbox address, a domain name is used in
Internet Mail to refer to the ADMD or the host that took action
upon the message, such as providing the administrative scope for
a message identifier, or performing transfer processing. </t>
</section>
<section title="Message Identifier">
<t>There are two standardized tags for identifying
messages:<!-- grammar; reads better without the comma; change 'tags,' to 'tags' -->
Message-ID and ENVID.</t>
<section anchor="msgid" title="Message-ID">
<t> The Message-ID is a user-level tag, primarily used for
threading and for eliminating duplicates <xref
target="RFC2822" />. Any actor within the Originating ADMD
can assign the Message-ID. The recipient's ADMD is the
intended consumer of the Message-ID, although any actor along
the transfer path might use it. Internet Mail standards
provide for a single Message-ID; however more than one is
sometimes assigned. </t>
<t>Like a mailbox address, a Message-ID has two distinct parts,
divided by an at-sign ("@"). The right-hand side is globally
interpreted and specifies the ADMD or host assigning the
identifier. The left-hand side contains a string that is
globally opaque and 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. </t>
<t>When a message is revised in any way, the question of whether
to assign a new Message-ID requires a subjective assessment,
deciding whether the editorial content has been changed enough
to constitute a new message. <xref target="RFC2822" /> says "a
message identifier pertains to exactly one instantiation of a
particular message; subsequent revisions to the message each
receive new message identifiers." However real-world
experience dictates some flexibility. An impossible test is
whether the recipient will consider the new message to be
equivalent to the old. For most components of Internet Mail,
there is no way to predict a specific recipient's preferences
on this matter. Both creating and failing to create a new
Message-ID have their downsides. </t>
<t> The best that can be offered, here, are some guidelines and
examples: </t>
<t>
<list>
<t>
<list style="symbols">
<t>If a message is changed only in terms of form,
such as character-encoding, it clearly is still
the same message. </t>
<t>If a message has minor additions to the content,
such as a mailing list tag at the beginning of the
RFC2822.Subject header field, or some mailing list
administrative information added to the end of the
primary body-part's text, then it probably is
still the same message. </t>
<t>If a message has viruses deleted from it, it
probably is still the same message. </t>
<t>If a message has offensive words deleted from it,
then some recipients will consider it the same
message, but some will not. </t>
<t>If a message is translated into a different
language, then some recipients will consider it
the same message, but some will not. </t>
<t>If a message is included in a digest of messages,
it the digest constitutes a new message.</t>
<t> If a message is forwarded by a recipient, what is
forwarded is considered to be a new message.</t>
<t>If a message is "redirected", such as using
RFC2822 "Redirect-*" headers, some recipients will
consider it the same message, but some will
not.</t>
</list>
</t>
</list>
</t>
<t>The absence of objective, precise criteria for Message-ID
re-generation, along with the absence of strong protection
associated with the string, means that the presence of an ID
can permit an assessment that is marginally better than a
heuristic, but the ID certainly has no value on its own for
strict formal reference or comparison. Hence Message-ID SHOULD
NOT be used for any function that has security implications.
</t>
</section>
<section anchor="envid" title="ENVID">
<t>The ENVID (envelope identifier) is a tag that is primarily for
use within Delivery Status Notifications (DSN), so that the
Return Address (RFC2821.MailFrom) recipient can correlate the
DSN with a particular message <xref target="RFC3461" />. The
ENVID is therefore used from one message posting, until the
directly-resulting message deliveries. It does not survive
re-postings. </t>
<t>The ENVID may also be used for message tracking purposes <xref
target="RFC3885" />. </t>
<!-- added note about msgtrk -->
<t>The format of an ENVID is free-form. Although its creator
might choose to impose structure on the string, none is
imposed by Internet standards. By implication, the scope of
the string is defined by the domain name of the Return
Address. </t>
</section>
</section>
</section>
<section title="Services and Standards">
<t>Internet Mail's architecture distinguishes among six basic types of
functionality, arranged to support a store-and-forward service
architecture. As shown in <xref target="Protocols" /> these types
can have multiple instances, some of which represent specialized
sub-roles. This section considers the activities and relationships
among these components, and the Internet Mail standards that apply
to them.</t>
<t>
<list>
<t>
<list style="numbers">
<t>Message</t>
<t>Mail User Agent (MUA)<list style="empty">
<t>Originating MUA (oMUA)</t>
<t>Receiving MUA (rMUA)</t>
</list>
</t>
<t>Message Submission Agent (MSA)<list style="empty">
<t>Author-focussed MSA functions (oMSA)</t>
<t>MHS-focussed MSA functions (hMSA)</t>
</list>
</t>
<t>Message Transfer Agent (MTA)</t>
<t>Message Delivery Agent (MDA)<list style="empty">
<t>Recipient-focused MDA functions (rMDA)</t>
<t>MHS-focussed MDA functions (hMDA)</t>
</list>
</t>
<t>Message Store (MS)<list>
<t>Author MS (oMS) <list style="empty">
<t>oMS on a remote server (soMS)</t>
<t>oMS co-located with the oMUA (uoMS)</t>
</list></t>
<t>Recipient MS (rms) <list style="empty">
<t>rMS on a remote server (srMS)</t>
<t>rMS co-located with the rMUA (urMS)</t>
</list>
</t>
</list>
</t>
</list>
</t>
</list>
</t>
<t>This section describes each functional component for Internet Mail,
and the standards-based protocols associated with their operation. </t>
<t>Software implementations of these architectural components often
compress them, such as having the same software do MSA, MTA and MDA
functions. However the requirements for each of these components of
the service are becoming more extensive. So their separation is
increasingly common. </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="NOTE: ">A discussion about any interesting
system architecture is often complicated by confusion
between architecture versus implementation. An
architecture defines the conceptual functions of a
service, divided into discrete conceptual modules. An
implementation of that architecture can combine or
separate architectural components, as needed for a
particular operational environment.</t>
<t>A software system that primarily performs message
relaying -- and therefore is an MTA -- might also
include MDA functionality. That same MTA system might be
able to interface with non-Internet email services and
therefore qualify as a Gateway.</t>
<t>It is important not to confuse the engineering decisions
made to implement a product, with the architectural
abstractions used to define conceptual functions. </t>
</list>
</t>
</list>
</t>
<figure anchor="Protocols" title="Protocols and Services">
<preamble>The following figure shows function modules and the
standardized protocols used between them. Additional protocols
and configurations are possible. Boxes defined by asterisks (*)
represent functions that often are distributed among two or more
systems. </preamble>
<?rfc needLines="48" ?>
<artwork name="Protocols and Services"><![CDATA[
+------+ +-------+
............+ oMUA |..............................| Disp |
. +--+-+-+ +-------+
. local,imap}| |{smtp,submission ^
. | | +---------+ |
. ******* | | .......................| Returns | |
. * oMS *<-----+ | . +---------+ |
. ******* | . ***************** ^ |
. +------V-.---*------------+ * | |
. MSA | +-------+ * +------+ | * | |
. | | oMSA +--O-->| hMSA | | * | |
. | +-------+ * +--+---+ | * | |
. +------------*------+-----+ * | |
//==========\\ * V {smtp * | |
|| MESSAGE || * +------+ * //===+===\\ |
||----------|| MHS * | MTA | * || dsn || |
|| Envelope || * +--+---+ * \\=======// |
|| SMTP || * V {smtp * ^ ^ |
|| Content || * +------+ * | | //==+==\\
|| RFC2822 || * | MTA +----*-----+ | || mdn ||
|| MIME || * +--+---+ * | \\=====//
\\==========// * smtp}| {local * | |
. MDA * | {lmtp * | |
. +------------+------V-----+ * | |
. | +------+ * +------+ | * | |
. | | | * | | +--*---------+ |
. | | rMDA |<--O---+ hMDA | | * |
. | | | * | | |<-*-------+ |
. | +-+----+ * +------+ | * | |
. +---+--+-----*------------+ * | |
. | | ***************** | |
. pop} +--+ +---+ | |
. imap} | | {local | |
. ******************V******** | |
. * | +------+ * rMS //===+===\\ |
. * | | srMS | * || sieve || |
. * V +--+-+-+ * \\=======// |
. * +------+ pop} | | * ^ |
. * | urMS |<-------+ | * | |
. * +--+---+ imap} | * | |
. *************************** | |
. local}| +------+ |{pop,imap | |
. +->| |<------+ | |
...........>| rMUA +---------------------------+ |
| +-----------------------------------+
+------+]]></artwork>
</figure>
<section anchor="Data" title="Message Data">
<t>The purpose of the Mail Handling Service (MHS) is to exchange a
message object among participants <xref target="RFC2822" />,<!-- move ','. It wasn't being placed properly by xml2rfc. -->
<xref target="RFC0822" />. Hence all of its underlying mechanisms
are merely in the service of getting that message from its Author
to its Recipients. A message can be explicitly labeled as to its
nature <xref target="RFC3458" />. </t>
<t>A message comprises a transit handling envelope and the message
content. The envelope contains information used by the MHS. The
content is divided into a structured header and the body. The
header comprises transit trace information and end-user
structured fields. The body may be unstructured simple lines of
text, or it may be a MIME tree of multi-media subordinate
objects, called body-parts, or attachments <xref target="RFC2045"
/>, <xref target="RFC2046" />, <xref target="RFC2047" />, <xref
target="RFC4288" />, <xref target="RFC4289" />, <xref
target="RFC2049" />. </t>
<t>In addition, Internet Mail has a few conventions for special
control data -- </t>
<t>
<list>
<t>Delivery Status Notification (DSN): </t>
<t>
<list>
<t>A Delivery Status Notification (DSN) is a message
that can be generated by the MHS (MSA, MTA or MDA)
and sent to the RFC2821.MailFrom address. The mailbox
for this is shown as Returns in <xref
target="Protocols" />. DSNs provide information
about message transit, such as transmission errors or
successful delivery <xref target="RFC3461" />. </t>
</list>
</t>
<t>Message Disposition Notification (MDN):</t>
<t>
<list>
<t>A Message Disposition Notification (MDN) is a message
that provides information about user-level,
Recipient-side message processing, such as indicating
that the message has been displayed <xref
target="RFC3798" /> or the form of content that
can be supported <xref target="RFC3297" />. It can be
generated by an rMUA and is sent to the
Disposition-Notification-To address(es). The mailbox
for this is shown as Disp in <xref target="Protocols"
/>. </t>
</list>
</t>
<t>Message Filtering (SIEVE): </t>
<t>
<list>
<t>SIEVE is a scripting language that permits specifying
conditions for differential handling of mail,
typically at the time of delivery <xref
target="RFC3028" />. It can be conveyed in a
variety of ways, as a MIME part. <xref
target="Protocols" /> shows a Sieve specification
going from the rMUA to the MDA. However filtering can
be done at many different points along the transit
path and any one or more of them might be subject to
Sieve directives, especially within a single ADMD.
Hence the Figure shows only one relationship, for
(relative) simplicity. </t>
</list>
</t>
</list>
</t>
<section title="Envelope">
<t>Internet Mail has a fragmented framework for transit-related
"handling" information. Information that is directly used by
the MHS is called the "envelope". It directs handling
activities by the transfer service as is carried in transfer
service commands. That is, the envelope exists in
the<!-- typo: change 'The' to 'the' --> transfer protocol SMTP
<xref target="RFC2821" />. </t>
<t>Trace information records handling activity and is recorded in
the message Header. <xref target="RFC2822" /></t>
</section>
<section anchor="Fields" title="Header Fields">
<t>Header fields are attribute name/value pairs covering an
extensible range of email service, user content and user
transaction meta-information. The core set of header fields is
defined in <xref target="RFC2822" />, <xref target="RFC0822"
/>. It is common to extend this set, for different
applications. Procedures for registering header fields are
defined in <xref target="RFC4021" />. An extensive set of
existing header field registrations is provided in <xref
target="RFC3864" />. </t>
<t>One danger with placing additional information in header
fields is that Gateways often alter or delete them. </t>
</section>
<section title="Body">
<t>The body of a message might simply be lines of ASCII text or
it might be hierarchically structured into a composition of
multi-media body-part attachments, using MIME <xref
target="RFC2045" />, <xref target="RFC2046" />, <xref
target="RFC2047" />, <xref target="RFC4288" />, <xref
target="RFC2049" />. MIME structures each body-part into a
recursive set of MIME header field meta-data and MIME Content
sections. </t>
</section>
<section title="Identity References in a Message" anchor="identref">
<t>For a message in transit, the core uses of identifiers combine
into:</t>
<texttable title="Layered Identities">
<ttcol>Layer</ttcol>
<ttcol>Field</ttcol>
<ttcol>Set By</ttcol>
<c>Message Body</c>
<c>MIME Header</c>
<c>Author</c>
<c>Message header fields</c>
<c>From</c>
<c>Author</c>
<c />
<c>Sender</c>
<c>Source</c>
<c />
<c>Reply-To</c>
<c>Author</c>
<c />
<c>To, CC, BCC</c>
<c>Author</c>
<c />
<c>Message-ID</c>
<c>Source</c>
<c />
<c>Received</c>
<c>Source, Relay, Dest</c>
<c />
<c>Return-Path</c>
<c>MDA, from MailFrom</c>
<c />
<c>Resent-*</c>
<c>Mediator</c>
<c />
<c>List-Id</c>
<!-- 'List-Id' was missing -->
<c>Mediator Author</c>
<c />
<c>List-*</c>
<!-- 'List-*' was missing -->
<c>Mediator Author</c>
<c>SMTP</c>
<c>HELO/EHLO</c>
<!-- left off 'EHLO'. You list it everywhere else you specify HELO, so why not here? -->
<c>Latest Relay Client</c>
<c />
<c>ENVID</c>
<c>Source</c>
<c />
<c>MailFrom</c>
<c>Source</c>
<c />
<c>RcptTo</c>
<c>Author</c>
<c>IP</c>
<c>Source Address</c>
<c>Latest Relay Client</c>
</texttable>
<t>The most common address-related fields are: <list
style="hanging">
<t hangText="RFC2822.From: ">Set by - Author</t>
<t>Names and addresses for author(s) of the message content
are listed in the From: field.</t>
<t hangText="RFC2822.Reply-To: ">Set by - Author</t>
<t>If a message Recipient sends a reply message that would
otherwise use the RFC2822.From field address(es) that
are contained in the original message, then they are
instead to use the address(es) in the RFC2822.Reply-To
field. In other words this field is a direct override of
the From: field, for responses from Recipients. </t>
<t hangText="RFC2822.Sender: ">Set by - Source</t>
<t>This specifies the address responsible for submitting
the message into the transfer service. For efficiency
this field can be omitted if it contains the same
address as RFC2822.From. However this does not mean
there is no Sender specified. Rather it means that that
header field is virtual and that the address in the
From: field MUST be used. </t>
<t>Specification of the notifications Return addresses --
contained in RFC2821.MailFrom -- is made by the
RFC2822.Sender. Typically the Return address is the same
as the Sender address. However some usage scenarios
require it to be different. </t>
<t hangText="RFC2822.To/.CC: ">Set by - Author</t>
<t>These specify MUA Recipient addresses. However some or
all of the addresses in these fields might not be
present in the RFC2821.RcptTo commands. </t>
<t> 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. </t>
<t hangText="RFC2822.BCC: ">Set by - Author</t>
<t>A message might be copied to an addressee whose
participation is not to be disclosed to the RFC2822.To
or RFC2822.CC Recipients and, usually, not to the other
BCC Recipients. The BCC header field indicates a message
copy to such a Recipient. </t>
<t>Typically, the field lists no addresses or only lists
the single address of the Recipient receiving this copy.
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 of the Author. </t>
<t hangText="RFC2821.HELO/.EHLO: ">Set by - Source</t>
<t>The MSA can specify its hosting domain identity for the
SMTP HELO or EHLO command operation. </t>
<t hangText="RFC3461.ENVID: ">Set by - Source</t>
<t>The MSA can specify an opaque string, to be included in
a DSN, as a means of assisting the Return address
recipient in identifying the message that produced a
DSN, or message tracking.</t>
<!-- add 'or message tracking' -->
<t hangText="RFC2821.MailFrom: ">Set by - Source</t>
<t>This is an end-to-end string that specifies an email
address for receiving return control information, such
as "bounces". The name of this field is misleading,
because it is not required to specify either the author
or the Actor responsible for submitting the message.
Rather, the Actor responsible for submission specifies
the RFC2821.MailFrom address. Ultimately the simple
basis for deciding what address needs to be in the
RFC2821.MailFrom is to determine what address needs to
be informed about transmission-level problems (and,
possibly, successes.)</t>
<t hangText="RFC2821.RcptTo: ">Set by - Author</t>
<t>This specifies the MUA mailbox address of a recipient.
The string might not be visible in the message content
header. For example, the message destination address
header fields, such as RFC2822.To, might specify a
mailing list mailbox, while the RFC2821.RcptTo address
specifies a member of that list. </t>
<t hangText="RFC2821.Received: ">Set by - Source, Relay,
Mediator, Dest</t>
<t>This indicates trace information, including originating
host, relays, Mediators, and MSA host domain names
and/or IP Addresses. </t>
<t hangText="RFC2821.Return-Path: ">Set by - Source</t>
<t>The MDA records the RFC2821.MailFrom address into the
RFC2822.Return-Path field. </t>
<t hangText="RFC2919.List-Id: ">Set by - Mediator Author</t>
<t>This provides a globally unique mailing list naming
framework that is independent of particular hosts. <xref
target="RFC2919" /></t>
<t>The identifier is in the form of a domain name; however
the string usually is constructed by combining the two
parts of an email address and the result rarely is a
true domain name, listed in the domain name service --
although it can be. </t>
<t hangText="RFC2369.List-*: ">Set by - Mediator Author</t>
<t>
<xref target="RFC2369" /> defines a collection of
message header fields for use by mailing lists. In
effect they supply list-specific parameters for common
mailing list user operations. The identifiers for these
operations are for the list, itself, and the
user-as-subscriber <xref target="RFC2369" />.</t>
<t hangText="RFC0791.SourceAddr: ">Set by - The Client
SMTP sending host immediately preceding the current
receiving SMTP server.</t>
<t><xref target="RFC0791" /> defines the basic unit of data
transfer for the Internet, the IP Datagram. It contains
a "Source Address" field that specifies the IP Address
for the host (interface) from which the datagram was
sent. This information is set and provided by the IP
layer, and is therefore independent of mail-level
mechanisms. As such, it is often taken to be
authoritative, although it is possible to provide false
addresses. </t>
<t />
<t />
</list>
</t>
</section>
</section>
<section title="User-Level Services">
<t>Interactions at the user level entail protocol exchanges,
distinct from those that occur at lower layers of the Internet
Mail architecture, which is above the Internet Transport layer.
Because the motivation for email, and much of its use, is for
interaction among humans, the nature and details of these
protocol exchanges often are determined by the needs of human and
group communication. In terms of efforts to specify behaviors,
one effect of this is to require subjective guidelines, rather
than strict rules, for some aspects of system behavior. Mailing
Lists provide particularly salient examples of this. </t>
<section title="Mail User Agent (MUA)">
<t>A Mail User Agent (MUA) works on behalf of end-users and
end-user applications. It is their "representative" within the
email service. </t>
<t>The Origination-side MUA (oMUA) creates a message and performs
initial "submission" into the transfer infrastructure, via a
Mail Submission Agent (MSA). It can also perform any creation-
and posting-time archival in its Message Store (oMS). An MUA's
oMS will typically include a folder for messages under
development (Drafts), a folder for messages waiting to be sent
(Queued or Unsent) and a folder for messages that have been
successfully posted for transmission (Sent). </t>
<t>The Recipient-side MUA (rMUA) works on behalf of the end-user
Recipient to process received mail. This includes generating
user-level return control messages, displaying and disposing
of the received message, and closing or expanding the user
communication loop, by initiating replies and forwarding new
messages. </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="NOTE: ">Although not shown in <xref
target="Protocols" />, an MUA can, itself, have
a distributed implementation, such as a "thin"
user interface module on a limited end-user
device, with the bulk of the MUA functionality
operated remotely on a more capable server. An
example of such an architecture might use IMAP
<xref target="RFC3501" /> for most of the
interactions between an MUA client and an MUA
server. A standardized approach for such scenarios
is defined by <xref target="RFC4550" />. </t>
</list>
</t>
</list>
</t>
<t>A Mediator is special class of MUA. It performs message
re-posting, as discussed in <xref target="Users" />. </t>
<t>Identity fields relevant to a typical end-user MUA include: </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="RFC2822.From" />
<t hangText="RFC2822.Reply-To" />
<t hangText="RFC2822.Sender" />
<t hangText="RFC2822.To, RFC2822.CC" />
<t hangText="RFC2822.BCC" />
</list>
</t>
</list>
</t>
</section>
<section title="Message Store (MS)">
<t>An MUA can employ a long-term Message Store (MS). <xref
target="Protocols" /> depicts an Origination-side MS (oMS)
and a Recipient-side MS (rMS). There is a rich set of choices
for configuring a store, because any MS may comprise a
distributed set of component stores. In <xref
target="Protocols" />, the rMS demonstrates this by showing
an rMS that is located on a remote server (srMS) and an rMS
that is on the same machine as the MUA (urMS). The
relationship between two message stores, themselves, can vary. </t>
<t>As discussed in <xref target="RFC1733" /> the operational
relationship among MSs can be -- </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="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. </t>
<t hangText="Offline: ">The MS is local to the user,
and messages are completely moved from any remote
store, rather than (also) being retained there. </t>
<t hangText="Disconnected: ">An rMS and a uMS are
kept synchronized, for all or part of their
contents, while there is a connection between
them. While they are disconnected, mail can
continue to arrive at the rMS and the user may
continue to make changes to the uMS. Upon
reconnection, the two stores are re-synchronized.
</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="MHS-Level Services">
<section title="Mail Submission Agent (MSA)">
<t>A Mail Submission Agent (MSA) accepts the message submission
from the oMUA and enforces the policies of the hosting ADMD
and the requirements of Internet standards. An MSA represents
an unusual functional dichotomy. A portion of its task is to
represent MUA (uMSA) interests during message posting, to
facilitate posting success, and another portion is to
represent MHS (hMSA) interests. This is best modeled, as shown
in <xref target="Protocols" />, with two sub-components, one
for the oMUA (oMSA) and one for the MHS (hMSA)</t>
<t>The hMSA's function is to take transit responsibility for a
message that conforms to the relevant Internet standards and
to local site policies. It rejects messages that are not in
conformance. The oMSA's is to perform final message
preparation for submission and to effect the transfer of
responsibility to the MHS, via the hMSA. The amount of
preparation will depend upon the local implementations.
Examples of oMSA tasks could be to add header fields, such as
Date: and Message-ID, to modify portions of the message from
local notations to Internet standards, such as expanding an
address to its formal RFC2822 representation. </t>
<t>Historically, standards-based MUA/MSA interactions have used
SMTP <xref target="RFC2821" />. A recent alternative is
SUBMISSION <xref target="RFC4409" />. Although SUBMISSION
derives from SMTP, it uses a separate TCP port and imposes
distinct requirements, such as access authorization. </t>
<t>Identities relevant to the MSA include: </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="RFC2821.HELO/.EHLO" />
<t hangText="RFC3461.ENVID" />
<t hangText="RFC2821.MailFrom" />
<t hangText="RFC2821.RcptTo" />
<t hangText="RFC2821.Received" />
</list>
</t>
</list>
</t>
</section>
<section title="Mail Transfer Agent (MTA)">
<t>A Mail Transfer Agent (MTA) relays mail for one
application-level "hop". It is like a packet-switch or IP
router in that its job is to make routing assessments and to
move the message closer to the Recipient(s). Relaying is
performed by a sequence of MTAs, until the message reaches a
destination MDA. Hence an MTA implements both client and
server MTA functionality. It does not make changes to
addresses in the envelope or reformulate the editorial
content. Hence a change in data form, such as to the MIME
Content-Transfer-Encoding, is within the purview of an MTA,
whereas removal or replacement of body content is not. Also it
can add trace information. Of course email objects are
typically much larger than the payload of a packet or
datagram, and the end-to-end latencies are typically much
higher. </t>
<t>Internet Mail primarily uses SMTP <xref target="RFC2821" />,
<xref target="RFC0821" /> to effect point-to-point
transfers between peer MTAs. Other transfer mechanisms include
Batch SMTP <xref target="RFC2442" /> and ODMR <xref
target="RFC2645" />. As with most network layer mechanisms,
Internet Mail's SMTP supports a basic level of reliability, by
virtue of providing for retransmission after a temporary
transfer failure. Contrary to typical packet switches (and
Instant Messaging services) Internet Mail MTAs typically store
messages in a manner that allows recovery across service
interruptions, such as host system shutdown. However the
degree of such robustness and persistence by an MTA can be
highly variable. </t>
<t>The primary "routing" mechanism for Internet Mail is the DNS
MX record <xref target="RFC1035" />, which specifies a host
through which the queried domain can be reached. This presumes
a public -- or at least a common -- backbone that permits any
attached host to connect to any other. </t>
<t>Identities relevant to the MTA include:</t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="RFC2821.HELO/.EHLO" />
<t hangText="RFC3461.ENVID" />
<t hangText="RFC2821.MailFrom" />
<t hangText="RFC2821.RcptTo" />
<t hangText="RFC2822.Received">Set by - Relay
Server</t>
</list>
</t>
</list>
</t>
</section>
<section title="Mail Delivery Agent (MDA)" anchor="mda">
<t>A Mail Delivery Agent (MDA) delivers email to the Recipient's
mailbox. It can provide distinctive, address-based
functionality, made possible by its detailed knowledge of the
properties of the destination address. This knowledge might
also be present elsewhere in the Recipient's ADMD, such as at
an organizational border (Boundary) Relay. However it is
required for the MDA, if only because the MDA must know where
to deliver the message. </t>
<t>As with an MSA, an MDA serves two roles, as depicted in <xref
target="Protocols" />. Formal transfer of responsibility,
called "delivery" is effected between the two components that
embody these roles. The MHS portion (hMDA) primarily functions
as a server SMTP engine. A common additional role is to
re-direct the message to an alternative address, as specified
by the recipient addressee's preferences. The job of the
recipient portion of the MDA (rMDA) is to perform any
delivery-actions are desired by the recipient. </t>
<t>Using Internet protocols, delivery can be effected by a
variety of standard protocols. When coupled with an internal
local mechanism, SMTP <xref target="RFC2821" /> and LMTP <xref
target="RFC2033" /> permit "push" delivery to the Recipient
system, at the initiative of the upstream email service. POP
<xref target="RFC1939" /> and IMAP <xref target="RFC3501"
/> are used for "pull" delivery at the initiative of the
Recipient system. POP and IMAP can also be used for repeated
access to messages on a remote MS. </t>
<t>Identities relevant to the MDA include:</t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="RFC2821.Return-Path: ">Set by - Author
Source or Mediator Source</t>
<t>The MDA records the RFC2821.MailFrom address into
the RFC2822.Return-Path field. </t>
<t hangText="RFC2822.Received: ">Set by - MDA server</t>
<t>An MDA can record a Received header field to
indicate trace information, including source host
and receiving host domain names and/or IP
Addresses. </t>
</list>
</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="Mediators" title="Mediators">
<t>Basic email transfer from an Author to the specified Recipients is
accomplished by using an asynchronous, store-and-forward
communication infrastructure, in a sequence of independent
transmissions through some number of MTAs. A very different task is
a User-level sequence of postings and deliveries, through Mediators.
A Mediator forwards a message, through a re-posting process. The
Mediator does share some functionality with basic MTA relaying, but
it enjoys a degree of freedom with both addressing and content that
is not available to MTAs. </t>
<t><list>
<t>
<list style="hanging">
<t hangText="RFC2821.HELO/.EHLO: ">Set by - Mediator
Source</t>
<t hangText="RFC3461.ENVID">Set by - Author Source or
Mediator Source</t>
<t hangText="RFC2821.MailFrom: ">Set by - Author Source or
Mediator Source</t>
<t hangText="RFC2821.RcptTo: ">Set by - Mediator Author</t>
<t hangText="RFC2821.Received: ">Set by - Mediator
Dest</t>
</list>
</t>
</list> The salient aspect of a Mediator, that distinguishes it from
any other MUA creating an entirely new message, is that a Mediator
preserves the integrity and tone of the original message, including
the essential aspects of its origination information. The Mediator
might also add commentary. </t>
<t>Examples of MUA message creation NOT performed by Mediators include
--</t>
<t>
<list>
<t> New message that forwards an existing message: </t>
<t>
<list>
<t>This action rather curiously provides a basic template
for a class of Mediators. However for its typical
occurrence it is not itself an example of a Mediator.
The new message is viewed as being from the Actor doing
the forwarding, rather than being from the original
Author. </t>
<t>A new message encapsulates the original message and is
seen as strictly "from" the Mediator. The Mediator might
add commentary and certainly has the opportunity to
modify the original message content. The forwarded
message is therefore independent of the original message
exchange and creates a new message dialogue. However the
final Recipient sees the contained message as from the
original Author. </t>
</list>
</t>
<t> Reply: </t>
<t>
<list>
<t>When a Recipient formulates a response back to the
original message's author, the new message is not
typically viewed as being a "forwarding" of the
original. Its focus is the new content, although it
might contain all or part of the material in the
original message. Therefore the earlier material is
merely contextual and secondary. </t>
</list>
</t>
<t> Annotation: </t>
<t>
<list>
<t>The integrity of the original message is usually
preserved, but one or more comments about the message
are added in a manner that distinguishes commentary from
original text. The tone of the new message is that it is
primarily commentary from a new Author, similar to a
Reply. </t>
</list>
</t>
</list>
</t>
<t>The remainder of this section describes common examples of
Mediators. </t>
<section title="Aliasing">
<t>Aliasing is a simple re-addressing facility that is available in
most MDA implementations. It is performed just before placing a
message into the specified Recipient's mailbox. Instead the
message is submitted back to the transfer service, for delivery
to one or more alternate addresses. Although typically
implemented as part of an MDA, this facility is strictly a
Recipient user function. It resubmits the message, replacing the
envelope address, on behalf of the mailbox address that was
listed in the envelope. </t>
<t>What is most distinctive about this forwarding mechanism is how
closely it compares to normal MTA store-and-forward Relaying. Its
only interesting difference is that it changes the RFC2821.RcptTo
value. Having the change be this small makes it easy to view
aliasing as a part of the lower-level mail relaying activity.
However the small change has a large semantic impact: The
designated recipient has chosen a new recipient. Hence that
original recipient SHOULD become responsible for any handling
issues. This change would be reflected by replacing the message's
RFC2821.MailFrom address to be one within the scope of the ADMD
doing the aliasing. </t>
<t>An MDA that is re-posting a message to an alias typically changes
only envelope information: </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="RFC2822.To/.CC/.BCC: ">Set by - Author</t>
<t>These retain their original addresses. </t>
<t hangText="RFC2821.RcptTo: ">Set by - Mediator Author</t>
<t>This field contains an alias address. </t>
<t hangText="RFC2821.MailFrom: ">Set by - Author Source
or Mediator Source</t>
<t>The Actor responsible for submission to an alias
address will often retain the original address to
receive handling Returns. The benefit of retaining
the original MailFrom value is to ensure that the
origination-side Actor knows that there has been a
delivery problem. On the other hand, the
responsibility for the problem usually lies with the
Recipient, since the Alias mechanism is strictly
under the Recipient's control. </t>
<t hangText="RFC2821.Received">Set by - Mediator Dest</t>
<t>The Actor can record Received information, to
indicate the delivery to the original address and
submission to the alias address. The trace of
Received header fields can therefore include
everything from original posting through final
delivery to a final delivery. </t>
</list>
</t>
</list>
</t>
</section>
<section title="Re-Sending">
<t>Also called Re-Directing, Re-Sending differs from Forwarding by
virtue of having the Mediator "splice" a message's addressing
information, to connect the Author of the original message and
the Recipient of the new message. This permits them to have
direct exchange, using their normal MUA Reply functions. Hence
the new Recipient sees the message as being From: the original
Author, even if the Mediator adds commentary. </t>
<t>Identities specified in a resent message include </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="RFC2822.From: ">Set by - original Author</t>
<t>Names and email addresses for the original author(s)
of the message content are retained. The free-form
(display-name) portion of the address might be
modified to provide informal reference to the Actor
responsible for the redirection. </t>
<t hangText="RFC2822.Reply-To: ">Set by - original
Author</t>
<t>If this field is present in the original message, it
is retained in the Resent message. </t>
<t hangText="RFC2822.Sender: ">Set by - Author Source
or Mediator Source. </t>
<t hangText="RFC2822.To/.CC/.BCC: ">Set by - original
Author</t>
<t>These specify the original message Recipients. </t>
<t hangText="RFC2822.Resent-From: ">Set by - Mediator
Author</t>
<t>The address of the original Recipient who is
redirecting the message. Otherwise the same rules
apply for the Resent-From: field as for an original
RFC2822.From field.</t>
<t hangText="RFC2822.Resent-Sender: ">Set by - Mediator
Source</t>
<t>The address of the Actor responsible for
re-submitting the message. As with RFC2822.Sender,
this field is often omitted when it would merely
contain the same address as RFC2822.Resent-From. </t>
<t hangText="RFC2822.Resent-To/-CC/-BCC: ">Set by:
Mediator Author</t>
<t>The addresses of the new Recipients who will now be
able to reply to the original author. </t>
<t hangText="RFC2821.MailFrom: ">Set by - Mediator
Source</t>
<t>The Actor responsible for re-submission
(RFC2822.Resent-Sender) is also responsible for
specifying the new MailFrom address. </t>
<t hangText="RFC2821.RcptTo: ">Set by - Mediator Author</t>
<t>This will contain the address of a new Recipient.</t>
<t hangText="RFC2822.Received: ">Set by - Mediator Dest</t>
<t>When resending a message the submission agent can
record a Received header field, to indicate the
transition from original posting to resubmission.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Mailing Lists">
<t>Mailing lists have explicit email addresses and they re-post
messages to a list of subscribed members. The Mailing List Actor
performs a task that can be viewed as an elaboration of the
Re-Director role. In addition to sending the new message to a
potentially large number of new Recipients, the Mediator can
modify content, such as deleting attachments, converting the
format, and adding list-specific comments. In
addition,<!-- grammar; 'formatting' doesn't parallel 'deleting' and 'adding'; change 'formatting conversion' to 'converting the format' -->
archiving list messages is common. Still the message retains
characteristics of being "from" the original Author. </t>
<t>Identities relevant to a mailing list processor, when submitting
a message, include: </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="RFC2919.List-Id: ">Set by - Mediator
Author</t>
<t hangText="RFC2369.List-*: ">Set by - Mediator Author</t>
<t hangText="RFC2822.From: ">Set by - original Author</t>
<t>Names and email addresses for the original author(s)
of the message content are specified -- or, rather,
retained. </t>
<t hangText="RFC2822.Reply-To: ">Set by - original
Author or Mediator Author</t>
<t hangText="RFC2822.Sender: ">Set by - Author Source
or Mediator Source</t>
<t>This will usually specify the address of the Actor
responsible for mailing list operations. However some
mailing lists operate in a manner very similar to a
simple MTA Relay, so that they preserve as much of
the original handling information as possible,
including the original RFC2822.Sender field. </t>
<t hangText="RFC2822.To/.CC">Set by - original Author</t>
<t>These usually contain the original list of Recipient
addresses. </t>
<t hangText="RFC2821.MailFrom">Set by - Author Source or
Mediator Source</t>
<t>This can contain the original address to be notified
of transmission issues, or the mailing list Actor can
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-related Returns. </t>
<t hangText="RFC2821.RcptTo">Set by - Mediator Author</t>
<t>This contains the address of a mailing list member. </t>
<t hangText="RFC2821.Received">Set by - Mediator Dest</t>
<t>A Mailing List Actor can record a Received header
field, to indicate the transition from original
posting to mailing list forwarding. The Actor can
choose to have the message retain the original set of
Received header fields or can choose to remove them.
In the latter case it can ensure that
the<!-- how? --> original Received header fields are
otherwise available, to ensure later accountability
and diagnostic access to them. </t>
</list>
</t>
</list>
</t>
</section>
<section title="Gateways">
<t>A Gateway performs the basic routing and transfer work of message
relaying, but it also may make any content, structure, address,
or attribute modifications needed to send the message into a
messaging environment that operates according to different
standards or potentially incompatible policies. When a Gateway
connects two differing messaging services, its role is easy to
identify and understand. When it connects environments that have
technical similarity, but can have significant administrative
differences, it is easy to think that a Gateway is merely an MTA. </t>
<t>The critical distinction between an MTA and a Gateway is that the
latter can make substantive changes to a message, in order to map
between the standards of two, different messaging services. In
virtually all cases, this mapping process results in some degree
of semantic loss. The challenge of Gateway design is to minimize
this loss. </t>
<t>A Gateway can set any identity field available to a regular MUA.
Identities typically relevant to Gateways include: </t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="RFC2822.From: ">Set by - original Author</t>
<t>Names and email addresses for the original author(s)
of the message content are retained. As for all
original addressing information in the message, the
Gateway can translate addresses in whatever way will
allow them continue to be useful in the target
environment. </t>
<t hangText="RFC2822.Reply-To: ">Set by - original
Author</t>
<t>The Gateway SHOULD retain this information, if it is
originally present. The ability to perform a
successful reply by a Gatewayed Recipient is a
typical test of Gateway functionality. </t>
<t hangText="RFC2822.Sender: ">Set by - Author Source
or Mediator Source</t>
<t>This can retain the original value or can be set to a
new address. </t>
<t hangText="RFC2822.To/.CC/.BCC">Set by - original
Recipient</t>
<t>These usually retain their original addresses. </t>
<t hangText="RFC2821.MailFrom">Set by - Author Source or
Mediator Source</t>
<t>The Actor responsible for gatewaying the message can
choose to specify a new address to receive handling
notices. </t>
<t hangText="RFC2822.Received">Set by - Mediator Dest</t>
<t>The Gateway can record a Received header field, to
indicate the transition from the original posting
environment
to<!-- grammar tweak; reads better changing 'original environment' to 'the original posting environment' -->
the new messaging environment. </t>
</list>
</t>
</list>
</t>
</section>
<section title="Boundary Filter">
<t>Organizations often enforce security boundaries by subjecting
messages to analysis, for conformance with the organization's
safety policies. An example is detection of content classed as
spam or a virus. A Filter might alter the content, to render it
safe, such as by removing content deemed unacceptable. Typically
these actions will result in the addition of content that records
the actions. </t>
</section>
</section>
<section title="Considerations">
<section title="Security Considerations">
<t>This document does not specify any new Internet Mail
functionality. Consequently it is not intended to introduce any
security considerations. </t>
<t>However its discussion of the roles and responsibilities for
different mail service modules, and the information they create,
highlights the considerable degree to which security issues are
present when implementing any component of the Internet Mail
service. In addition, email transfer protocols can operate over
authenticated and/or encrypted links, and message content or
authorship can be authenticated or encrypted. </t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
</section>
</middle>
<back>
<references title="Normative">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to
Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave. </street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t> In many standards track documents several words are used
to signify the requirements in the specification. These
words are often capitalized. This document defines these
words as they should be interpreted in IETF documents.
Authors who follow these guidelines should incorporate this
phrase near the beginning of their document: </t>
<t>
<list>
<t> The key words "MUST",
"MUST NOT",
"REQUIRED",
"SHALL", "SHALL
NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED",
"MAY", and
"OPTIONAL" in this document are to
be interpreted as described in RFC 2119. </t>
</list>
</t>
<t> Note that the force of these words is modified by the
requirement level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="14486"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5661"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC1034">
<front>
<title abbrev="Domain Concepts and Facilities">Domain names -
concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P."
surname="Mockapetris">
<organization>Information Sciences Institute
(ISI)</organization>
</author>
<date day="1" month="November" year="1987" />
</front>
<seriesInfo name="STD" value="13" />
<seriesInfo name="RFC" value="1034" />
</reference>
<reference anchor="RFC1939">
<front>
<title abbrev="POP3">Post Office Protocol - Version 3</title>
<author fullname="John G. Myers" initials="J.G." surname="Myers">
<organization>Carnegie-Mellon University</organization>
<address>
<postal>
<street>5000 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>
<email>jgm+@cmu.edu</email>
</address>
</author>
<author fullname="Marshall T. Rose" initials="M.T."
surname="Rose">
<organization>Dover Beach Consulting, Inc. </organization>
<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>
<date month="May" year="1996" />
</front>
<seriesInfo name="STD" value="53" />
<seriesInfo name="RFC" value="1939" />
</reference>
<reference anchor="RFC1035">
<front>
<title abbrev="Domain Implementation and Specification">Domain
names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P."
surname="Mockapetris">
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>
<phone>+1 213 822 1511</phone>
</address>
</author>
<date day="1" month="November" year="1987" />
</front>
<seriesInfo name="STD" value="13" />
<seriesInfo name="RFC" value="1035" />
</reference>
<reference anchor="RFC2045">
<front>
<title abbrev="Internet Message Bodies">Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Message
Bodies</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc. </organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>
<author fullname="Nathaniel S. Borenstein" initials="N.S."
surname="Borenstein">
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
</author>
<date month="November" year="1996" />
<abstract>
<t>STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message
header fields, and leaves the message content, or message
body, as flat US-ASCII text. This set of documents,
collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to
allow for</t>
<t>(1) textual message bodies in character sets other than
US-ASCII,</t>
<t>(2) an extensible set of different formats for non-textual
message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets other than
US-ASCII. </t>
<t>These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822. </t>
<t>This initial document specifies the various header fields
used to describe the structure of MIME messages. The second
document, RFC 2046, defines the general structure of the
MIME media typing system and defines an initial set of
media types. The third document, RFC 2047, describes
extensions to RFC 822 to allow non-US-ASCII text data in
Internet Mail header fields. The fourth document, RFC 2048,
specifies various IANA registration procedures for
MIME-related facilities. The fifth and final document, RFC
2049, describes MIME conformance criteria as well as
providing some illustrative examples of MIME message
formats, acknowledgements, and the bibliography. </t>
<t>These documents are revisions of RFCs 1521, 1522, and 1590,
which themselves were revisions of RFCs 1341 and 1342. An
appendix in RFC 2049 describes differences and changes from
previous versions. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="2045" />
</reference>
<reference anchor="RFC2046">
<front>
<title abbrev="Media Types">Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc. </organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>
<author fullname="Nathaniel S. Borenstein" initials="N."
surname="Borenstein">
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
</author>
<date month="November" year="1996" />
<abstract>
<t>STD 11, RFC 822 defines a message representation protocol
specifying considerable detail about US-ASCII message
header fields, but which leaves the message content, or
message body, as flat US-ASCII text. This set of documents,
collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to
allow for</t>
<t>(1) textual message bodies in character sets other than
US-ASCII,</t>
<t>(2) an extensible set of different formats for non-textual
message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets other than
US-ASCII. </t>
<t>These documents are based on earlier work documented in RFC
934, STD 11 and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822. </t>
<t>The initial document in this set, RFC 2045, specifies the
various header fields used to describe the structure of
MIME messages. This second document defines the general
structure of the MIME media typing system and defines an
initial set of media types. The third document, RFC 2047,
describes extensions to RFC 822 to allow non-US-ASCII text
data in Internet Mail header fields. The fourth document,
RFC 2048, specifies various IANA registration procedures
for MIME-related facilities. The fifth and final document,
RFC 2049, describes MIME conformance criteria as well as
providing some illustrative examples of MIME message
formats, acknowledgements, and the bibliography. </t>
<t>These documents are revisions of RFCs 1521 and 1522, which
themselves were revisions of RFCs 1341 and 1342. An
appendix in RFC 2049 describes differences and changes from
previous versions. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="2046" />
</reference>
<reference anchor="RFC2047">
<front>
<title abbrev="Message Header Extensions">MIME (Multipurpose
Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text</title>
<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee</organization>
<address>
<postal>
<street>107 Ayres Hall</street>
<street>Knoxville TN 37996-1301</street>
</postal>
<email>moore@cs.utk.edu</email>
</address>
</author>
<date month="November" year="1996" />
<area>Applications</area>
<keyword>American Standard Code for Information Interchange</keyword>
<keyword>mail</keyword>
<keyword>multipurpose Internet Mail extensions</keyword>
<abstract>
<t>STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message
header fields, and leaves the message content, or message
body, as flat US-ASCII text. This set of documents,
collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to
allow for</t>
<t>
<list>
<t>(1) textual message bodies in character sets other
than US-ASCII,</t>
<t>(2) an extensible set of different formats for
non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets
other than US-ASCII. </t>
</list>
</t>
<t>These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822. </t>
<t>This particular document is the third document in the
series. It describes extensions to RFC 822 to allow
non-US-ASCII text data in Internet Mail header fields.
Other documents in this series include:</t>
<t>
<list>
<t>+ RFC 2045, which specifies the various header fields
used to describe the structure of MIME messages. </t>
<t>+ RFC 2046, which defines the general structure of
the MIME media typing system and defines an initial
set of media types,</t>
<t>+ RFC 2048, which specifies various IANA registration
procedures for MIME-related facilities, and</t>
<t>+ RFC 2049, which describes MIME conformance criteria
and provides some illustrative examples of MIME
message formats, acknowledgements, and the
bibliography. </t>
</list>
</t>
<t>These documents are revisions of RFCs 1521, 1522, and 1590,
which themselves were revisions of RFCs 1341 and 1342. An
appendix in RFC 2049 describes differences and changes from
previous versions. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="2047" />
<format octets="52141"
target="http://xml.resource.org/public/rfc/html/rfc2047.html"
type="HTML" />
<format octets="39194"
target="http://xml.resource.org/public/rfc/xml/rfc2047.xml"
type="XML" />
</reference>
<reference anchor="RFC4289">
<front>
<title abbrev="MIME Registration">Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc. </organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>MCI</organization>
<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Reston</street>
<street>VA 22091</street>
</postal>
<phone>+1 703 715-7361</phone>
<facsimile>+1 703 715-7436</facsimile>
<email>klensin@mci.net</email>
</address>
</author>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
<country>USA</country>
</postal>
<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>
<date month="December" year="2005" />
<area>Applications</area>
<keyword>mail</keyword>
<keyword>media type</keyword>
<keyword>multipurpose Internet Mail extensions</keyword>
<abstract>
<t>STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message
header fields, and leaves the message content, or message
body, as flat US-ASCII text. This set of documents,
collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to
allow for</t>
<t>
<list>
<t>(1) textual message bodies in character sets other
than US-ASCII,</t>
<t>(2) an extensible set of different formats for
non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets
other than US-ASCII. </t>
</list>
</t>
<t>These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822. This fourth document, RFC 2048, specifies
various IANA registration procedures for the following MIME
facilities:</t>
<t>
<list>
<t>(1) media types,</t>
<t>(2) external body access types,</t>
<t>(3) content-transfer-encodings. </t>
</list>
</t>
<t>Registration of character sets for use in MIME is covered
here and is no longer addressed by this document. </t>
<t>These documents are revisions of RFCs 1521 and 1522, which
themselves were revisions of RFCs 1341 and 1342. An
appendix in RFC 2049 describes differences and changes from
previous versions. </t>
</abstract>
</front>
<seriesInfo name="BCP" value="13" />
<seriesInfo name="RFC" value="4289" />
<format octets="54732"
target="http://xml.resource.org/public/rfc/html/rfc4289.html"
type="HTML" />
<format octets="43342"
target="http://xml.resource.org/public/rfc/xml/rfc4289.xml"
type="XML" />
</reference>
<reference anchor="RFC4288">
<front>
<title abbrev="Media Registration">Media Type Specifications and
Registration Procedures</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc. </organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>MCI</organization>
<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Reston</street>
<street>VA 22091</street>
</postal>
<phone>+1 703 715-7361</phone>
<facsimile>+1 703 715-7436</facsimile>
<email>klensin@mci.net</email>
</address>
</author>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
<country>USA</country>
</postal>
<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>
<date month="December" year="2005" />
<area>Applications</area>
<keyword>mail</keyword>
<keyword>media type</keyword>
<keyword>multipurpose Internet Mail extensions</keyword>
<abstract>
<t>STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message
header fields, and leaves the message content, or message
body, as flat US-ASCII text. This set of documents,
collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to
allow for</t>
<t>
<list>
<t>(1) textual message bodies in character sets other
than US-ASCII,</t>
<t>(2) an extensible set of different formats for
non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets
other than US-ASCII. </t>
</list>
</t>
<t>These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822. This fourth document, RFC 2048, specifies
various IANA registration procedures for the following MIME
facilities:</t>
<t>
<list>
<t>(1) media types,</t>
<t>(2) external body access types,</t>
<t>(3) content-transfer-encodings. </t>
</list>
</t>
<t>Registration of character sets for use in MIME is covered
here and is no longer addressed by this document. </t>
<t>These documents are revisions of RFCs 1521 and 1522, which
themselves were revisions of RFCs 1341 and 1342. An
appendix in RFC 2049 describes differences and changes from
previous versions. </t>
</abstract>
</front>
<seriesInfo name="BCP" value="13" />
<seriesInfo name="RFC" value="4288" />
<format octets="54732"
target="http://xml.resource.org/public/rfc/html/rfc4288.html"
type="HTML" />
<format octets="43342"
target="http://xml.resource.org/public/rfc/xml/rfc4288.xml"
type="XML" />
</reference>
<reference anchor="RFC2049">
<front>
<title abbrev="MIME Conformance">Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc. </organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>
<author fullname="Nathaniel S. Borenstein" initials="N.S."
surname="Borenstein">
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<street>Morristown</street>
<street>NJ 07960</street>
<country>USA</country>
</postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
</author>
<date month="November" year="1996" />
<area>Applications</area>
<keyword>mail</keyword>
<keyword>multipurpose Internet Mail extensions</keyword>
<abstract>
<t>STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message
header fields, and leaves the message content, or message
body, as flat US-ASCII text. This set of documents,
collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to
allow for</t>
<t>
<list>
<t>(1) textual message bodies in character sets other
than US-ASCII,</t>
<t>(2) an extensible set of different formats for
non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets
other than US-ASCII. </t>
</list>
</t>
<t>These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822. </t>
<t>The initial document in this set, RFC 2045, specifies the
various header fields used to describe the structure of
MIME messages. The second document defines the general
structure of the MIME media typing system and defines an
initial set of media types. The third document, RFC 2047,
describes extensions to RFC 822 to allow non-US- ASCII text
data in Internet Mail header fields. The fourth document,
RFC 2048, specifies various IANA registration procedures
for MIME- related facilities. This fifth and final document
describes MIME conformance criteria as well as providing
some illustrative examples of MIME message formats,
acknowledgements, and the bibliography. </t>
<t>These documents are revisions of RFCs 1521, 1522, and 1590,
which themselves were revisions of RFCs 1341 and 1342.
Appendix B of this document describes differences and
changes from previous versions. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="2049" />
<format octets="55000"
target="http://xml.resource.org/public/rfc/html/rfc2049.html"
type="HTML" />
<format octets="41896"
target="http://xml.resource.org/public/rfc/xml/rfc2049.xml"
type="XML" />
</reference>
<reference anchor="RFC2181">
<front>
<title abbrev="DNS Clarifications">Clarifications to the DNS
Specification</title>
<author fullname="Robert Elz" initials="R." surname="Elz">
<organization>Computer Science</organization>
<address>
<postal>
<street>Parkville</street>
<street>Victoria</street>
<street>3052</street>
<street>Australia. </street>
</postal>
<email>kre@munnari.OZ.ADMD</email>
<uri>e</uri>
</address>
</author>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>RGnet, Inc. </organization>
<address>
<postal>
<street>5147 Crystal Springs Drive</street>
<street>Bainbridge Island</street>
<street>Washington</street>
<street>98110</street>
<street>United States. </street>
<country>NE</country>
</postal>
<email>randy@psg.com</email>
</address>
</author>
<date month="July" year="1997" />
<area>Applications</area>
<keyword>DNS</keyword>
<keyword>domain name system</keyword>
</front>
<seriesInfo name="RFC" value="2181" />
<format octets="54106"
target="http://xml.resource.org/public/rfc/html/rfc2181.html"
type="HTML" />
<format octets="38795"
target="http://xml.resource.org/public/rfc/xml/rfc2181.xml"
type="XML" />
</reference>
<reference anchor="RFC3798">
<front>
<title>Message Disposition Notification</title>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization />
</author>
<author fullname="G. Vaudreuil" initials="G." surname="Vaudreuil">
<organization />
</author>
<date month="May" year="2004" />
</front>
<seriesInfo name="RFC" value="3798" />
<format octets="64049"
target="ftp://ftp.isi.edu/in-notes/rfc3798.txt" type="TXT" />
</reference>
<reference anchor="RFC3192">
<front>
<title abbrev="Minimal FAX address format">Minimal FAX address
format in Internet Mail</title>
<author fullname="C. Allocchio" initials="C." surname="Allocchio">
<organization>GARR-Italy</organization>
<address>
<postal>
<street>Sincrotrone Trieste</street>
<street>SS 14 Km 163.5 Basovizza</street>
<city>Trieste</city>
<code>I 34012</code>
<country>Italy</country>
</postal>
<phone>+39 40 3758523</phone>
<facsimile>+39 40 3758565</facsimile>
<email>Claudio.Allocchio@elettra.trieste.it</email>
</address>
</author>
<date month="October" year="2001" />
<area>Applications</area>
<keyword>facsimile</keyword>
<keyword>mail</keyword>
<note title="IESG Note">
<t>This memo describes a simple method of encoding PSTN
addresses of facsimile devices in the local-part of
Internet email addresses. </t>
<t>As with all Internet Mail addresses, the left-hand-side
(local- part) of an address generated according to this
specification, is not to be interpreted except by the MTA
that is named on the right-hand-side (domain). </t>
</note>
</front>
<seriesInfo name="RFC" value="2304" />
<format octets="22309"
target="http://xml.resource.org/public/rfc/html/RFC3192.html"
type="HTML" />
<format octets="14696"
target="http://xml.resource.org/public/rfc/xml/RFC3192.xml"
type="XML" />
</reference>
<reference anchor="RFC4409">
<front>
<title>Message Submission for Mail</title>
<author fullname="Randall Gellens" initials="R."
surname="Gellens">
<organization>QUALCOMM Incorporated</organization>
<address>
<postal>
<street>6455 Lusk Blvd. </street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>USA</country>
</postal>
<phone>+1 619 651 5115</phone>
<facsimile>+1 619 651 5334</facsimile>
<email>Randy@Qualcomm.Com</email>
</address>
</author>
<author fullname="John C. Klensin" initials="J.C."
surname="Klensin">
<organization>MCI Telecommunications</organization>
<address>
<postal>
<street>800 Boylston St, 7th floor</street>
<city>Boston</city>
<region>MA</region>
<code>02199</code>
<country>USA</country>
</postal>
<phone>+1 617 960 1011</phone>
<email>klensin@mci.net</email>
</address>
</author>
<date month="April" year="2006" />
<area>Applications</area>
<keyword>SMTP</keyword>
</front>
<seriesInfo name="RFC" value="4409" />
<format octets="47918"
target="http://xml.resource.org/public/rfc/html/rfc4409.html"
type="HTML" />
<format octets="50997"
target="http://xml.resource.org/public/rfc/xml/rfc4409.xml"
type="XML" />
</reference>
<reference anchor="RFC2821">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization />
</author>
<date month="April" year="2001" />
</front>
<seriesInfo name="RFC" value="2821" />
<format octets="192504"
target="ftp://ftp.isi.edu/in-notes/rfc2821.txt" type="TXT" />
</reference>
<reference anchor="RFC2822">
<front>
<title>Internet Message Format</title>
<author fullname="P. Resnick" initials="P." surname="Resnick">
<organization />
</author>
<date month="April" year="2001" />
</front>
<seriesInfo name="RFC" value="2822" />
<format octets="110695"
target="ftp://ftp.isi.edu/in-notes/rfc2822.txt" type="TXT" />
</reference>
<reference anchor="RFC3501">
<front>
<title>Internet Message Access Protocol - Version 4rev1</title>
<author fullname="M. Crispin" initials="M." surname="Crispin">
<organization />
</author>
<date month="March" year="2003" />
</front>
<seriesInfo name="RFC" value="3501" />
<format octets="227640"
target="ftp://ftp.isi.edu/in-notes/rfc3501.txt" type="TXT" />
</reference>
<reference anchor="RFC2645">
<front>
<title>On-Demand Mail Relay (ODMR) SMTP with Dynamic IP Addresses</title>
<author fullname="R. Gellens">
<organization />
</author>
<date month="August" year="1999" />
</front>
<seriesInfo name="RFC" value="2645" />
</reference>
<reference anchor="RFC3864">
<front>
<title>Registration Procedures for Message Header Fields</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization>Nine by Nine</organization>
</author>
<author fullname="M. Nottingham" initials="M."
surname="Nottingham">
<organization />
</author>
<author fullname="J. Mogul" initials="J." surname="Mogul">
<organization>HP Labs</organization>
</author>
<date month="September" year="2004" />
</front>
<seriesInfo name="RFC" value="3864" />
</reference>
<reference anchor="RFC2369">
<front>
<title abbrev="URLs as Meta-Syntax">The Use of URLs as
Meta-Syntax for Core Mail List Commands and their Transport
through Message Header Fields</title>
<author fullname="Grant Neufeld" initials="G." surname="Neufeld">
<organization>Calgary, Alberta</organization>
<address>
<email>grant@acm.org</email>
<uri>http://www.nisto.com/</uri>
</address>
</author>
<author fullname="Joshua D. Baer" initials="J.D." surname="Baer">
<organization>Box 273</organization>
<address>
<postal>
<street>4902 Forbes Avenue</street>
<street>Pittsburgh</street>
<street>PA 15213-3799</street>
<country>USA</country>
</postal>
<email>josh@skyweyr.com</email>
</address>
</author>
<date month="July" year="1998" />
<area>Applications</area>
<keyword>mail</keyword>
<keyword>uniform resource locater</keyword>
<keyword>URL</keyword>
<abstract>
<t>The mailing list command specification header fields are a
set of structured fields to be added to email messages sent
by email distribution lists. Each field typically contains
a URL (usually mailto ) locating the relevant information
or performing the command directly. The three core header
fields described in this document are List-Help,
List-Subscribe, and List-Unsubscribe. </t>
<t>There are three other header fields described here which,
although not as widely applicable, will have utility for a
sufficient number of mailing lists to justify their
formalization here. These are List-Post, List-Owner and
List-Archive. </t>
<t>By including these header fields, list servers can make it
possible for mail clients to provide automated tools for
users to perform list functions. This could take the form
of a menu item, push button, or other user interface
element. The intent is to simplify the user experience,
providing a common interface to the often cryptic and
varied mailing list manager commands. </t>
<t>The key words "MUST", "MUST
NOT", "REQUIRED",
"SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="2369" />
<format octets="45836"
target="http://xml.resource.org/public/rfc/html/rfc2369.html"
type="HTML" />
<format octets="31893"
target="http://xml.resource.org/public/rfc/xml/rfc2369.xml"
type="XML" />
</reference>
<reference anchor="RFC2919">
<front>
<title>List-Id: A Structured Field and Namespace for the
Identification of Mailing Lists</title>
<author fullname="R. Chandhok" initials="R." surname="Chandhok">
<organization />
</author>
<author fullname="G. Wenger" initials="G." surname="Wenger">
<organization />
</author>
<date month="March" year="2001" />
</front>
<seriesInfo name="RFC" value="2919" />
<format octets="18480"
target="ftp://ftp.isi.edu/in-notes/rfc2919.txt" type="TXT" />
</reference>
<reference anchor="RFC3028">
<front>
<title>Sieve: A Mail Filtering Language</title>
<author fullname="T. Showalter" initials="T." surname="Showalter">
<organization />
</author>
<date month="January" year="2001" />
</front>
<seriesInfo name="RFC" value="3028" />
<format octets="73582"
target="ftp://ftp.isi.edu/in-notes/rfc3028.txt" type="TXT" />
</reference>
<reference anchor="RFC3297">
<front>
<title>Content Negotiation for Messaging Services based on Email</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization>Clearswift Corporation</organization>
</author>
<author fullname="R. Iwazaki" initials="R." surname="Iwazaki">
<organization>Toshiba TEC</organization>
</author>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
</author>
<date month="July" year="2002" />
</front>
<seriesInfo name="RFC" value="3297" />
</reference>
<reference anchor="RFC3458">
<front>
<title>Message Context for Internet Mail</title>
<author fullname="E. Burger" initials="E." surname="Burger">
<organization>SnowShore Networks</organization>
</author>
<author fullname="E. Candell" initials="E." surname="Candell">
<organization>Comverse</organization>
</author>
<author fullname="C. Eliot" initials="C." surname="Eliot">
<organization>Microsoft Corporation</organization>
</author>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization>Nine by Nine</organization>
</author>
<date month="January" year="2003" />
</front>
<seriesInfo name="RFC" value="3458" />
</reference>
<reference anchor="RFC3461">
<front>
<title>Simple Mail Transfer Protocol (SMTP) Service Extension for
Delivery Status Notifications (DSNs)</title>
<author fullname="K. Moore" initials="K." surname="Moore">
<organization />
</author>
<date month="January" year="2003" />
</front>
<seriesInfo name="RFC" value="3461" />
<format octets="76076"
target="ftp://ftp.isi.edu/in-notes/rfc3461.txt" type="TXT" />
</reference>
<reference anchor="RFC4021">
<front>
<title>Registration of Mail and MIME Header Fields</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization>University of Oxford</organization>
</author>
<author fullname="J. Palme" initials="J." surname="Palme">
<organization>Stockholm University/KT</organization>
</author>
<date month="March" year="2005" />
</front>
<seriesInfo name="RFC" value="4021" />
</reference>
<reference anchor="RFC4550">
<front>
<title>Internet Email to Support Diverse Service Environments
(Lemonade) Profile</title>
<author initials="S." surname="Maes">
<organization>Oracle</organization>
</author>
<author fullname="Melnikov" initials="S.">
<organization />
</author>
<author>
<organization>Isode Ltd. </organization>
</author>
<date month="June" year="2006" />
</front>
</reference>
<reference anchor="RFC0791">
<front>
<title>Internet Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>USC-ISI</organization>
</author>
<date month="1981" year="September" />
</front>
</reference>
</references>
<references title="Informative">
<reference anchor="Tussle">
<front>
<title>Tussle in Cyberspace: Defining Tomorrow’s Internet</title>
<author fullname="David D. Clark" initials="D" surname="Clark">
<organization>MIT Lab for Computer Science</organization>
<address>
<email>ddc@lcs.mit.edu</email>
</address>
</author>
<author fullname="John Wroclawski" initials="J"
surname="Wroclawski">
<organization>MIT Lab for Computer Science</organization>
<address>
<email>jtw@lcs.mit.edu</email>
</address>
</author>
<author fullname="Karen R. Sollins" initials="K"
surname="Sollins">
<organization />
<address>
<email>sollins@lcs.mit.edu</email>
</address>
</author>
<author fullname="Robert Braden" initials="R" surname="Braden">
<organization>USC Information Sciences Institute</organization>
<address>
<email>braden@isi.edu</email>
</address>
</author>
<date year="2002" />
<note title="">
<t />
</note>
</front>
<seriesInfo name="ACM" value="SIGCOMM" />
</reference>
<reference anchor="RFC0821">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="Jonathan B. Postel" initials="J.B."
surname="Postel">
<organization>University of Southern California
(USC)/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>
<phone>+1 213 822 1511</phone>
</address>
</author>
<date day="1" month="August" year="1982" />
</front>
<seriesInfo name="STD" value="10" />
<seriesInfo name="RFC" value="821" />
</reference>
<reference anchor="RFC0822">
<front>
<title abbrev="Standard for ARPA Internet Text Messages">Standard
for the format of ARPA Internet text messages</title>
<author fullname="David H. Crocker" initials="D.H."
surname="Crocker">
<organization>University of Delaware, Dept. of Electrical
Engineering</organization>
<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19711</code>
<country>US</country>
</postal>
<email>DCrocker@UDel-Relay</email>
</address>
</author>
<date day="13" month="August" year="1982" />
</front>
<seriesInfo name="STD" value="11" />
<seriesInfo name="RFC" value="822" />
</reference>
<reference anchor="RFC1767">
<front>
<title>MIME Encapsulation of EDI Objects</title>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<date month="March" year="1995" />
</front>
<seriesInfo name="RFC" value="1767" />
</reference>
<reference anchor="RFC2033">
<front>
<title abbrev="Local Mail">Local Mail Transfer Protocol</title>
<author fullname="John G. Myers" initials="J.G." surname="Myers">
<organization>Carnegie-Mellon University</organization>
<address>
<postal>
<street>5000 Forbes Ave. </street>
<street>Pittsburgh</street>
<street>15213-3890</street>
<country>PA</country>
</postal>
<email>jgm+@cmu.edu</email>
</address>
</author>
<date month="October" year="1996" />
<area>Applications</area>
<keyword>mail</keyword>
</front>
<seriesInfo name="RFC" value="2033" />
<format octets="27748"
target="http://xml.resource.org/public/rfc/html/rfc2033.html"
type="HTML" />
<format octets="17426"
target="http://xml.resource.org/public/rfc/xml/rfc2033.xml"
type="XML" />
</reference>
<reference anchor="RFC2442">
<front>
<title>The Batch SMTP Media Type</title>
<author fullname="N. Freed">
<organization />
</author>
<author fullname="D. Newman">
<organization />
</author>
<author fullname="J. Belissen">
<organization />
</author>
<author fullname="M. Hoy">
<organization />
</author>
<date month="November" year="1998" />
</front>
<seriesInfo name="RFC" value="2442" />
</reference>
<reference anchor="RFC3801">
<front>
<title
abbrev="Voice Profile for Internet Mail - version 2 (VPIMv2)" />
<author fullname="Gregory M. Vaudreuil" initials="G.M."
surname="Vaudreuil">
<organization>Lucent Technologies, Octel Messaging Division</organization>
<address>
<postal>
<street>17080 Dallas Parkway</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>USA</country>
</postal>
<phone>+1 972 733 2722</phone>
<email>GregV@Lucent.Com</email>
</address>
</author>
<author fullname="Glenn W. Parsons" initials="G.W."
surname="Parsons">
<organization>Northern Telecom</organization>
<address>
<postal>
<street>P.O. Box 3511</street>
<street>Station C</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1Y 4H7</code>
<country>Canada</country>
</postal>
<phone>+1 613 763 7582</phone>
<facsimile>+1 613 763 4461</facsimile>
<email>Glenn.Parsons@Nortel.ca</email>
</address>
</author>
<date month="June" year="2004" />
<area>Applications</area>
<keyword>audio</keyword>
<keyword>mail</keyword>
<abstract>
<t>A class of special-purpose computers has evolved to provide
voice messaging services. These machines generally
interface to a telephone switch and provide call answering
and voice messaging services. Traditionally, messages sent
to a non-local machine are transported using analog
networking protocols based on DTMF signaling and analog
voice playback. As the demand for networking increases,
there is a need for a standard high-quality digital
protocol to connect these machines. The following document
is a profile of the Internet standard MIME and ESMTP
protocols for use as a digital voice messaging networking
protocol. The profile is referred to as VPIM (Voice Profile
for Internet Mail) in this document. </t>
<t>This profile is based on earlier work in the Audio Message
Interchange Specification (AMIS) group that defined a voice
messaging protocol based on X.400 technology. This profile
is intended to satisfy the user requirements statement from
that earlier work with the industry standard ESMTP/MIME
mail protocol infrastructures already used within corporate
intranets. This second version of VPIM is based on
implementation experience and obsoletes RFC 1911 which
describes version 1 of the profile. </t>
</abstract>
<note title="Working Group Summary">
<t>This profile is not the product of an IETF working group,
though several have reviewed the document. It is instead
the product of the VPIM Work Group of the Electronic
Messaging Association (EMA). This work group, which has
representatives from most major voice mail vendors and
several email vendors, has held several interoperability
demonstrations between voice messaging vendors and is
currently promoting VPIM trials and deployment. </t>
</note>
</front>
<seriesInfo name="RFC" value="3801" />
<format octets="162050"
target="http://xml.resource.org/public/rfc/html/rfc3801.html"
type="HTML" />
<format octets="180600"
target="http://xml.resource.org/public/rfc/xml/rfc3801.xml"
type="XML" />
</reference>
<reference anchor="RFC3885">
<!-- added reference for message tracking -->
<front>
<title>SMTP Service Extension for Message Tracking</title>
<author fullname="E. Allman" initials="E." surname="Allman">
<organization />
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization />
</author>
<date month="September" year="2004" />
</front>
<seriesInfo name="RFC" value="3885" />
<format octets="17458"
target="http://xml.resource.org/public/rfc/xml/rfc3801.xml"
type="XML" />
</reference>
<reference anchor="RFC4142">
<front>
<title>Full-mode Fax Profile for Internet Mail: FFPIM</title>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization>Nine By Nine</organization>
</author>
<date month="December" year="2005" />
</front>
</reference>
<reference anchor="RFC5068">
<front>
<title>Email Submission Operations: Access and Accountability
Requirements</title>
<author fullname="Carl Hutzler" initials="C" surname="Hutzler">
<organization />
</author>
<author fullname="Dave Crocker" initials="D" surname="Crocker">
<organization />
</author>
<author fullname="Pete Resnick" initials="P" surname="Resnick">
<organization />
</author>
<author fullname="Robert Sanderson" initials="R"
surname="Sanderson">
<organization />
</author>
<author fullname="Eric Allman" initials="E" surname="Allman">
<organization />
</author>
<date month="Nov" year="2007" />
</front>
<seriesInfo name="RFC" value="5068" />
<seriesInfo name="BCP" value="134" />
</reference>
<reference anchor="RFC1733">
<front>
<title>Distributed Electronic Models in IMAP4</title>
<author fullname="M. Crispin" initials="M" surname="Crispin">
<organization>University of Washington</organization>
</author>
<date month="December" year="1994" />
</front>
</reference>
</references>
<section title="Acknowledgements">
<t>This work derives from a section in draft-hutzler-spamops <xref
target="RFC5068" />. Discussion of the Source actor role was
greatly clarified during discussions in the IETF's Marid working
group. </t>
<t>Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful
insight on the framework and details of the original drafts. </t>
<t>Later reviews and suggestions were provided by Eric Allman,
Nathaniel Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann,
Tony Finch, Ned Freed, Eric Hall, Tony Hansen, Willemien
Hoogendoorn, Brad Knowles, John Leslie, Bruce Valdis Kletnieks, Mark
E. Mallett, David MacQuigg, Alexey Melnikov, der Mouse, S.
Moonesamy, Chris Newman, Daryl Odnert, Rahmat M. Samik-Ibrahim,
Marshall Rose, Hector Santos, Jochen Topf, Greg Vaudreuil. </t>
<t>Diligent proof-reading was performed by Bruce Lilly. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:25:07 |