tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5598

 Errata 
Informational
Pages: 54
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~mail

Internet Mail Architecture

Part 1 of 3, p. 1 to 17
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                         D. Crocker
Request for Comments: 5598                   Brandenburg InternetWorking
Category: Informational                                        July 2009


                       Internet Mail Architecture

Abstract

   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.  To collaborate productively on
   this large and complex system, all participants need to 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.

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may

Page 2 
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  History  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  The Role of This Architecture  . . . . . . . . . . . . . .  6
     1.3.  Document Conventions . . . . . . . . . . . . . . . . . . .  7
   2.  Responsible Actor Roles  . . . . . . . . . . . . . . . . . . .  7
     2.1.  User Actors  . . . . . . . . . . . . . . . . . . . . . . .  8
     2.2.  Message Handling Service (MHS) Actors  . . . . . . . . . . 11
     2.3.  Administrative Actors  . . . . . . . . . . . . . . . . . . 14
   3.  Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     3.1.  Mailbox  . . . . . . . . . . . . . . . . . . . . . . . . . 17
     3.2.  Scope of Email Address Use . . . . . . . . . . . . . . . . 18
     3.3.  Domain Names . . . . . . . . . . . . . . . . . . . . . . . 19
     3.4.  Message Identifier . . . . . . . . . . . . . . . . . . . . 19
   4.  Services and Standards . . . . . . . . . . . . . . . . . . . . 21
     4.1.  Message Data . . . . . . . . . . . . . . . . . . . . . . . 24
       4.1.4.  Identity References in a Message . . . . . . . . . . . 25
     4.2.  User-Level Services  . . . . . . . . . . . . . . . . . . . 29
     4.3.  MHS-Level Services . . . . . . . . . . . . . . . . . . . . 31
     4.4.  Transition Modes . . . . . . . . . . . . . . . . . . . . . 34
     4.5.  Implementation and Operation . . . . . . . . . . . . . . . 35
   5.  Mediators  . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     5.1.  Alias  . . . . . . . . . . . . . . . . . . . . . . . . . . 37
     5.2.  ReSender . . . . . . . . . . . . . . . . . . . . . . . . . 38
     5.3.  Mailing Lists  . . . . . . . . . . . . . . . . . . . . . . 39
     5.4.  Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 41
     5.5.  Boundary Filter  . . . . . . . . . . . . . . . . . . . . . 42
   6.  Considerations . . . . . . . . . . . . . . . . . . . . . . . . 42
     6.1.  Security Considerations  . . . . . . . . . . . . . . . . . 42
     6.2.  Internationalization . . . . . . . . . . . . . . . . . . . 43
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 45
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 47
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 50
   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Top      ToC       Page 3 
1.  Introduction

   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.  These specifications form the
   core:

      *  Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821],
         [RFC5321]) moves a message through the Internet.

      *  Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822],
         [RFC5322]) defines a message object.

      *  Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines
         an enhancement to the message object that permits using
         multimedia 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 need to 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:

Top      ToC       Page 4 
      *  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

1.1.  History

   The first standardized architecture for networked email specified a
   simple split between the user world, in the form of Message User
   Agents (MUAs), and the transfer world, in the form of the Message
   Handling Service (MHS), which is composed of Message Transfer Agents
   (MTAs) [RFC1506].  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 Figure 1, this architecture 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, remain
   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
   Section 2.1.4.  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 [RFC3801], EDI
   (Electronic Data Interchange) over email [RFC1767], and facsimile
   over email [RFC4142].

Top      ToC       Page 5 
                                         +--------+
                      ++================>|  User  |
                      ||                 +--------+
                      ||                      ^
          +--------+  ||          +--------+  .
          |  User  +==++=========>|  User  |  .
          +---+----+  ||          +--------+  .
              .       ||               ^      .
              .       ||   +--------+  .      .
              .       ++==>|  User  |  .      .
              .            +--------+  .      .
              .                 ^      .      .
              .                 .      .      .
              V                 .      .      .
          +---+-----------------+------+------+---+
          |   .                 .      .      .   |
          |   .................>.      .      .   |
          |   .                        .      .   |
          |   ........................>.      .   |
          |   .                               .   |
          |   ...............................>.   |
          |                                       |
          |     Message Handling Service (MHS)    |
          +---------------------------------------+

          Legend: === lines indicate primary (possibly indirect)
                      transfers or roles
                  ... lines indicate supporting transfers or roles

                Figure 1: Basic Internet Mail Service Model

   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 requirement for prior arrangement between MTAs or between
         Authors and Recipients

      *  No requirement for prior arrangement between point-to-point
         transfer services over the open Internet

