Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5598

Internet Mail Architecture

Pages: 54
Part 3 of 3 – Pages 35 to 54
First   Prev   None

Top   ToC   RFC5598 - Page 35   prevText

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
Top   ToC   RFC5598 - Page 36
   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

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


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


         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:
Top   ToC   RFC5598 - Page 38
      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.
Top   ToC   RFC5598 - Page 39
      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.
Top   ToC   RFC5598 - Page 40
      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

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

         These fields usually contain the original list of Recipient

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

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.
Top   ToC   RFC5598 - Page 42
      RFC5321.MailFrom:  Set by - Author Originator or Mediator

         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].
Top   ToC   RFC5598 - Page 43
   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
Top   ToC   RFC5598 - Page 44
      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.
Top   ToC   RFC5598 - Page 45

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.
Top   ToC   RFC5598 - Page 46
   [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.

              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.
Top   ToC   RFC5598 - Page 47
   [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.
Top   ToC   RFC5598 - Page 48
   [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.
Top   ToC   RFC5598 - Page 49
   [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.
Top   ToC   RFC5598 - Page 50

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


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
Top   ToC   RFC5598 - Page 52
      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

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

      header  24
      hMSA  31

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

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

      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
Top   ToC   RFC5598 - Page 53
      MUA  4, 14, 24, 30-31

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

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

      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

      SIEVE  24-25
      SMTP  24, 35, 44

      transfer  11, 13-14
      Transit Actor  15
      transition  31

      UA  4
      User Agent  4
Top   ToC   RFC5598 - Page 54

Author's Address

Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA Phone: +1.408.246.8253 EMail: