Models for Mail Handling Systems                                     DRAFT 14-Aug-2010

Models and terminology are important in shaping our understanding of complex systems and guiding further development.  Internet mail has evolved to an extremely diverse and complex system.  Development of security protocols has been misguided by inadequate models that do not focus clearly on security issues, and may even divert attention from critical issues.

We need simple models, focused on the features of real email systems that are critical to security.  These models should describe the administrative-level (Actors, their roles, and their responsibilities). The terminology should be simple and unambiguous.

Textbook models, even in graduate-level texts [1] are too simple, showing only a sequence of "gateways" connected by SMTP/TCP, with no discussion of roles and responsibilities within the system.  Internet standards documents [2,3] provide complete details on specific protocols, but don't tell us much about real system architecture [4].

A recent noble effort to provide a comprehensive and accurate description covering all current systems [5] is a good starting point, but we need more.  Actors play a variety of roles, and detailing these roles in our models is central to our understanding of the security issues [6].

We can't do much better than [5] for a single, all-inclusive model, but we can provide a collection of simpler, more narrowly focused models that covers all systems of interest.  The value of these models should be judged by how well they describe real systems, enhance our understanding of security issues, and facilitate development of better systems.

See Forwarding for an example applying one of these models to a discussion of current proposals on enhancing the SPF authentication protocol.

[1] L. Peterson, B. Davie, "Computer Networks: A Systems Approach", 4th ed. 2007, Sect. 9.1.1 "Electronic Mail".

[2] J. Klensin, ed, "Simple Mail Transfer Protocol", RFC-2821, 2001, http://tools.ietf.org/html/rfc2821.

[3] P. Resnick, ed, "Internet Message Format", RFC-2822, 2001, http://tools.ietf.org/html/rfc2822.

[4] P. Faltstrom, mail-flows-0.4, Jan 6, 2004, http://www.ripe.net/ripe/meetings/ripe-47/mailflows.pdf

[5] D. Crocker, "Internet Mail Architecture", 2008, http://tools.ietf.org/html/draft-crocker-email-arch-10.

[6] K. Moore, "Recommendations for Submission of Email and Relaying of Email Between Mail Networks", 2005, http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html

Actors and Roles:
Actors include Users and Agents
Agents may play more than one role
Typical roles include Transmitting, Receiving, Forwarding, and Delivery.
A Border shows where there is no prior relationship between Agents.
--> Direction of mail flow (no statement as to relationship)
==> Direct relationship between Actors (e.g. a contract)
~~> Indirect relationship (e.g. both directly related to Recipient)
A/B Roles A and B both played by the same Actor

Simple Setup with four Actors:

|--- Sender's Network ---|           |-- Recipient's Network -|
                                /
Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient
                              /
                           Border
          
Simple Forwarding is quite common:

          |-------- Recipient's Network ---------|
     /
--> / --> Receiver/Forwarder ~~> MDA ==> Recipient
   /
 Border

Chain Forwarding should be discouraged:

          |------------ Recipient's Network ------------|
     /
--> / --> Receiver ~~> Forwarder(s) ~~> MDA ==> Recipient
   /
 Border

Open Forwarding must be banned:
         
     /                   /    |-- Recipient's Network -|
--> / --> Forwarder --> / --> Receiver/MDA ==> Recipient
   /                   /
 Border              Border


Roles and Responsibilities

Author
- Originate messages
- Provide a password or other means of authentication

MSA - Mail Submission Agent
- Authenticate the Author
- Manage Author accounts

Transmitter
- Spam Prevention
  - rate limits, content analysis, alerts
  - respond to spam reports
  - maintain reputation
- Authentication
  - RFC compliance
  - IP authorization (SPF, SID, CSV, ...)
  - signatures & key management (DKIM ...)
  - Return Address validation code
- Process SMTP Rejects

Receiver
- Block DoS
- Authenticate Sender
  - HELO, Return Address, Headers, Signature
  - reject forgeries
- Assess reputation
  - whitelists
- Filter spam
- Add authentication headers
- Manage Recipient accounts/options
  - whitelisting, blacklisting, filtering, blocking, forwarding
- Process spam reports, DSNs

Forwarder
- Authenticate upstream Agent
- Set up forwarding to downstream Agent
  - check RFC compliance
  - set up authentication records
  - submit forwarding request, wait for approval
- Manage Recipient accounts
  - maintain database of forwarding addresses
  - suspend account when a message is rejected
  - communicate w Recipient re  "      "
- Maintain reputation as a trusted Forwarder
  - certifications
- Process SMTP Rejects

MDA - Mail Delivery Agent
- Authenticate upstream Agent
- Sort and store messages
- Provide access for Recipients
  - POP3, IMAP, Webmail
- Manage Recipient accounts/options
- Relay spam reports to Receiver (or don't accept them)

Recipient
- Set up accounts with each Agent
- Select options in each account
- Report spam to Receiver

Mediator
- Receive - Process - Resend automatically
- Acts as an Agent, but
- Classified as a User for simplicity

Terminology
Our models use some new terms (Border, Transmitter) and also refine the definition of some others, while not contradicting their most common usage.  Thus, we make a distinction between "Forwarding" (with a capital F) and other kinds of relaying that some may call "forwarding".  Here a Forwarder is an Agent on the Recipient's side of the Border.  Forwarders re-write the Recipient's address, changing at least the domain name.
There are many "boundaries" between different Agents in an email system, but only one "Border", where there is no relationship between Agents.  Systems with more than one Border involve "open relays", and are generally banned.
We use the terms "Transmitter" and "Receiver" to mean the Agents at the Border.  The term "receiver" is sometimes used for Agents downstream from the Receiver, but we will avoid that usage entirely.
The term "sender" is a general term commonly used for the Author or Transmitter of a message.  We will use it only in contexts where there is no need to be more specific.
The term Transmitter is not generally used in discussions of email, and therefore not in conflict with other usage.  We use it because there is no generally accepted word to describe the sender's Agent at the Border.  The analogy to radio is helpful.
The terms MSA, MTA and MDA mean Mail Submission, Mail Transfer, and Mail Delivery Agents, although they are often used to label the machines or relays operated by these Agents.  Our models deal with Agents, but we will make it clear if we mean a specific relay, e.g.  "A Transmitter is identified by its domain name.  A transmitter usually has a more specific name, ending in a domain name."  Note the use of upper/lower case to highlight the difference.