Top      ToC       Page 6 
      *  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.

1.2.  The Role of This Architecture

   An Internet service is an integration of related capabilities among
   two or more participating nodes.  The capabilities are accomplished
   across the Internet by one or more protocols.  What connects a
   protocol to a service is an architecture.  An architecture specifies
   how the protocols implement the service by defining the logical
   components of a service and the relationships among them.  From that
   logical view, a service defines what is being done, an architecture
   defines where the pieces are (in relation to each other), and a
   protocol defines how particular capabilities are performed.

   As such, an architecture will more formally describe a service at a
   relatively high level.  A protocol that implements some portion of a
   service will conform to the architecture to a greater or lesser
   extent, depending on the pragmatic tradeoffs they make when trying to
   implement the architecture in the context of real-world constraints.
   Failure to precisely follow an architecture is not a failure of the
   protocol, nor is failure to precisely cast a protocol a failure of

Top      ToC       Page 7 
   the architecture.  Where a protocol varies from the architecture, it
   will of course be appropriate for it to explain the reason for the
   variance.  However, such variance is not a mark against a protocol:
   Happily, the IETF prefers running code to architectural purity.

   In this particular case, this architecture attempts to define the
   logical components of Internet email and does so post hoc, trying to
   capture the architectural principles that the current email protocols
   embody.  To different extents, email protocols will conform to this
   architecture more or less well.  Insofar as this architecture differs
   from those protocols, the reasons are generally well understood and
   are required for interoperation.  The differences are not a sign that
   protocols need to be fixed.  However, this architecture is a best
   attempt at a logical model of Internet email, and insofar as new
   protocol development varies from this architecture, it is necessary
   for designers to understand those differences and explain them
   carefully.

1.3.  Document Conventions

   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 part 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 (RFC 5322) 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.

2.  Responsible Actor Roles

   Internet Mail is a highly distributed service, with a variety of
   Actors playing different roles.  These Actors fall into three basic
   types:

      *  User

      *  Message Handling Service (MHS)

      *  ADministrative Management Domain (ADMD)

Top      ToC       Page 8 
   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 diagrams of email architecture.

2.1.  User Actors

   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

      *  Recipients

      *  Return Handlers

      *  Mediators

   Figure 2 shows the primary and secondary flows of messages among
   them.  As a pragmatic heuristic: User Actors can generate, modify, or
   look at the whole message.

Top      ToC       Page 9 
           ++==========++
           ||  Author  ||<..................................<..
           ++=++=++=++=++                                     .
              || || ||     ++===========++                    .
              || || ++====>|| Recipient ||                    .
              || ||        ++=====+=====++                    .
              || ||               .                           .
              || ||               ..........................>.+
              || ||                                           .
              || ||               ...................         .
              || ||               .                 .         .
              || ||               V                 .         .
              || ||         +-----------+    ++=====+=====++  .
              || ++========>| Mediator  +===>|| Recipient ||  .
              ||            +-----+-----+    ++=====+=====++  .
              ||                  .                 .         .
              ||                  ..................+.......>.+
              ||                                              .
              ||    ..............+..................         .
              ||    .             .                 .         .
              \/    V             V                 '         .
           +-----------+    +-----------+    ++=====+=====++  .
           | Mediator  +===>| Mediator  +===>|| Recipient ||  .
           +-----+-----+    +-----+-----+    ++=====+=====++  .
                 .                .                 .         .
                 .................+.................+.......>..

          Legend: === lines indicate primary (possibly indirect)
                      transfers or roles
                  ... lines indicate supporting transfers or roles

                 Figure 2: Relationships among User Actors

   From a User's perspective, all message-transfer activities are
   performed by a monolithic Message 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 back to an Author or
   Originator in the sequence of handling a message, that Actor is a
   User.

2.1.1.  Author

   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 (Section 2.2.1) that correlates with the Author role.

Top      ToC       Page 10 
2.1.2.  Recipient

   The Recipient is a consumer of the delivered message.  The MHS has a
   Receiver role (Section 2.2.4) that correlates with the Recipient
   role.  This is labeled Recv in Figure 3.

   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 Section 4.1.)

