Internet Mail ArchitectureBrandenburg InternetWorking675 Spruce DriveSunnyvaleCA94086USA+1.408.246.8253dcrocker@bbiw.net
Applications
SMTPemail, e-mail, service, mime, rfc2822, rfc 2822, rfc822, rfc
822, rfc2821, rfc 2821, rfc821, rfc 821, rfc5321, rfc5322, rfc
5321, rfc 5322, architecture, mta, mua, msa, mda, admd, user,
originator, recipient, transfer, message transfer, deliver,
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,
administrative management domainOver its thirty-five year history, Internet Mail has changed
significantly in scale and complexity, as it has become a
global infrastructure service. These changes have been
evolutionary, rather than revolutionary, reflecting a strong
desire to preserve both its installed base and its usefulness.
To collaborate productively on this large and complex system,
all participants must work from a common view of it and use a
common language to describe its components and the
interactions among them. But the many differences in
perspective currently make it difficult to know exactly what
another participant means. To serve as the necessary common
frame of reference, this document describes the enhanced
Internet Mail architecture, reflecting the current
service.Over its thirty-five year history, Internet Mail has changed
significantly in scale and complexity, as it has become a
global infrastructure service. These changes have been
evolutionary, rather than revolutionary, reflecting a strong
desire to preserve both its installed base and its usefulness.
Today, Internet Mail is distinguished by many independent
operators, many different components for providing service to
users, as well as many different components that transfer
messages. The underlying technical standards for Internet Mail comprise a
rich array of functional capabilities. The specifications form
the core:Simple Mail Transfer Protocol (SMTP) , , moves a message
through the Internet.Internet Mail Format (IMF) , , , defines a message
object.Multipurpose Internet Mail Extensions (MIME) defines an enhancement
to the message object that permits using
multi-media attachments.Public collaboration on technical, operations, and policy
activities of email, including those that respond to the
challenges of email abuse, has brought a much wider range of
participants into the technical community. To collaborate
productively on this large and complex system, all
participants must work from a common view of it and use a
common language to describe its components and the
interactions among them. But the many differences in
perspective currently make it difficult to know exactly what
another participant means. It is the need to resolve these differences that motivates this
document, which describes 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. To serve as the necessary common frame of reference, this
document describes the enhanced Internet Mail architecture,
reflecting the current service. The document focuses on: Capturing refinements to the email model Clarifying functional roles for the
architectural components Clarifying identity-related issues, across the
email service Defining terminology for architectural
components and their interactions The first standardized architecture for networked email
specified a simple split between the user world, in the
form of Mail User Agents (MUA), and the transfer world, in
the form of the Mail Handling Service (MHS), which is
composed of Mail Transfer Agents (MTA) . The MHS accepts a message from
one User and delivers it to one or more other users,
creating a virtual MUA-to-MUA exchange environment. As shown in , this defines two logical layers of
interoperability. One is directly between Users. The other
is among the 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. The operational service has evolved, although core aspects
of the service, such as mailbox addressing and message
format style, remaining remarkably constant. The original
distinction between the user level and transfer level
remains, but with elaborations in each. The term "Internet
Mail" is used to refer to the entire collection of user
and transfer components and services. For Internet Mail, the term "end-to-end" usually refers to
a single posting and the set of deliveries that result
from a single transit of the MHS. A common exception is
group dialogue that is mediated, through a Mailing List;
in this case, two postings occur before intended
Recipients receive an Author's message, as discussed in . 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 the email service.
Examples are voicemail over email ", EDI over email and facsimile over email . End-to-end Internet Mail exchange is accomplished by using
a standardized infrastructure with these components and
characteristics: An email object Global addressing An asynchronous sequence of point-to-point
transfer mechanisms No prior arrangement between MTAs or
between Authors and Recipients No prior arrangement between point-to-point
transfer services over the open Internet No requirement for Author, Originator, or
Recipients to be online at the same
time The end-to-end portion of the service is the email object,
called a “message.” Broadly, the message itself
distinguishes control information, for handling, from the
Author's content. A precept to the design of mail over the open Internet is
permitting user-to-user and MTA-to-MTA interoperability
without prior, direct arrangement between the independent
administrative authorities responsible for handling a
message. All participants rely on having the core services
universally supported and accessible, either directly or
through Gateways that act as translators between Internet
Mail and email environments conforming to other standards.
Given the importance of spontaneity and serendipity in
interpersonal communications, not requiring such
prearrangement between participants is a core benefit of
Internet Mail and remains a core requirement for it. Within localized networks at the edge of the public
Internet, prior administrative arrangement often is
required and can include access control, routing
constraints, and configuration of the information query
service. Although recipient authentication has usually
been required for message access since the beginning of
Internet Mail, in recent years it also has been required
for message submission. In these cases, a server validates
the client's identity, whether by explicit security
protocols or by implicit infrastructure queries to
identify "local" participants. 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 <RFC5322.From>
is the IMF From: header field in an email content header
and <RFC5321.MailFrom> is the address in the
SMTP "Mail From" command. When occurring without the IMF (rfc5322) qualifier, header
field names are shown with a colon suffix. For example,
From:. References to labels for actors, functions or components
have the first letter capitalized. Also, 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 [RFC2119] . Remove the
following paragraph before publication. Please
direct discussion about this document to
the IETF-SMTP mailing list . Internet Mail is a highly distributed service, with a variety
of actors playing different roles. These actors fall into
three basic types: User Mail Handling Service (MHS)ADministrative Management Domain (ADMD)Although related to a technical architecture, the focus on
actors concerns participant responsibilities, rather than
functionality of modules. For that reason, the labels used are
different from those used in classic email architecture
diagrams. Users are the sources and sinks of messages. Users can be
people, organizations, or processes. They can have an
exchange that iterates, and they can expand or contract
the set of users that participate in a set of exchanges.
In Internet Mail, there are four types of Users: Authors RecipientsReturn HandlersMediators shows the primary and secondary
flows of messages among them. From the user 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. Whenever any MHS actor sends information to back to an
Author or Originator in the sequence of handling a
message, that actor is a User. The Author is responsible for creating the message,
its contents, and its list of recipient addresses. The
MHS transfers the message from the Author and delivers
it to the Recipients. The MHS has an Originator role () that correlates with the
Author role. The Recipient is a consumer of the delivered message.
The MHS has a Receiver role () that correlates with the
Recipient role. This is labeled Recv in . Any Recipient can close the user communication loop by
creating and submitting a new message that replies to
the Author. An example of an automated form of reply
is the Message Disposition Notification (MDN), which
informs the Author about the Recipient's handling of
the message. (See .)Also called "Bounce Handler", the Return Handler is a
special form of Recipient tasked with servicing
notifications that the MHS generates, as it transfers
or delivers the message. These notices can be about
failures or completions and are sent to an address
that is specified by the Originator. This Return
Handling address (also known as a Return address)
might have no visible characteristics in common with
the address of the Author or Originator. A Mediator receives, aggregates, reformulates, and
redistributes messages among Authors and Recipients
who are the principals in (potentially) protracted
exchanges. This activity is easily confused with the
underlying MHS transfer exchanges. However, each
serves very different purposes and operates in very
different ways. When mail is delivered to the Mediator specified in the
RFC5321.RcptTo command for the original message, the
MHS handles it the same way as for any other
Recipient. In particular, the MHS sees each posting
and delivery activity between sources and sinks as
independent; it does not see subsequent re-posting as
a continuation of a process. Because the Mediator
originates messages, it can receive replies. Hence,
when submitting a reformulated message, the Mediator
is an Author, albeit an author actually serving as an
agent of one or more other authors. So a Mediator
really is a full-fledged User. Mediators are
considered extensively in . A Mediator attempts to preserve the original Author's
information in the message it reformulates but is
permitted to make meaningful changes to the message
content or envelope. The MHS sees a new message, but
users receive a message that they interpret as being
from, or at least initiated by, the Author of the
original message. The role of a Mediator is not
limited to merely connecting other participants; the
Mediator is responsible for the new message. A Mediator's role is complex and contingent, for
example, modifying and adding content or regulating
which users are allowed to participate and when. The
common example of this role is a group Mailing List.
In a more complex use, a sequence of Mediators could
perform a sequence of formal steps, such as reviewing,
modifying, and approving a purchase request. A Gateway is a particularly interesting form of
Mediator. It is a hybrid of User and Relay that
connects heterogeneous mail services. Its purpose is
to emulate a Relay. For a detailed discussion, see . The Mail Handling Service (MHS) performs a single
end-to-end transfer on behalf of the Author to reach the
Recipient addresses specified in the original
RFC5321.RcptTo commands. Exchanges that are either
mediated or iterative and protracted, such as those used
for collaboration over time are handled by the User
actors, not by the MHS actors. The Originator ensures that a message is valid for
posting and then submits it to a Relay. A message is
valid if it conforms to both Internet Mail standards
and local operational policies. The Originator can
simply review the message for conformance and reject
it if it finds errors, or it can create some or all of
the necessary information. In effect, the Originator
is responsible for the functions of the Mail
Submission Agent. The Originator operates with dual allegiance. It serves
the Author and can be the same entity. But 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). The Originator also performs any post-submission,
Author-related administrative tasks associated with
message transfer and delivery. Notably, these tasks
pertain to sending error and delivery notices,
enforcing local policies, and dealing with messages
from the Author that prove to be problematic for the
Internet. The Originator is accountable for the
message content, even when it is not responsible for
it. The Author creates the message, but the Originator
handles any transmission issues with it. The Relay performs MHS-level transfer-service routing
and store-and-forward, by transmitting or
retransmitting the message to its Recipients. The
Relay adds trace information but does not modify the
envelope information or the message content semantics.
It can modify message content representation, such as
changing the form of transfer encoding from binary to
text, but only as required to meet the capabilities of
the next hop in the MHS. A Mail Handling Service (MHS) network consists of a set
of Relays. This network is above any underlying
packet-switching network that might be used and below
any Gateways or other Mediators. In other words, email scenarios can involve three
distinct architectural layers, each providing its own
type of data of store-and-forward service: User Mediators MHS RelaysPacket Switches The bottom layer is the Internet's IP service. The most
basic email scenarios involve Relays and Switches. When a Relay stops attempting to transfer a message, it
becomes an Author because it must send an error
message to the Return address. The potential for
looping is avoided by omitting a Return address from
this message. A Gateway is a hybrid of User and Relay that connects
heterogeneous mail services. Its purpose is to emulate
a Relay and the closer it comes to this, the better. A
Gateway operates as a User when it needs the ability
to modify message content. Differences between mail services can be as small as
minor syntax variations, but they usually encompass
significant, semantic distinctions. One difference
could be email addresses that are hierarchical and
machine-specific rather than a flat, global namespace.
Another difference could be support for text-only
content or multi-media. Hence the Relay function in a
Gateway presents a significant design challenge, if
the resulting performance is to be seen as nearly
seamless. The challenge is to ensure user-to-user
functionality between the services, despite
differences in their syntax and semantics. The basic test of Gateway design is 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 components in the Author's or
Recipient's mail services other than adding the
Gateway. To each of these otherwise independent
services, the Gateway appears to be a native
participant. But the ultimate test of Gateway design
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 Author?The Receiver performs final delivery or sends the
message to an alternate address. It can also perform
filtering and other policy enforcement immediately
before or after delivery. Administrative actors can be associated with different
organizations, each with its own administrative authority.
This operational independence, coupled with the need for
interaction between groups, provides the motivation to
distinguish among ADministrative Management Domains (ADMDs
). Each ADMD can have vastly different operating policies
and trust-based decision-making. One obvious example is
the distinction between mail that is exchanged within an
organization and mail that is exchanged between
independent organizations. The rules for handling both
types of traffic tend to be quite different. That
difference requires defining the boundaries of each, and
this requires the ADMD construct. Operation of Internet Mail services is carried out by
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. A
department that operates a local Relay, an IT department
that operates an enterprise Relay, and an ISP that
operates a public shared email service can be configured
into many combinations of administrative and operational
relationships. Each is a distinct ADMD, potentially having
a complex arrangement of functional components. depicts relationships among ADMDs.
The benefit of the ADMD construct is to facilitate
discussion about designs, policies and operations that
need to distinguish between internal issues and external
ones. The architectural impact of the need for boundaries
between ADMDs is discussed in . Most significant is that the
entities communicating across ADMD boundaries typically
have the added burden of enforcing organizational policies
concerning external communications. At a more mundane
level, routing mail between ADMDs can be an issue, such as
needing to route mail between organizational partners over
specially trusted paths. These are three basic types of ADMDs: Independent transfer
services in networks at the edge of the
open Internet Mail service. This might be a
type of Edge service, as is common for
web-based email access. Mail Service
Providers (MSP) that offer value-added
capabilities for Edge ADMDs, such as
aggregation and filtering. The mail-level transit service is different from
packet-level switching. End-to-end packet transfers
usually go through intermediate routers; email exchange
across the open Internet can be directly between the
Boundary MTAs of Edge ADMDs. This distinction between
direct and indirect interaction highlights the
differences discussed in Edge networks can use proprietary email standards
internally. However the distinction between Transit
network and Edge network transfer services is 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 the transitions of
responsibility and the accountability and authorization
relationships among participants in message transfer. The interactions of ADMD components are subject to the
policies of that domain, which cover concerns such as
these: Reliability Access control Accountability Content evaluation and modification These policies can be implemented in different functional
components, according to the needs of the ADMD. For
example, see . Consumer, 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. These are common examples of ADMDs: Enterprise Service Providers: These ADMDs operate the internal data
and/or the mail services within an
organization. Internet Service Providers (ISP): These ADMDs operate the underlying data
communication services, which are used by
one or more Relay and User. ISPs are not
responsible for performing email
functions, but they can provide an
environment in which those functions can
be performed. Mail Service Providers: These ADMDs operate email services, such as
for consumers or client companies. Practical operational concerns demand that providers be
involved in administration and enforcement issues. This
involvement can extend to operators of lower-level packet
services. Internet Mail uses three forms of identity: mailbox, domain
name, message-ID and ENVID. Each must be globally unique. "A mailbox sends and receives mail. It is a
conceptual entity which does not necessarily
pertain to file storage." A mailbox is specified as an Internet Mail address
<addr&nbhy;spec>. It has two distinct
parts, separated by an at&nbhy;sign (@). The right
side is a globally interpreted domain name associated with
an ADMD. Domain names are discussed in . Formal Internet Mail addressing
syntax can support source routes, to indicate the path
through which a message ought to be sent. The use of
source routes is not common and has been deprecated in . The portion to the left of the at&nbhy;sign contains a
string that is globally opaque and is called the
<local&nbhy;part>. It is to be
interpreted only by the entity specified by the address's
domain name. Except as noted later in this section all
other entities MUST treat the
<local&nbhy;part> as an 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 creator. Some local&nbhy;part values have been standardized,
for contacting personnel at an organization. These names
cover common operations and business functions. It is common for sites to have local structuring
conventions for the left-hand side
<local&nbhy;part> of an
<addr&nbhy;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 MUST NOT be
interpreted by any domain except the one listed in the
right side of the <addr&nbhy;spec>. The
exceptions are those specialized services that conform to
public, standardized conventions, as noted below. Basic email addressing defines the
<local&nbhy;part> as being globally
opaque. However there are some uses of email that add a
standardized, global schema to the value, such as between
an author and a Gateway. The
<local&nbhy;part> details remain
invisible to the public email transfer infrastructure, but
provide addressing and handling instructions for further
processing by the Gateway. Standardized examples of such
conventions are the telephone numbering formats for VPIM such as: and iFax , such as: Email addresses are being used far beyond their original
role in email transfer and delivery. In practical terms,
an email address string has become the common identifier
for representing online identity. Hence, it is essential
to be clear about both the nature and role of an identity
string in a particular context and the entity responsible
for setting that string. For example, see , and . 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 can encompass an organization, a
collection of machines integrated into a homogeneous
service, or a single machine. A domain name can be
administered to refer to an individual user, but this is
not common practice. The name is structured as a
hierarchical sequence of names, separated by dots (.),
with the top of the hierarchy being on the right end of
the sequence. There can be many names in the sequence --
that is, the depth of the hierarchy can be substantial.
Domain names are defined and operated through the Domain
Name System (DNS) , , . When not part of a mailbox address, a domain name is used
in Internet Mail to refer to the ADMD or to the host that
took action upon the message, such as providing the
administrative scope for a message identifier or
performing transfer processing. There are two standardized tags for identifying messages:
Message-ID: and ENVID. A Message-ID: pertains to content,
and an ENVID pertains to transfer. Internet Mail standards provide for, at most, a single
Message-ID:. The Message-ID: for a single message,
which is a user-level IMF tag, has a variety of uses
including threading, aiding identification of
duplicates, and DSN tracking. . The Originator assigns the
Message-ID:. The Recipient's ADMD is the intended
consumer of the Message-ID:, although any actor along
the transfer path can use it. Message-ID: MUST be globally unique. Its format is
similar to that of a mailbox, with two distinct parts,
separated by an at&nbhy;sign (@). Typically, the
right side specifies the ADMD or host that assigns the
identifier, and the left side contains a string that
is globally opaque and serves to uniquely identify the
message within the domain referenced on the right
side. The duration of uniqueness for the message
identifier is undefined. When a message is revised in any way, the decision
whether to assign a new Message-ID: requires a
subjective assessment to determine whether the
editorial content has been changed enough to
constitute a new message. states that "a message
identifier pertains to exactly one instantiation of a
particular message; subsequent revisions to the
message each receive new message identifiers." Yet
experience suggests that some flexibility is needed.
An impossible test is whether the recipient will
consider the new message to be equivalent to the old
one. 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. Here are some guidelines and examples: If a message is changed only in form,
such as character encoding, it is
still the same message. If a message has minor additions to the
content, such as a mailing list tag at
the beginning of the RFC5322.Subject
header field, or some mailing list
administrative information added to
the end of the primary body-part text,
it is probably the same message.If a message has viruses deleted from
it, it is probably the same message. If a message has offensive words
deleted from it, some recipients will
consider it the same message, but some
will not. If a message is translated into a
different language, some recipients
will consider it the same message, but
some will not. If a message is included in a digest of
messages, the digest constitutes a new
message. If a message is forwarded by a
recipient, what is forwarded is a new
message. If a message is "redirected", such as
using IMF "Resent-*" header fields,
some recipients will consider it the
same message, but some will not. The absence of both objective, precise criteria for
regenerating a Message-ID: and 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. For that reason, the Message-ID: SHOULD
NOT be used for any function that has security
implications. The ENVID (envelope identifier) can be used for
message-tracking purposes (, ) concerning a single
posting/delivery transfer. The ENVID labels a single
transit of the MHS by a specific message. So, the
ENVID is used for one message posting, until that
message is delivered. A re-posting of the message,
such as by a Mediator, does not reuse that ENVID, but
can use a new one, even though the message might
legitimately retain its original Message-ID:. 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. The Internet Mail architecture comprises six basic types of
functionality, which are arranged to support a
store-and-forward service. As shown in , each type can have multiple
instances, some of which represent specialized roles. This
section considers the activities and relationships among these
components, and the Internet Mail standards that apply to
them. MessageMail User Agent (MUA)Author MUA (aMUA)Recipient MUA (rMUA)Message Submission Agent (MSA)Author-focused MSA functions (aMSA)MHS-focused MSA functions (hMSA)Message Transfer Agent (MTA)Message Delivery Agent (MDA)Recipient-focused MDA functions (rMDA)MHS-focused MDA functions (hMDA)Message Store (MS)Author MS (aMS) Recipient MS (rMS) The purpose of the Mail Handling Service (MHS) is to
exchange an IMF message object among participants . All of its underlying mechanisms
serve to deliver that message from its Author to its
Recipients. A message can be explicitly labeled as to its
nature . 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 handling trace
information and structured fields that are part of the
Author’s message content. The body can be unstructured
lines of text or a tree of multi-media subordinate
objects, called “body-parts” or attachments , , , , , . In addition, Internet Mail has a few conventions for
special control data, notably: Delivery Status Notification (DSN): A Delivery Status Notification (DSN) is a
message that can be generated by the MHS
(MSA, MTA, or MDA) and sent to the
RFC5321.MailFrom address. An MDA and MTA
are shown as sources of DSNs in , and the
destination is shown as Returns. DSNs
provide information about message transit,
such as transfer errors or successful
delivery. Message Disposition Notification (MDN): A Message Disposition Notification (MDN)
is a message that provides information
about post-delivery processing, such as
indicating that the message has been
displayed or the form of
content that can be supported . It can be
generated by an rMUA and is sent to the
Disposition-Notification-To addresses. The
mailbox for this is shown as Disp in . Message Filtering (SIEVE): Sieve is a scripting language used to
specify conditions for differential
handling of mail, typically at the time of
delivery . Scripts can be
conveyed in a variety of ways, such as a
MIME part in a message. shows a Sieve
script 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. the shows only one
relationship, for (relative) simplicity. Internet Mail has a fragmented framework for
transit-related handling information. Information that
is used directly by the MHS is called the "envelope."
It directs handling activities by the transfer service
and is carried in transfer service commands. That is,
the envelope exists in the transfer protocol SMTP. Trace information, such as RFC5322.Received, is
recorded in the message header and is not subsequently
altered. Header fields are attribute name/value pairs that
cover an extensible range of email service parameters,
structured user content, and user transaction
meta-information. The core set of header fields is
defined in . It is common practice to
extend this set for different applications. Procedures
for registering header fields are defined in . An extensive set of existing
header field registrations is provided in . One danger of placing additional information in header
fields is that Gateways often alter or delete them. The body of a message might be lines of ASCII text or
a hierarchically structured composition of
multi-media body-part attachments, using MIME. , , , , lists the core identifiers
present in a message during transit. LayerFieldSet ByMessage BodyMIME HeaderAuthorMessage header fieldsFrom:AuthorSender:OriginatorReply-To:AuthorTo:, CC:, BCC:AuthorMessage-ID:OriginatorReceived:Originator, Relay, ReceiverReturn-Path:MDA, from MailFromResent-*:MediatorList-Id:MediatorList-*:MediatorSMTPHELO/EHLOLatest Relay ClientENVIDOriginatorMailFromOriginatorRcptToAuthorORCPTOriginatorIPSource AddressLatest Relay Client Legend: Layer - The part of the email
architecture that uses the identifier; Field - The
protocol construct that contains the identifier;
Set By - The actor role responsible for specifying
the identifier value (and this can be different
from the actor that performs the fill-in function
for the protocol construct) These are the most common address-related fields: Set by -
Author Names and addresses for authors of the
message content are listed in the
From: field. Set by
- Author If a Recipient sends a reply message
that would otherwise use the
RFC5322.From field addresses in the
original message, the addresses in the
RFC5322.Reply-To field are used
instead. In other words, this field
overrides the From: field for
responses from Recipients. Set by -
Originator This field specifies the address
responsible for submitting the message
to the transfer service. This field
can be omitted if it contains the same
address as RFC5322.From. However,
omitting this field does not mean that
no Sender is specified; it means that
that header field is virtual and that
the address in the From: field MUST be
used. Specification of the notifications
Return addresses, which are contained
in RFC5321.MailFrom, is made by the
RFC5322.Sender. Typically the Return
address is the same as the Sender
address. However, some usage scenarios
require it to be different. Set by -
Author These fields specify MUA Recipient
addresses. However, some or all of the
addresses in these fields might not be
present in the RFC5321.RcptTo
commands. 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 as
a courtesy. Set by -
Author A copy of the message might be sent to
an addressee whose participation is
not to be disclosed to the RFC5322.To
or RFC5322.CC Recipients and, usually,
not to the other BCC Recipients. The
BCC: header field indicates a message
copy to such a Recipient. Use of this
field is discussed in . Set
by - Originator, MSA, MTA Any SMTP client -- including
Originator, MSA, or MTA -- can specify
its hosting domain identity for the
SMTP HELO or EHLO command operation. Set by -
Originator 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. Set by
- Originator This field is an end-to-end string that
specifies an email address for
receiving return control information,
such as returned messages. 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 RFC5321.MailFrom
address. Ultimately, the simple basis
for deciding which address needs to be
in the RFC5321.MailFrom field is to
determine which address must be
informed about transfer-level problems
(and possibly successes.) Set by -
Author, Final MTA, MDA.This field specifies the MUA mailbox
address of a Recipient. The string
might not be visible in the message
content header. For example, the IMF
destination address header fields,
such as RFC5322.To, might specify a
mailing list mailbox, while the
RFC5321.RcptTo address specifies a
member of that list. Set by -
Author. This is an optional parameter to the
RCPT command, indicating the original
address to which the current RCPT TO
address corresponds, after a mapping
was performed during transit. An ORCPT
is the only reliable way to correlate
a DSN from a multi-recipient message
transfer with the intended recipient. Set by
- Originator, Relay, Mediator, Dest This field contains trace information,
including originating host, Relays,
Mediators, and MSA host domain names
and/or IP Addresses. Set
by - Originator The MDA records the RFC5321.MailFrom
address into the RFC5322.Return-Path
field. Set by
- Mediator Author This field provides a globally unique
mailing list naming framework that is
independent of particular hosts. 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. The
result is rarely a true domain name,
listed in the domain name service,
although it can be. Set by -
Mediator Author 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. Set
by - The Client SMTP sending host
immediately preceding the current
receiving SMTP server. 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, which makes
it independent of mail-level
mechanisms. As such, it is often taken
to be authoritative, although it is
possible to provide false addresses. Interactions at the user level entail protocol exchanges,
distinct from those that occur at lower layers of the
Internet Mail MHS architecture that is, in turn, above the
Internet Transport layer. Because the motivation for
email, and much of its use, is for interaction among
people, the nature and details of these protocol exchanges
often are determined by the needs of interpersonal and
group communication. To accommodate the idiosyncratic
behavior inherent in such communication, only subjective
guidelines, rather than strict rules, can be offered for
some aspects of system behavior. Mailing Lists provide
particularly salient examples. A Mail User Agent (MUA) works on behalf of User actors
and User applications. It is their representative
within the email service. The Author MUA (aMUA) 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 (aMS). An MUA aMS can organize messages in many
different ways. A common model uses aggregations,
called "folders"; in IMAP they are called "mailboxes".
This model allows 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 transfer
(Sent). But none of these folders is required. For
example, IMAP allows drafts to be stored in any
folder; so no Drafts folder needs to be present.The Recipient MUA (rMUA) works on behalf of the
Recipient to process received mail. This processing
includes generating user-level disposition control
messages, displaying and disposing of the received
message, and closing or expanding the user
communication loop by initiating replies and
forwarding new messages. Although not shown
in , an MUA
itself can have a distributed
implementation, such as a "thin" user
interface module on a constrained
device such as a smartphone, with most
of the MUA functionality running
remotely on a more capable server. An
example of such an architecture might
use IMAP for most of
the interactions between an MUA client
and an MUA server. An approach for
such scenarios is defined by . A Mediator is special class of MUA. It performs
message re-posting, as discussed in . An MUA can be automated, on behalf of a user who is not
present at the time the MUA is active. One example is
a bulk sending service that has a timed-initiation
feature. These services are not to be confused with a
mailing list Mediator, since there is no incoming
message triggering the activity of the automated
service. A popular and problematic MUA is an automatic
responder, such as one that sends out-of-office
notices. This behavior might be confused with that of
a Mediator, but this MUA is generating a new message.
Automatic responders can annoy users of mailing lists
unless they follow . The identity fields are relevant to a typical MUA: RFC5322.From RFC5322.Reply-To RFC5322.Sender RFC5322.To, RFC5322.CC RFC5322.BCC An MUA can employ a long-term Message Store (MS). depicts an Author’s MS (aMS)
and a Recipient’s MS (rMS). An MS can be located on a
remote server or on the same machine as the MUA. An MS acquires messages from an MDA either proactively
by a local mechanism or even with a standardized
mechanism such as SMTP(!) or reactively by using POP
or IMAP. The MUA accesses the MS either by a local
mechanism or by using POP or IMAP. Using POP for
individual message accesses, rather than for bulk
transfer, is relatively rare and inefficient. A Mail Submission Agent (MSA) accepts the message
submitted by the aMUA and enforces the policies of the
hosting ADMD and the requirements of Internet
standards. An MSA represents an unusual functional
dichotomy. It represents the interests of the Author
(aMUA) during message posting, to facilitate posting
success; it also represents the interests of the MHS.
In the architecture, these responsibilities are
modeled, as shown in , by dividing the MSA into
two sub-components, aMSA and hMSA, respectively.
Transfer of responsibility for a single message, from
an Author's environment to the MHS, is called
"posting". In it is marked as the (S)
transition, within the MSA. The hMSA takes 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 MSA performs final message
preparation for submission and effects the transfer of
responsibility to the MHS, via the hMSA. The amount of
preparation depends upon the local implementations.
Examples of oMSA tasks include adding header fields,
such as Date: and Message-ID:, and modifying portions
of the message from local notations to Internet
standards, such as expanding an address to its formal
IMF representation. Historically, standards-based MUA/MSA message postings
have used SMTP. The standard currently
preferred is SUBMISSION. Although SUBMISSION derives
from SMTP, it uses a separate TCP port and imposes
distinct requirements, such as access authorization. These identities are relevant to the MSA: RFC5321.HELO/.EHLO RFC3461.ENVID RFC5321.MailFrom RFC5321.RcptTo RFC5321.Received RFC0791.SourceAddr 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
Recipients. 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. 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 change addresses in the
envelope or reformulate the editorial content. A
change in data form, such as to MIME
Content-Transfer-Encoding, is within the purview of an
MTA, but removal or replacement of body content is
not. An MTA also adds trace information. Within a
destination ADMD, email relaying
modules can make a variety of changes
to the message, prior to delivery. In
such cases, these modules are acting
as Gateways, rather than MTAs. Internet Mail uses SMTP , primarily to effect
point-to-point transfers between peer MTAs. Other
transfer mechanisms include Batch SMTP and ODMR . As with most network layer
mechanisms, the Internet Mail SMTP supports a basic
level of reliability, by virtue of providing for
retransmission after a temporary transfer failure.
Unlike typical packet switches (and Instant Messaging
services), Internet Mail MTAs are expected to store
messages in a manner that allows recovery across
service interruptions, such as host system shutdown.
The degree of such robustness and persistence by an
MTA can vary. The base SMTP specification provides a
framework for protocol response codes. An extensible
enhancement to this framework is defined in Although quite basic, the primary routing mechanism
for Internet Mail is the DNS MX record , which specifies an MTA
through which the queried domain can be reached. This
mechanism presumes a public, or at least a common,
backbone that permits any attached MTA to connect to
any other. MTAs can perform any of these well-established roles: An MTA that
is part of an ADMD and interacts with
MTAs in other ADMDs. This is also
called a Border MTA. There can be
different Boundary MTAs, according to
the direction of mail-flow. An
MTA that relays messages to
other ADMDs. An
MTA that receives inbound SMTP
messages from MTA Relays in
other ADMDs, for example, an
MTA running on the host listed
as the target of an MX
record. The MTA that
transfers a message to the MDA. These identities are relevant to the MTA: Set by
- Relay Server A transfer of responsibility from the MHS to a
Recipient's environment (mailbox) is called
"delivery." In the architecture, as depicted in , delivery takes place within
a Mail Delivery Agent (MDA) and is shown as the (D)
transition from the MHS-oriented MDA component (hMDA)
to the Recipient-oriented MDA component (rMDA). An MDA can provide distinctive, address-based
functionality, made possible by its detailed
information about the properties of the destination
address. This information 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 is
required to know where to deliver the message. Like an MSA, an MDA serves two roles, as depicted in . Formal transfer of
responsibility, called "delivery", is effected between
the two components that embody these roles as shows as
"(D)" in . 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 that the Recipient specifies. Transfer into the MDA is accomplished by a normal MTA
transfer mechanism. Transfer from an MDA to an MS uses
an access protocol, such as POP or IMAP. The term
"delivery" can refer to the formal,
MHS function specified here or to the
first time a message is displayed to a
Recipient. A simple, practical test
for whether the MHS-based definition
applies is whether a DSN can be
generated. These identities are relevant to the MDA: Set
by - Author Originator or Mediator
Originator The MDA records the RFC5321.MailFrom
address into the RFC5322.Return-Path
field. Set by
- MDA server An MDA can record a Received: header
field to indicate trace information,
including source host and receiving
host domain names and/or IP
Addresses. From the origination site to the point of delivery,
Internet Mail usually follows a "push" model. That is, the
actor that holds the message initiates transfer to the
next venue, typically with SMTP or LMTP . With a "pull" model, the actor
that holds the message waits for the actor in the next
venue to initiate a request for transfer. Standardized
mechanisms for pull-based MHS transfer are ETRN and ODMR . After delivery, the Recipient's MUA (or MS) can gain
access by having the message pushed to it or by having the
receiver of access pull the message, such as by using POP and IMAP . A discussion of any interesting system architecture often
bogs down when architecture and implementation are
confused. 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. For example, a
software system that primarily performs message relaying
is an MTA, yet it might also include MDA functionality.
That same MTA system might be able to interface with
non-Internet email services and thus perform both as an
MTA and as a Gateway. Similarly, implemented modules might be configured to form
elaborations of the architecture. An interesting example
is a distributed MS. One portion might be a remote server
and another might be local to the MUA. As discussed in , there are three operational
relationships among such MSs: The MS is remote,
and messages are accessible only when the
MUA is attached to the MS so that the MUA
will re-fetch all or part of a message,
from one session to the next. The MS is local to
the user, and messages are completely
moved from any remote store, rather than
(also) being retained there. An rMS and a
uMS are kept synchronized, for all or part
of their contents, while they are
connected. When they are disconnected,
mail can arrive at the rMS and the user
can make changes to the uMS. The two
stores are re-synchronized when they are
reconnected. Basic message transfer from Author to 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 sequence of postings and deliveries through
Mediators. A Mediator forwards a message, through a re-posting
process. The Mediator shares some functionality with basic MTA
relaying, but has greater flexibility in both addressing and
content than is available to MTAs. This is the core set of message information that is commonly
set by all types of Mediators: Set by -
Mediator Originator Set by - Mediator
Originator Set by -
Mediator Author Set by -
Mediator Dest The Mediator 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
include everything from original posting,
through relaying, to final delivery. The aspect of a Mediator that distinguishes it from any other
MUA creating a 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.Examples of MUA messages that a Mediator does not create
include: New message that forwards an existing message: Although this action provides a basic template
for a class of Mediators, its typical
occurrence is not, itself, an example of a
Mediator. The new message is viewed as being
from the actor that is doing the forwarding,
rather than from the original Author. A new message encapsulates the original
message and is seen as from the new
Originator. This Mediator Originator might add
commentary and can modify the original message
content. Because the forwarded message is a
component of the message sent by the new
Originator, the new message creates a new
dialogue. However the final Recipient still
sees the contained message as from the
original Author. Reply: When a Recipient responds to the Author of a
message, the new message is not typically
viewed as a forwarding of the original. Its
focus is the new content, although it might
contain all or part of the material from the
original message. The earlier material is
merely contextual and secondary. This includes
automated replies, such as vacation
out-of-office notices, as discussed in . Annotation: 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 primary purpose of the new message is to
provide commentary from a new Author, similar
to a Reply. The remainder of this section describes common examples of
Mediators. One function of an MDA is to determine the internal
location of a mailbox in order to perform delivery. An
Alias is a simple re-addressing facility that provides one
or more new Internet Mail addresses, rather than a single,
internal one; the message continues through the transfer
service, for delivery to one or more alternate addresses.
Although typically implemented as part of an MDA, this
facility is a Recipient function. It resubmits the
message, although all handling information except the
envelope recipient (rfc5321.RcptTo) address is retained.
In particular, the Return address (rfc5321.MailFrom) is
unchanged. What is distinctive about this forwarding mechanism is how
closely it resembles normal MTA store-and-forward
relaying. Its only significant difference is that it
changes the RFC5321.RcptTo value. Because this change is
so small, aliasing can be viewed as a part of the
lower-level mail relaying activity. However, this small
change has a large semantic impact: The designated
recipient has chosen a new recipient. When the replacement
list includes more than one address, the
alias is increasingly likely to have
delivery problems. Any problem reports go
to the original Author, not the
administrator of the alias entry. This
makes it more difficult to resolve the
problem, because the original Author has
no knowledge of the Alias mechanism.Including the core set of message information listed at the
beginning of this section, Alias typically changes: Set by
- Author These fields retain their original
addresses. Set by -
Author The benefit of retaining the original
MailFrom value is to ensure that an actor
related to the originating ADMD knows
there has been a delivery problem. On the
other hand, the responsibility for
handling problems, when transiting from
the original recipient mailbox to the
alias mailbox usually lies with that
original Recipient, because the Alias
mechanism is strictly under that
Recipient's control. Retaining the
original MailFrom address prevents this. Also called the ReDirector, the ReSender's actions differ
from forwarding because the Mediator "splices" a message's
addressing information to connect the Author of the
original message with the Recipient of the new message.
This connection permits them to have direct exchange,
using their normal MUA Reply functions, while also
recording full reference information about the Recipient
who served as a Mediator. Hence, the new Recipient sees
the message as being from the original Author, even if the
Mediator adds commentary. Including the core set of message information listed at the
beginning of this section, these identities are relevant
to a resent message: Set by -
original Author Names and addresses for the original Author
of the message content are retained. The
free-form (display-name) portion of the
address might be modified to provide
informal reference to the ReSender. Set by -
original Author If this field is present in the original
message, it is retained in the resent
message. Set by -
Author's Originator or Mediator
Originator. Set by
- original Author These fields specify the original message
Recipients. Set by -
Mediator Author This address is of the original Recipient
who is redirecting the message. Otherwise,
the same rules apply to the Resent-From:
field as to an original RFC5322.From
field. Set
by - Mediator Originator The address of the actor responsible for
resubmitting the message. As with
RFC5322.Sender, this field can be omitted
when it contains the same address as
RFC5322.Resent-From.
Set by: Mediator Author The addresses of the new Recipients who are
now able to reply to the original author. Set by -
Mediator Originator The actor responsible for resubmission
(RFC5322.Resent-Sender) is also
responsible for specifying the new
MailFrom address. A Mailing List receives messages as an explicit addressee
and then re-posts them to a list of subscribed members.
The Mailing List performs a task that can be viewed as an
elaboration of the ReSender. In addition to sending the
new message to a potentially large number of new
Recipients, the Mailing List can modify content, for
example, by deleting attachments, converting the format,
and adding list-specific comments. Mailing Lists also
archive messages posted by Authors. Still the message
retains characteristics of being from the original Author. Including the core set of message information listed at the
beginning of this section, these identities are relevant
to a mailing list processor, when submitting a message: Set by -
Mediator Author Set by -
Mediator Author Set by -
original Author Names and email addresses for the original
Author of the message content are
retained. Set by –
Mediator or original Author Although problematic, it is common for a
Mailing List to assign its own addresses
to the Reply-To: header field of messages
that it posts. This assignment is intended
to ensure that replies go to all list
members, rather than to only the original
Author. As a User actor, a Mailing List is
the Author of the new message and can
legitimately set the Reply-To: value. As a
Mediator attempting to represent the
message on behalf of its original Author,
creating or modifying a Reply-To: field
can be viewed as violating that Author's
intent. When the Reply-To is modified in
this way, a reply that is meant only for
the original Author will instead go to the
entire list. When the Mailing List does
not set the field, a reply meant for the
entire list can instead go only to the
original Author. At best, either choice is
a matter of group culture for the
particular list. Set by -
Author Originator or Mediator Originator This field usually specifies the address of
the actor responsible for Mailing List
operations. Mailing Lists that operate in
a manner similar to a simple MTA Relay
preserve as much of the original handling
information as possible, including the
original RFC5322.Sender field. (Note that
this mode of operation causes the Mailing
List to behave much like an Alias, with a
possible difference in number of new
addressees.) Set by -
original Author These fields usually contain the original
list of Recipient addresses. Set by -
Mediator Originator Because a Mailing List can modify the
content of a message in any way, it is
responsible for that content; that is, it
is an Author. As such, the Return Address
is specified by the Mailing List. Although
it is plausible for the Mailing List to
re-use the Return Address employed by the
original Originator, notifications sent to
that address after a message has been
processed by a Mailing List could be
problematic. A Gateway performs the basic routing and transfer work of
message relaying, but it also is permitted to modify
content, structure, address, or attributes as needed to
send the message into a messaging environment that
operates under 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 follow
similar technical standards, but significantly different
administrative policies, it is easy to view a Gateway as
merely an MTA. The critical distinction between an MTA and a Gateway is
that a Gateway can make substantive changes to a message
to map between the standards. In virtually all cases, this
mapping results in some degree of semantic loss. The
challenge of Gateway design is to minimize this loss.
Standardized gateways to Internet Mail are facsimile , voicemail , and MMS A Gateway can set any identity field available to an MUA.
Including the core set of message information listed at
the beginning of this section, these identities are
typically relevant to Gateways: Set by -
original Author Names and addresses for the original Author
of the message content are retained. As
for all original addressing information in
the message, the Gateway can translate
addresses as required to continue to be
useful in the target environment. Set by -
original Author The Gateway SHOULD retain this information,
if it is present. The ability to perform a
successful reply by a Recipient is a
typical test of Gateway functionality. Set by -
Author Originator or Mediator Originator This field can retain the original value or
can be set to a new address. Set by
- original Recipient These fields usually retain their original
addresses. Set by -
Author Originator or Mediator Originator The actor responsible for handling the
message can specify a new address to
receive handling notices. To enforce security boundaries, organizations can subject
messages to analysis, for conformance with its 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 add content to the
message that records the actions. This document describes the existing Internet Mail
architecture. It introduces no new capabilities. The
security considerations of this deployed architecture are
documented extensively in the technical specifications
referenced by this document. These specifications cover
classic security topics, such as authentication and
privacy. For example, email transfer protocols can use
standardized mechanisms for operation over authenticated
and/or encrypted links, and message content has similar
protection standards available. Examples of such
mechanisms include SMTP-TLS , SMTP-Auth , OpenPGP , and S/MIME . The core of the Internet Mail architecture does not impose
any security requirements or functions on the end-to-end
or hop-by-hop components. For example, it does not require
participant authentication and does not attempt to prevent
data disclosure. Particular message attributes might expose specific
security considerations. For example, the blind carbon
copy feature of the architecture invites disclosure
concerns, as discussed in section 7.2 of and section 5 of . Transport of text or non-text
content in this architecture has security considerations
that are discussed in , , , and as well as the security
considerations present in the IANA media types registry
for the respective types. Agents that automatically respond to email raise
significant security considerations, as discussed in . Gateway behaviors affect
end-to-end security services, as discussed in . Security considerations for
boundary filters are discussed in . See section 7.1 of for a discussion of the topic of
origination validation. As mentioned in , it is common practice for
components of this architecture to use the .SourceAddr to make policy
decisions , although the address can be
"spoofed". It is possible to use it without authorization.
SMTP and Submission authentication , provide more secure alternatives. The discussion of trust boundaries, ADMDs, actors, roles,
and responsibilities in this document highlights the
relevance and potential complexity of security factors for
operation of an Internet mail service. The core design of
Internet Mail to encourage open and casual exchange of
messages has met with scaling challenges, as the
population of email participants has grown to include
those with problematic practices. For example, spam, as
defined in , is a by-product of this
architecture. A number of standards track or BCP documents
on the subject have been issued. , , This document has no actions for IANA. The core Internet email standards are based on the use of
US-ASCII. That is SMTP and IMF , as well as their predecessors,
describe the transport and composition of messages
composed strictly of US-ASCII 7-bit encoded characters.
The standards have been incrementally enhanced to allow
for characters outside of this limited set, while
retaining mechanisms for backwards-compatibility. Specifically:The MIME specifications , , and allow for the use of coded
character sets and character encoding schemes
("charsets" in MIME terminology) other than
US-ASCII. MIME's allows the textual content
of a message to have a label affixed that
specifies the charset used in that content.
Equally MIME's allows the textual content
of certain header fields in a message to be
similarly labeled. However, since messages might
be transported over SMTP implementations only
capable of transporting 7-bit encoded characters,
MIME's also provides for "content
transfer encoding" so that characters of other
charsets can be re-encoded as an overlay to
US-ASCII. MIME's allows for the textual
content of a message to be in an 8-bit character
encoding scheme. In order to transport these
without re-encoding them, the SMTP specification
supports an option that permits the transport
of such textual content. However, the option does not address
the use of 8-bit content in message header fields,
and therefore encoding is still required
for those. A series of experimental protocols on Email Address
Internationalization (EAI) have been released that
extend SMTP and IMF to allow for 8-bit encoded
characters to appear in addresses and other
information throughout the header fields of
messages. specifies the format of
such message header fields (which encode the
characters in UTF-8), and specifies an SMTP option
for the transport of these messages. Hence, the use of UTF-8 is fully established in existing
Internet mail. However support for long-standing encoding
forms is retained and is still used. Key words for use in RFCs to
Indicate Requirement LevelsHarvard University1350 Mass. Ave. CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword 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: 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. Note that the force of these words is modified by
the requirement level of the document in which
they are used. Domain names -
concepts and facilitiesInformation Sciences Institute
(ISI)Post Office Protocol - Version 3Carnegie-Mellon University5000 Forbes AvePittsburghPA15213USjgm+@cmu.eduDover Beach Consulting, Inc. 420 Whisman CourtMountain ViewCA94043-2186USmrose@dbc.mtview.ca.usDomain names - implementation and specificationUSC/ISI4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message BodiesInnosoft International, Inc. 1050 East Garvey Avenue SouthWest CovinaCA91790US+1 818 919 3600+1 818 919 3614ned@innosoft.comFirst Virtual Holdings25 Washington AvenueMorristownNJ07960US+1 201 540 8967+1 201 993 3032nsb@nsb.fv.comSTD 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 (1) textual message bodies in character sets other
than US-ASCII,(2) an extensible set of different formats for
non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character sets
other than US-ASCII. 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 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. 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.
Multipurpose Internet Mail
Extensions (MIME) Part Two: Media TypesInnosoft International, Inc. 1050 East Garvey Avenue SouthWest CovinaCA91790US+1 818 919 3600+1 818 919 3614ned@innosoft.comFirst Virtual Holdings25 Washington AvenueMorristownNJ07960US+1 201 540 8967+1 201 993 3032nsb@nsb.fv.comSTD 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(1) textual message bodies in character sets other
than US-ASCII,(2) an extensible set of different formats for
non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character sets
other than US-ASCII. 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. 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. 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.
MIME (Multipurpose
Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII TextUniversity of Tennessee107 Ayres HallKnoxville TN 37996-1301moore@cs.utk.edu
Applications
American Standard Code for Information
Interchangemailmultipurpose Internet Mail extensionsSTD 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(1) textual message bodies in character
sets other than US-ASCII,(2) an extensible set of different formats
for non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character
sets other than US-ASCII. 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 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:+ RFC 2045, which specifies the various
header fields used to describe the
structure of MIME messages. + RFC 2046, which defines the general
structure of the MIME media typing system
and defines an initial set of media types,+ RFC 2048, which specifies various IANA
registration procedures for MIME-related
facilities, and+ RFC 2049, which describes MIME
conformance criteria and provides some
illustrative examples of MIME message
formats, acknowledgements, and the
bibliography. 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.
Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration ProceduresInnosoft International, Inc. 1050 East Garvey Avenue SouthWest CovinaCA 91790USA+1 818 919 3600+1 818 919 3614ned@innosoft.comMCI2100 Reston ParkwayRestonVA 22091+1 703 715-7361+1 703 715-7436klensin@mci.netUSC/Information Sciences Institute4676 Admiralty WayMarina del ReyCA 90292USA+1 310 822 1511+1 310 823 6714Postel@ISI.EDU
Applications
mailmedia typemultipurpose Internet Mail extensionsSTD 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(1) textual message bodies in character
sets other than US-ASCII,(2) an extensible set of different formats
for non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character
sets other than US-ASCII. 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:(1) media types,(2) external body access types,(3) content-transfer-encodings. Registration of character sets for use in MIME is
covered here and is no longer addressed by this
document. 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.
Media Type Specifications
and Registration ProceduresInnosoft International, Inc. 1050 East Garvey Avenue SouthWest CovinaCA 91790USA+1 818 919 3600+1 818 919 3614ned@innosoft.comMCI2100 Reston ParkwayRestonVA 22091+1 703 715-7361+1 703 715-7436klensin@mci.netUSC/Information Sciences Institute4676 Admiralty WayMarina del ReyCA 90292USA+1 310 822 1511+1 310 823 6714Postel@ISI.EDU
Applications
mailmedia typemultipurpose Internet Mail extensionsSTD 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(1) textual message bodies in character
sets other than US-ASCII,(2) an extensible set of different formats
for non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character
sets other than US-ASCII. 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:(1) media types,(2) external body access types,(3) content-transfer-encodings. Registration of character sets for use in MIME is
covered here and is no longer addressed by this
document. 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.
Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
ExamplesInnosoft International, Inc. 1050 East Garvey Avenue SouthWest CovinaCA 91790USA+1 818 919 3600+1 818 919 3614ned@innosoft.comFirst Virtual Holdings25 Washington AvenueMorristownNJ 07960USA+1 201 540 8967+1 201 993 3032nsb@nsb.fv.com
Applications
mailmultipurpose Internet Mail extensionsSTD 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(1) textual message bodies in character
sets other than US-ASCII,(2) an extensible set of different formats
for non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character
sets other than US-ASCII. 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. 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. 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. Clarifications to the DNS
SpecificationComputer ScienceParkvilleVictoria3052Australia. kre@munnari.OZ.ADMDeRGnet, Inc. 5147 Crystal Springs DriveBainbridge IslandWashington98110United States. NErandy@psg.com
Applications
DNSdomain name systemMessage Disposition NotificationMinimal FAX
address format in Internet MailGARR-ItalySincrotrone TriesteSS 14 Km 163.5 BasovizzaTriesteI 34012Italy+39 40 3758523+39 40 3758565Claudio.Allocchio@elettra.trieste.it
Applications
facsimilemailThis memo describes a simple method of encoding
PSTN addresses of facsimile devices in the
local&nbhy;part of Internet email addresses. 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). Message Submission for MailQUALCOMM Incorporated6455 Lusk Blvd. San DiegoCA92121-2779USA+1 619 651 5115+1 619 651 5334Randy@Qualcomm.ComMCI Telecommunications800 Boylston St, 7th floorBostonMA02199USA+1 617 960 1011klensin@mci.net
Applications
SMTPAn Extensible Message Format for Message
Disposition NotificationsNational Institutes of
HealthSimple Mail Transfer ProtocolInternet Message FormatInternet Message Access Protocol - Version 4rev1On-Demand Mail Relay (ODMR) SMTP with Dynamic IP
AddressesRegistration Procedures for Message Header FieldsNine by NineHP LabsThe Use of URLs as
Meta-Syntax for Core Mail List Commands and their
Transport through Message Header FieldsCalgary, Albertagrant@acm.orghttp://www.nisto.com/Box 2734902 Forbes AvenuePittsburghPA 15213-3799USAjosh@skyweyr.com
Applications
mailuniform resource locaterURLThe 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. 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. 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. 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. List-Id: A Structured Field and Namespace for the
Identification of Mailing ListsSieve: A Mail Filtering LanguageContent Negotiation for Messaging Services based on
EmailClearswift CorporationToshiba TECBrandenburg
InternetWorkingMessage Context for Internet MailSnowShore NetworksComverseMicrosoft CorporationNine by NineSimple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)Registration of Mail and MIME Header FieldsUniversity of OxfordStockholm University/KTInternet Email to Support Diverse Service
Environments (Lemonade) ProfileOracleIsode Ltd. Internet ProtocolUSC-ISIRecommendations for Automatic Responses to
Electronic MailA Registry for SMTP Enhanced Mail System Status
CodesAT&T LaboratoriesSimple Mail Transfer ProtocolInternet Message FormatQualcomm IncorporatedInternationalized Email HeadersTWNICTussle in Cyberspace: Defining Tomorrow’s InternetMIT Lab for Computer Scienceddc@lcs.mit.eduMIT Lab for Computer Sciencejtw@lcs.mit.edusollins@lcs.mit.eduUSC Information Sciences Institutebraden@isi.eduUsing International Characters in Internet MailInternet Mail ConsortiumSimple Mail Transfer ProtocolUniversity of Southern California
(USC)/Information Sciences Institute4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511Standard for the Format of ARPA Network Text
MessagesThe Rand CorporationBolt Beranek and Newman
Inc.Massachusets Institute of
TechnologyBolt Beranek and Newman
Inc.Standard for the format of ARPA Internet text
messagesUniversity of Delaware, Dept. of
Electrical EngineeringNewarkDE19711USDCrocker@UDel-RelaySMTP Service Extension for 8bit-MIMEtransportMCIInnosoftDover Beach Consulting,
Inc.Network Management Associates,
Inc.Silicon Graphics, Inc.MIME Encapsulation of EDI ObjectsBrandenburg InternetWorking675 Spruce DriveSunnyvaleCA94086USA+1.408.246.8253dcrocker@bbiw.netLocal Mail Transfer ProtocolCarnegie-Mellon University5000 Forbes Ave. Pittsburgh15213-3890PAjgm+@cmu.edu
Applications
mailThe Batch SMTP Media TypeAn Extensible Message Format for Delivery Status
NotificationsUniversity of TennesseeLucent TechnologiesVoice Profile for Internet Mail -
version 2 (VPIMv2)Lucent Technologies, Octel Messaging
Division17080 Dallas ParkwayDallasTX75248-1905USA+1 972 733 2722GregV@Lucent.ComNorthern TelecomP.O. Box 3511Station COttawaONK1Y 4H7Canada+1 613 763 7582+1 613 763 4461Glenn.Parsons@Nortel.ca
Applications
audiomailA 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. 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. 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.
SMTP Service Extension for Message TrackingFull-mode Fax Profile for Internet Mail: FFPIMBrandenburg InternetWorking675 Spruce DriveSunnyvaleCA94086USA+1.408.246.8253dcrocker@bbiw.netNine By NineEmail Submission Operations: Access and
Accountability RequirementsSIEVE Email Filtering: Spamtest and VirusTest
ExtensionsDistributed Electronic Models in IMAP4University of WashingtonMapping Between the Multimedia Messaging Service
(MMS) and Internet MailQualcommFacsimile Using Internet Mail (IFAX) Service of
ENUMPCCBrandenburgMailbox Names for Common services, Roles and
FunctionsInternet Mail ConsortiumAnti-Spam Recommendations for SMTP MTAsChalmers University of
TechnologySMTP Service Extension for Secure SMTP over
Transport Layer SecurityInternet Mail Consortium>SMTP Service Extension for
AuthenticationGoogle, Inc.OpenPGP Message FormatSecure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification SMTP Service Extension for Remote Message Queue
StartingGateways and MIME Security MultipartsInnosoft International,
Inc.A Tutorial on Gatewaying between X.400 and Internet
MailRARE Secretariat SMTP Extension for Internationalized Email
AddressesCNNICCNNICThis work began in 2004 and has evolved through numerous rounds
of community review; it derives from a section in an early
version of . Over its 4 years of development, the
draft has gone through 12 incremental versions, with vigorous
community review that produced many substantive changes.
Review was performed in the IETF and other email technical
venues. Although not a formal activity of the IETF, issues
with the document's contents were resolved using the classic
style of IETF community open, group decision-making. The
document is already cited in other work, such as for IMAP and
Sieve specifications and for academic classwork. The step of
standardizing is useful to provide a solid and stable
reference to the Internet's now-complex email service. Details of the Originator actor role was greatly clarified
during discussions in the IETF's Marid working group. Graham Klyne, Pete Resnick and Steve Atkins provided thoughtful
insight on the framework and details of the original drafts,
as did Chris Newman for the final versions, while also serving
as cognizant Area Director for the document. Tony Hansen
served as document shepherd, through the IETF process.Later reviews and suggestions were provided by Eric Allman,
Nathaniel Borenstein, Ed Bradford, Cyrus Daboo, Frank
Ellermann, Tony Finch, Ned Freed, Eric Hall, Willemien
Hoogendoorn, Brad Knowles, John Leslie, Bruce Valdis
Kletnieks, Mark E. Mallett, David MacQuigg, Alexey Melnikov,
der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M.
Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, and
Greg Vaudreuil. Diligent early proof-reading was performed by Bruce Lilly.
Diligent technical editing was provided by Susan Hunziker.The final stages of development for this document were guided
by a design team comprising: Alexey Melnikov, Pete Resnick,
Carl S. Gutekunst, Jeff Macdonald, Randall Gellens, Tony
Hansen and Tony Finch. Pete Resnick developed the final
version of the section on internationalization.