User:David MacQuigg/Sandbox/test

Table 1. Identities used in authenticating email

ID	Set By	Scope	Methods	Limitations	Deployment [1]
IPname	Network Owner	Entire Connection	FCrDNS	No relation to email	?
HELOname	Transmitter Agent	Entire email session	CSV		0%
Return Address	MSA Agent [2]	One message	SPF	Forwarding problem	12%
From Header	Author	One message	Sender ID	Forwarding problem	0.1% [3]
Digital Signature	MSA Agent	One message	DKIM	Replay problem	1.9%

System architecture

(CC) Image: David MacQuigg
Figure 1 Actors (Users and Agents) and their roles in an ideal email system.

Actors and Roles: Actors include Users and Agents. Agents may play more than one role. Typical roles include Transmitter, Receiver, and Delivery (MDA).

Figure 1 shows an ideal system with the machines grouped into functional blocks. In this diagram, we have named the blocks by their role in processing a message. The MSA role is played by a Mail Submission Agent, which performs all functions related to message submission. In this ideal system, we have assigned each role to a different actor (user or agent). In real systems, however, an actor can have multiple blocks, a block can have multiple machines, and a machine can host multiple relays running as independent daemon processes.

A small Internet Service Provider (ISP) might perform the roles of MSA/Transmitter using two relays running on one machine. An agent performing the role of Transmitter might have a dozen relays, operating in parallel to handle a large mailflow, or widely dispersed to serve users all over the world. A Mail Delivery Agent might have a process dedicated to managing a large mailstore, another running a POP/IMAP server, and another providing webmail via HTTP to the Recipient's browser.

There are many other possibilities. We might add a Forwarder between the Receiver and the MDA. We might add another layer of organization, showing contractual relationships between the agents. A diagram like Figure 1 could get quite complex. A shorthand notation will allow us to show the relevant networks, actors, roles, and relationships. Here is a basic system with four actors (two users and two agents), organized as two networks:

|--- Sender's Network ---|           |-- Recipient's Network -|
                                /
Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient
                              /
                           Border

