5.  Mediators

   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:

      RFC5321.HELO/.EHLO:  Set by - Mediator Originator

      RFC3461.ENVID:  Set by - Mediator Originator

      RFC5321.RcptTo:  Set by - Mediator Author

      RFC5321.Received:  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 Section 4.2.1.

      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.

5.1.  Alias

   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.

   NOTE:   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:

      RFC5322.To/.CC/.BCC:  Set by - Author

         These fields retain their original addresses.

      RFC5321.MailFrom:  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.

5.2.  ReSender

   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:

      RFC5322.From:  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 an informal reference
         to the ReSender.

      RFC5322.Reply-To:  Set by - original Author

         If this field is present in the original message, it is
         retained in the resent message.

      RFC5322.Sender:  Set by - Author's Originator or Mediator
         Originator

      RFC5322.To/.CC/.BCC:  Set by - original Author

         These fields specify the original message Recipients.

      RFC5322.Resent-From:   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.

      RFC5322.Resent-Sender:  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.

      RFC5322.Resent-To/-CC/-BCC:  Set by - Mediator Author

         The addresses of the new Recipients who are now able to reply
         to the original Author.

      RFC5321.MailFrom:  Set by - Mediator Originator

         The Actor responsible for resubmission (RFC5322.Resent-Sender)
         is also responsible for specifying the new MailFrom address.

5.3.  Mailing Lists

   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:

      RFC2919.List-Id:  Set by - Mediator Author

      RFC2369.List-*:  Set by - Mediator Author

      RFC5322.From:  Set by - original Author

         Names and email addresses for the original Author of the
         message content are retained.

      RFC5322.Reply-To:  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.

      RFC5322.Sender:  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.)

      RFC5322.To/.CC:  Set by - original Author

         These fields usually contain the original list of Recipient
         addresses.

      RFC5321.MailFrom:  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
         reuse 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.

5.4.  Gateways

   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 [RFC4143], voicemail [RFC3801], and the Multimedia
   Messaging Service (MMS) [RFC4356].

   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:

      RFC5322.From:  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.

      RFC5322.Reply-To:  Set by - original Author

         It is best for a Gateway to retain this information, if it is
         present.  The ability to perform a successful reply by a
         Recipient is a typical test of Gateway functionality.

      RFC5322.Sender:  Set by - Author Originator or Mediator Originator

         This field can retain the original value or can be set to a new
         address.

      RFC5322.To/.CC/.BCC:  Set by - original Recipient

         These fields usually retain their original addresses.

      RFC5321.MailFrom:  Set by - Author Originator or Mediator
         Originator

         The Actor responsible for handling the message can specify a
         new address to receive handling notices.

5.5.  Boundary Filter

   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.

6.  Considerations

6.1.  Security Considerations

   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 [RFC3207], SMTP-Auth [RFC4954], OpenPGP
   [RFC4880], and S/MIME [RFC3851].

   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 [RFC5321] and Section 5 of [RFC5322].  Transport of text or non-
   text content in this architecture has security considerations that
   are discussed in [RFC5322], [RFC2045], [RFC2046], and [RFC4288];
   also, security considerations are present for some of the media types
   registered with IANA.

   Agents that automatically respond to email raise significant security
   considerations, as discussed in [RFC3834].  Gateway behaviors affect
   end-to-end security services, as discussed in [RFC2480].  Security
   considerations for boundary filters are discussed in [RFC5228].

   See Section 7.1 of [RFC5321] for a discussion of the topic of
   origination validation.  As mentioned in Section 4.1.4, it is common
   practice for components of this architecture to use the
   RFC0791.SourceAddr to make policy decisions [RFC2505], although the
   address can be "spoofed".  It is possible to use it without
   authorization.  SMTP and Submission authentication ([RFC4409],
   [RFC4954]) 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 [RFC2505],
   is a by-product of this architecture.  A number of Standards Track or
   BCP documents on the subject have been issued (see [RFC2505],
   [RFC5068], and [RFC5235]).

