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)
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.
++==========++
|| 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.
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.
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.
++==========++ ++===========++
|| 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).
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.
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 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.
+--------+ +---------+ +-------+ +-----------+
| 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.
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.