To understand a mail handling system, including its security vulnerabilities, we need to focus on the roles and responsibilities of each actor and the relationships between them. The double arrow shows a direct relationship between actors (e.g. a contract between the Author and his ISP). The single arrow shows only the direction of mail flow. There is no relationship between agents across the Border to the open Internet. The / shows multiple roles being played by one actor. Using these diagrams, we can model almost any system, and include a lot of detail on relationships, but not lose the simplicity of Figure 1. The elements of the model (actors' roles) are the fundamental building blocks. See Email agents for more example systems.

Here is an extension of the basic system, adding a Forwarder role, played by the same actor as the Receiver. Both the Receiver/Forwarder and the MDA have a direct relationship with the Recipient, so they have an indirect relationship (wavy arrow) with each other. These details are important in discussions of authentication protocols.

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

If we wonder why email continues to be such an insecure system, we can study this last example. An MDA is quite frequently a Receiver/MDA that is unaware when an incoming message has been forwarded. If the MDA runs the most common authentication checks on the incoming message, it may be rejected as a forgery. The problem is that the Transmitter's domain name no longer correlates with the IP address seen on the incoming connection from the Forwarder.

This is a good example of how difficult it is for security protocols to keep up with evolving system designs and changing environments. Forwarding is much more prevalent now than when the most common email authentication protocols were designed. We can no longer dismiss Forwarding as just an "edge case". It is important for a user who changes jobs or ISPs, and would like to continue receiving mail at her old address.

When a homeopath is conducting an interview to characterise a patient's syndrome of symptoms, some "categories of change" are identified as important: (1) emotion (2) mentation (18) creativity (19) recall of past experiences

Table 1 shows some acronyms commonly used in discussions of email systems. Four of these (MUA, MSA, MTA, and MDA) may be a bit confusing. The confusion arises over the word agent, which is used to mean a process, a program, or a machine, rather than an individual or organization. The use of plain English words like actor and agent to mean something else is common in computer science. This distortion of meaning occurs naturally, as specialists try to be concise in their communications. Instead of saying "MSA process", meaning the process that performs the functions of an agent that handles mail submission, it was easier to just use MSA as an acronym. It works as long as the context is clear.

Table 1

Term	Definition
MUA	Mail User Agent; a program such as Mozilla Thunderbird, Microsoft Outlook or MUTT that can be used by an Author to compose and send, or by a Recipient to retrieve and read email messages. An MUA can also be a process, such as found in many web browsers or mobile phones.
MSA	Message Submission Agent; a machine, program or process that receives messages directly from an MUA, and performs the functions of an Agent responsible for mail submission.
MTA	Message Transfer Agent; a Relay; a machine, program or process that receives and stores a message, performs some administrative function, and forwards it to the next Relay or Mailstore.
MDA	Message Delivery Agent; the server that accepts mail for a user from a remote MTA and holds it until the user's mail client (their MUA) downloads the message
DSN	Delivery Status Notification (aka Bounce); A message generated by any process handling a message in transit, and sent to the Return Address. DSNs are typically sent when a permanent failure occurs in transit.
MDN	Message Disposition Notification (aka Return Receipt); A message generated by the recipient's MUA, providing information on post-delivery handling, such as notice that the message has been displayed.
SMTP	Simple Mail Transfer Protocol; the protocol used to transfer mail from one mail system to another. Uses port 25 or 587 for unencrypted message transfer.
POP	Post Office Protocol; A protocol where a client connects, downloads mail from the server and then deletes that mail from the server. Mail that is downloaded then "sticks" on the computer the user retrieves their mail from. Contrast with IMAP.
IMAP	Internet Message Access Protocol; IMAP differs from POP in that messages are left on the server; this allows a user to "float" between different clients at different locations but still have access to all their mail.
ADMD	Administrative Management Domain; An individual or organization (user or agent) having operational independence in an email system.

Table 1 shows some acronyms commonly used in discussions of email systems. Four of these (MUA, MSA, MTA, and MDA) may be a bit confusing. The confusion arises over the word agent, which is used to mean a process, a program, or a machine, rather than an individual or organization. The use of plain English words like actor and agent to mean something else is common in computer science. This distortion of meaning occurs naturally, as specialists try to be concise in their communications. Instead of saying "MSA process", meaning the process that performs the functions of an agent that handles mail submission, it was easier to just use MSA as an acronym. It works as long as the context is clear.

In these articles, we talk about the whole spectrum of "agents", from organizations and individuals to programs and processes, so we can't just use the common jargon without clarification. We also need to make distinctions based on function, like transmitter vs receiver, instead of just calling every relay an MTA.

Figure 2 is the same as Figure 1, but with the processes labeled using the acronyms in Table 1.

Figure 2 Machines, processes and protocols in an ideal email system.

Table 1 shows some acronyms commonly used in discussions of email systems. Four of these (MUA, MSA, MTA, and MDA) may be a bit confusing. The confusion arises over the word agent, which is used to mean a process, a program, or a machine, rather than an individual or organization. The use of plain English words like actor and agent to mean something else is common in computer science. This distortion of meaning occurs naturally, as specialists try to be concise in their communications. Instead of saying "MSA process", meaning the process that performs the functions of an agent that handles mail submission, it was easier to just use MSA as an acronym. It works as long as the context is clear.

Table 1 shows some acronyms commonly used in discussions of email systems. Four of these (MUA, MSA, MTA, and MDA) may be a bit confusing. The confusion arises over the word agent, which is used to mean a process, a program, or a machine, rather than an individual or organization. The use of plain English words like actor and agent to mean something else is common in computer science. This distortion of meaning occurs naturally, as specialists try to be concise in their communications. Instead of saying "MSA process", meaning the process that performs the functions of an agent that handles mail submission, it was easier to just use MSA as an acronym. It works as long as the context is clear.