2.1.3.  Return Handler

   Also called "Bounce Handler", the Return Handler is a special form of
   Recipient tasked with servicing notifications generated by the MHS as
   it transfers or delivers the message.  (See Figure 3.)  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.

2.1.4.  Mediator

   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 Section 5.

   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.

Top      ToC       Page 11 
   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
   Section 2.2.3.

2.2.  Message Handling Service (MHS) Actors

   The Message 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.  As a pragmatic heuristic MHS Actors generate,
   modify, or look at only transfer data, rather than the entire
   message.

   Figure 3 shows the relationships among transfer participants in
   Internet Mail.  Although it shows the Originator (labeled Origin) as
   distinct from the Author, and Receiver (labeled Recv) as distinct
   from Recipient, each pair of roles usually has the same Actor.
   Transfers typically entail one or more Relays.  However, direct
   delivery from the Originator to Receiver is possible.  Intra-
   organization mail services usually have only one Relay.

Top      ToC       Page 12 
           ++==========++                        ++===========++
           ||  Author  ||                        || Recipient ||
           ++====++====++   +--------+           ++===========++
                 ||         | Return |                  /\
                 ||         +-+------+                  ||
                 \/           .    ^                    ||
             +---------+      .    .                +---++---+
             |         |      .    .                |        |
          /--+---------+----------------------------+--------+----\
          |  |         |      .    .      MHS       |        |    |
          |  | Origin  +<......    .................+  Recv  |    |
          |  |         |           ^                |        |    |
          |  +---++----+           .                +--------+    |
          |      ||                .                    /\        |
          |      ||  ..............+..................  ||        |
          |      \/  .             .                 .  ||        |
          |  +-------+-+        +--+------+        +-+--++---+    |
          |  |  Relay  +=======>|  Relay  +=======>|  Relay  |    |
          |  +---------+        +----++---+        +---------+    |
          |                          ||                           |
          |                          ||                           |
          |                          \/                           |
          |                     +---------+                       |
          |                    | Gateway +-->...                  |
          |                     +---------+                       |
          \-------------------------------------------------------/

         Legend: === and || lines indicate primary (possibly
                     indirect) transfers or roles
                 ... lines indicate supporting transfers or roles

                 Figure 3: Relationships among MHS Actors

2.2.1.  Originator

   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 also represents the local operator of the MHS, that is, the
   local ADministrative Management Domain (ADMD).

Top      ToC       Page 13 
   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.

2.2.2.  Relay

   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 [RFC2505] 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 Message Handling System (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 Relays

      *  Packet 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 sends an error message to the Return Address.  The
   potential for looping is avoided by omitting a Return Address from
   this message.

2.2.3.  Gateway

   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.

Top      ToC       Page 14 
   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 multimedia.  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?

2.2.4.  Receiver

   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.

2.3.  Administrative Actors

   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

Top      ToC       Page 15 
   administrative and operational relationships.  Each is a distinct
   ADMD, potentially having a complex arrangement of functional
   components.  Figure 4 depicts relationships among ADMDs.  The benefit
   of the ADMD construct is that it facilitates 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 [Tussle].  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:

   Edge:       Independent transfer services in networks at the edge of
               the open Internet Mail service.

   Consumer:   Might be a type of Edge service, as is common for web-
               based email access.

   Transit:    Mail Service Providers (MSPs) 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 Section 2.2.2.

Top      ToC       Page 16 
         +--------+     +---------+     +-------+     +-----------+
         |  ADMD1 |<===>|  ADMD2  |<===>| ADMD3 |<===>|   ADMD4   |
         |  ----- |     |  -----  |     | ----- |     |   -----   |
         |        |     |         |     |       |     |           |
         | Author |     |         |     |       |     | Recipient |
         |   .    |     |         |     |       |     |     ^     |
         |   V    |     |         |     |       |     |     .     |
         |  Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer |
         |        |     |         |     |       |     |           |
         +--------+     +---------+     +-------+     +-----------+

         Legend: === lines indicate primary (possibly indirect)
                     transfers or roles
                 ... lines indicate supporting transfers or roles

              Figure 4: Administrative Domain (ADMD) Example

   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 [RFC5068].

   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.

Top      ToC       Page 17 
   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.



(page 17 continued on part 2)

Next RFC Part