1. Components of an Email System
No matter the specifics of
application and server, a handful of components and roles, shown in Figure 1, are involved in any email transmission:
Mail User Agent (MUA)
This is the component that
the user directly interacts with. If we were to use a postal metaphor,
the MUA is roughly the equivalent of your local mailbox at the end of
the driveway. Traditionally, the MUA has been a stand-alone client
application such as Outlook; however, a web-based client such as Outlook
Web App also offers MUA functionality, even though it is technically a
server-side application.
Mail Retrieval Agent (MRA)
The MRA, closely related to
the MUA, is the component that handles retrieving messages from the
main mail store. Depending on which protocols you are using, such as the
Post Office Protocol (POP) or Internet Mailbox Access Protocol (IMAP),
you can't just rely on new messages to be pushed to your MUA; something
needsto pull them down for you. Typically, the MRA is not a separate
component in modern systems, but a set of additional routines in the MUA
that supports message retrieval. In an Exchange 2010 system, this
functionality is supplied either by the Outlook client or by Outlook Web
App when configured to pull mail from an external account into the
mailbox. Outlook Web App leaves all mail on the server and merely serves
as an interface for reading or sending email, so nothing is really
being pulled off the server. Outlook can either manipulate mail directly
on the mail server or make a copy of the mail on to the local hard
drive of the client (in the case of Outlook, in local cache mode.)
Mail Transport Agent (MTA)
If the MUA is the
local mailbox, the mail transport agent (MTA) is the Post Office
infrastructure connecting different towns and cities with one another.
The MTA is responsible for accepting messages from other systems such as
MUAs and MTAs, routing them, and ensuring their delivery to their
recipients. Messages typically travel though two MTAs — the sender's and
the recipient's (unless, of course, they share an MTA). In an Exchange
2010 system, the Hub Transport and Edge Transport roles fill the MTA
role.
Mail Submission Agent (MSA)
Just as the MRA is a
variant role often performed by the MUA, the mail submission agent (MSA)
is a specialized form of the MTA. It's adapted to accept mail
submissions from the MUA, introduce them into the mail flow, and handle
any specialized processing that may be required. In Exchange 2010, this
function is handled both in the Client Access server role via messaging
application programming interfaces (MAPIs) and remote procedure calls
(RPCs) — when receiving messages from Outlook, Outlook Web Access,
Exchange Web Services, or mobile devices using Exchange ActiveSync — as
well as through SMTP via the client receive connector on the Hub
Transport role — when receiving messages from third-party clients.
Mail Delivery Agent (MDA)
What's missing from this
picture? In this case, it's the equivalent of the local Post Office (or,
if you prefer, the mailroom in the big corporation) — the mail delivery
agent (MDA) or local delivery agent (LDA). Once the incoming message
has been delivered to the proper collection of systems, the MDA/LDA is
responsible for ensuring it's been put into the correct mailbox. In an
Exchange system, this functionality is handled by a component of the Hub
Transport role as messages are passed to the various Mailbox roles.
Each
email system can use a wide variety of solutions to implement these
functions. Some applications, such as Exchange, incorporate all these
functions into a single end-to-end offering, whereas others provide just
one piece of the puzzle, relying on other applications to provide the
missing functionality. Even when using a complete solution, however, you
can always mix and match pieces to provide functionality (such as using
a third-party client for MUA functionality, or an edge mail appliance
as an MTA to other mail systems). To ensure that these implementations
work together, a series of standards have been developed over time.
2. Defining the Standards
When you have this many moving
parts in a system — especially when they can be created, implemented,
and configured by anyone — it helps if you define how the various parts
work together. Although trying to create a true central authority for
the Internet has proven to be a futile exercise, over the years the
Internet community has evolved a method for describing, proposing,
discussing, and documenting the various protocols that are in use across
the world: a document known as the request for comment (RFC).
RFCs began as informal
memos among members of the academic teams that invented and programmed
the hardware and software used to develop the Advanced Research Projects
Agency Network (ARPANET), which was an early predecessor of the
Internet. Whenever a team member wanted to suggest a new feature or
protocol to the rest of the team, they'd write up an RFC describing
their idea as a formal invitation for feedback. Over the years, as the
ARPANET grew into the core of the Internet, RFCs expanded in scope to
become more formal definitions and descriptions, sometimes retroactive.
Taken in total, the RFC
archives provide a fascinating history of the Internet, although not all
of the various technologies that have been used were documented through
RFCs. Many of these alternatives, such as the X.400 standard for
message handling systems, were much more complicated and harder to
implement than the systems described in the RFCs. In the end, the
commercially developed X.400 standard and accompanying X.500 directory
service protocols lost to SMTP, Lightweight Directory Access Protocol
(LDAP), and Domain Name System (DNS). The latter protocols were all
freely available in RFCs, allowing anyone with the time and interest to
develop their own implementations.
RFCs are not static; they
can contain errors or even just erroneous assumptions. As the world has
changed, older RFCs are often updated, modified, or even superseded by
newer RFCs. You can examine any of the RFCs online at www.rfc-editor.org.
As you read through the RFCs,
you will see many prescriptive statements. You may even find
configurations or software functions that are dictated (or forbidden)
but that your organization is using. Sometimes you will have good
reasons for a specific congiuration, but sometimes a non-standard
configuration may be set through ignorance. However, before you blindly
make the changes in order to be RFC compliant, you should remember the
ultimate rule: local policy trumps RFC.
For
example, one common spam-fighting mechanism is to check the DNS records
for remote SMTP servers that connect to your servers to see if the
reverse and forward DNS lookups match. If not, many systems choose to
regard that message source as a potential spam source and refuse to
accept messages from those systems. Strictly speaking, this behavior
violates RFCs. Practically, it can be a valuable spam-reduction
technique, depending on your traffic patterns and characteristic mail
partners. If the reason behind a particular recommendation doesn't meet
your needs, don't use it; if you don't know the reason, ask.