6.2.  Internationalization

   The core Internet email standards are based on the use of US-ASCII --
   that is, SMTP [RFC5321] and IMF [RFC5322], as well as their
   predecessors.  They describe the transport and composition of
   messages as 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:

   o  The MIME specifications ([RFC2045], [RFC2046], [RFC2047],
      [RFC2049]) allow for the use of coded character sets and
      character-encoding schemes ("charsets" in MIME terminology) other
      than US-ASCII.  MIME's [RFC2046] allows the textual content of a
      message to have a label affixed that specifies the charset used in
      that content.  Equally, MIME's [RFC2047] 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 [RFC2045] also provides for "content transfer
      encoding" so that characters of other charsets can be re-encoded
      as an overlay to US-ASCII.

   o  MIME's [RFC2045] 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 [RFC1652] that permits the transport of such textual

      content.  However, the [RFC1652] option does not address the use
      of 8-bit content in message header fields, and therefore [RFC2047]
      encoding is still required for those.

   o  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.
      [RFC5335] specifies the format of such message header fields
      (which encode the characters in UTF-8), and [RFC5336] specifies an
      SMTP option for the transport of these messages.

   o  MIME's [RFC2045] and [RFC2046] allow for the transport of true
      multimedia material; such material enables internationalization
      because it is not restricted to any particular language or locale.

   o  The formats for Delivery Status Notifications (DSNs -- [RFC3462],
      [RFC3463], [RFC3464]) and Message Disposition Notifications (MDNs
      -- [RFC3798]) include both a structured and unstructured
      representation of the notification.  In the event that the
      unstructured representation is in the wrong language or is
      otherwise unsuitable for use, this allows an MUA to construct its
      own appropriately localized representation of notification for
      display to the User.

   o  POP and IMAP have no difficulties with handling MIME messages,
      including ones containing 8bit, and therefore are not a source of
      internationalization issues.

   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.

7.  References

7.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Five: Conformance Criteria and
              Examples", RFC 2049, November 1996.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2369]  Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
              for Core Mail List Commands and their Transport through
              Message Header Fields", RFC 2369, July 1998.

   [RFC2645]  Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with
              Dynamic IP Addresses", RFC 2645, August 1999.

   [RFC2919]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
              and Namespace for the Identification of Mailing Lists",
              RFC 2919, March 2001.

   [RFC3192]  Allocchio, C., "Minimal FAX address format in Internet
              Mail", RFC 3192, October 2001.

   [RFC3297]  Klyne, G., Iwazaki, R., and D. Crocker, "Content
              Negotiation for Messaging Services based on Email",
              RFC 3297, July 2002.

   [RFC3458]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
              Context for Internet Mail", RFC 3458, January 2003.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [RFC3462]  Vaudreuil, G., "The Multipart/Report Content Type for the
              Reporting of Mail System Administrative Messages",
              RFC 3462, January 2003.

   [RFC3463]  Vaudreuil, G., "Enhanced Mail System Status Codes",
              RFC 3463, January 2003.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC3798]  Hansen, T. and G. Vaudreuil, "Message Disposition
              Notification", RFC 3798, May 2004.

   [RFC3834]  Moore, K., "Recommendations for Automatic Responses to
              Electronic Mail", RFC 3834, August 2004.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC4021]  Klyne, G. and J. Palme, "Registration of Mail and MIME
              Header Fields", RFC 4021, March 2005.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC4289]  Freed, N. and J. Klensin, "Multipurpose Internet Mail
              Extensions (MIME) Part Four: Registration Procedures",
              BCP 13, RFC 4289, December 2005.

   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              RFC 4409, April 2006.

   [RFC4550]  Maes, S. and A. Melnikov, "Internet Email to Support
              Diverse Service Environments (Lemonade) Profile",
              RFC 4550, June 2006.

   [RFC5228]  Guenther, P. and T. Showalter, "Sieve: An Email Filtering
              Language", RFC 5228, January 2008.

   [RFC5248]  Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
              Mail System Status Codes", BCP 138, RFC 5248, June 2008.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

7.2.  Informative References

   [RFC0733]  Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
              "Standard for the format of ARPA network text messages",
              RFC 733, November 1977.

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
              RFC 821, August 1982.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC1506]  Houttuin, J., "A Tutorial on Gatewaying between X.400 and
              Internet Mail", RFC 1506, August 1993.

   [RFC1652]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
              RFC 1652, July 1994.

   [RFC1733]  Crispin, M., "Distributed Electronic Mail Models in
              IMAP4", RFC 1733, December 1994.

   [RFC1767]  Crocker, D., "MIME Encapsulation of EDI Objects",
              RFC 1767, March 1995.

   [RFC1985]  De Winter, J., "SMTP Service Extension for Remote Message
              Queue Starting", RFC 1985, August 1996.

   [RFC2033]  Myers, J., "Local Mail Transfer Protocol", RFC 2033,
              October 1996.

   [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
              FUNCTIONS", RFC 2142, May 1997.

   [RFC2442]  Freed, N., Newman, D., and Hoy, M., "The Batch SMTP Media
              Type", RFC 2442, November 1998.

   [RFC2480]  Freed, N., "Gateways and MIME Security Multiparts",
              RFC 2480, January 1999.

   [RFC2505]  Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
              BCP 30, RFC 2505, February 1999.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              January 2003.

   [RFC3801]  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
              Mail - version 2 (VPIMv2)", RFC 3801, June 2004.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC3885]  Allman, E. and T. Hansen, "SMTP Service Extension for
              Message Tracking", RFC 3885, September 2004.

   [RFC4142]  Crocker, D. and G. Klyne, "Full-mode Fax Profile for
              Internet Mail (FFPIM)", RFC 4142, November 2005.

   [RFC4143]  Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail
              (IFAX) Service of ENUM", RFC 4143, November 2005.

   [RFC4356]  Gellens, R., "Mapping Between the Multimedia Messaging
              Service (MMS) and Internet Mail", RFC 4356, January 2006.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [RFC4954]  Siemborski, R. and A. Melnikov, "SMTP Service Extension
              for Authentication", RFC 4954, July 2007.

   [RFC5068]  Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
              Finch, "Email Submission Operations: Access and
              Accountability Requirements", BCP 134, RFC 5068,
              November 2007.

   [RFC5235]  Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
              Extensions", RFC 5235, January 2008.

   [RFC5335]  Abel, Y., "Internationalized Email Headers", RFC 5335,
              September 2008.

   [RFC5336]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
              Email Addresses", RFC 5336, September 2008.

   [Tussle]   Clark, D., Wroclawski, J., Sollins, K., and R. Braden,
              "Tussle in Cyberspace: Defining Tomorrow's Internet",
              ACM SIGCOMM, 2002.

Appendix A.  Acknowledgments

   This work began in 2004 and has evolved through numerous rounds of
   community review; it derives from a section in an early version of
   [RFC5068].  Over its 5 years of development, the document has gone
   through 14 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 in IMAP and Sieve
   specifications and in 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, Greg
   Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, and Hans
   Lachman.

   Diligent early proof-reading was performed by Bruce Lilly.  Diligent
   professional 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.

Index

   7
      7-bit  44

   A
      accountability  12
      accountable  13-14
      Actor
         Administrative  14
         Author  10
         Consumer  15
         Edge  15
         Gateway  13
         Originator  12
         Recipient  10
         Return Handler  10
         Transit  15
      actor  7, 19, 26, 28-29, 35-36, 38-40, 42-43, 49
      Actors
         MHS  11
      addr-spec  17
      address
         addr-spec  17
         local-part  18
      ADMD  12, 14-15, 19, 25, 31, 37
      Administrative Actors  14
      Administrative Management Domain  12
      aMSA  31
      Author  10-11
      author  35

   B
      body parts  24
      bounce handler  10
      boundary  15

   C
      charset  44
      Consumer Actor  15
      content  11, 13-14, 20, 24, 32

   D
      delivery  4, 10-11, 13-14, 18, 24-25, 35, 37-38
      Discussion of document  7
      domain name  17, 21, 28
      DSN  44

   E
      EAI  44
      Edge Actor  15
      encoding  44
      end-to-end  4-6, 11, 15, 28

      envelope  10, 13, 21, 24-25, 32, 37
      ETRN  35

   G
      Gateway  11, 13
      gateway  6, 12-13, 18, 25, 32

   H
      header  24
      hMSA  31

   I
      identifier  18-19, 21, 25, 29
      IMAP  24, 31, 34-35, 44
      IMF  19, 24, 44
      Internet Mail  4

   L
      left-hand side  18
      LMTP  24, 35
      local-part  18

   M
      Mail  4
      Mail From  37
      Mail Submission Agent  12
      mailbox  17, 19, 24, 28, 30, 33, 37-38
      MDA  24, 37
      MDN  10, 24, 44
      message  6, 24
      Message Disposition Notification  10
      Message Handling Service  4
      Message Handling System  11
      Message Transfer Agent  4
      Message User Agent  4
      MHS  4, 10-13, 21-22, 24-25
         Actors  11
      MIME  24, 44
      MS  24
      MSA  12, 24, 31
      MTA  4, 15
         boundary  15

      MUA  4, 14, 24, 30-31

   O
      ODMR  35
      operations  3, 15, 18, 29, 40
      Originator  10-12

   P
      POP  24, 31, 34-35, 44
      posting  4, 10, 12, 21, 30-31, 35, 37
      pull  35
      push  35

   R
      RcptTo  11
      Receiver  11
      Recipient  10-11, 37
      recipient  35
      relay  11
      responsibility  31
      responsible  13-14
      Return Address  37
      Return Handler  10
      role  10, 18
         Author  10
         Originator  12
         Recipient  10

   S
      SIEVE  24-25
      SMTP  24, 35, 44

   T
      transfer  11, 13-14
      Transit Actor  15
      transition  31

   U
      UA  4
      User Agent  4

Author's Address

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086
   USA

   Phone: +1.408.246.8253
   EMail: dcrocker@bbiw.net