<p><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;"><span style="color: #000000;">In this diagram, the sender is using their company account to send an email to someone at a different company.</span></span></span></p>
<p><span style="font-size: 10pt;"><span style="font-family: arial,helvetica,sans-serif;"><span style="color: #000000;"> </span></span></span></p>
<p style="text-align: center;"><span style="font-size: 10pt;"><span style="font-family: arial,helvetica,sans-serif;"><span style="color: #000000;"><br /><img src="images/stories/howemailworks.png" alt="howemailworks" height="453" width="596" /></span></span></span></p>
<div lang="en">
<div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;"><strong>Step A:</strong> Sender creates and sends an email</span></span></span></p>
</div>
</div>
<p lang="en"><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">The originating sender creates an email in their Mail User Agent (MUA) and clicks 'Send'. The MUA is the application the originating sender uses to compose and read email, such as Eudora, Outlook, etc.</span></span></span></p>
<div lang="en">
<div>
<div>
<div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;"><strong>Step B:</strong> Sender's MDA/MTA routes the email</span></span></span></p>
</div>
</div>
</div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">The sender's MUA transfers the email to a Mail Delivery Agent (MDA). Frequently, the sender's MTA also handles the responsibilities of an MDA. Several of the most common MTAs do this.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">The MDA/MTA accepts the email, then routes it to local mailboxes or forwards it if it isn't locally addressed.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">In our diagram, an MDA forwards the email to an MTA and it enters the first of a series of "network clouds," labeled as a "Company Network" cloud.</span></span></span></p>
</div>
<div lang="en">
<div>
<div>
<div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;"><strong>Step C:</strong> Network cloud</span></span></span></p>
</div>
</div>
</div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">An email can encounter a network cloud within a large company or ISP, or the largest network cloud in existence:the Internet. The network cloud may encompass a multitude of mail servers, DNS servers, routers, and other devices and services too numerous to mention. These are prone to be slow when processing an unusually heavy load, temporarily unable to receive an email when taken down for maintenance, and sometimes may not have identified themselves properly to the Internet through the Domain Name System (DNS) so that other MTAs in the network cloud are unable to deliver mail as addressed. These devices may be protected by firewalls, spam filters and malware detection software that may bounce or even delete an email. When an email is deleted by this kind of software, it tends to fail silently, so the sender is given no information about where or when the delivery failure occurred.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">Email service providers and other companies that process a large volume of email often have their own, private network clouds. These organizations commonly have multiple mail servers, and route all email through a central gateway server (i.e., mail hub) that redistributes mail to whichever MTA is available. Email on these secondary MTAs must usually wait for the primary MTA (i.e., the designated host for that domain) to become available, at which time the secondary mail server will transfer its messages to the primary MTA.</span></span></span></p>
</div>
<div lang="en">
<div>
<div>
<div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;"><strong>Step D:</strong> Email queue</span></span></span></p>
</div>
</div>
</div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">The email in the diagram is addressed to someone at another company, so it enters an email queue with other outgoing email messages. If there is a high volume of mail in the queue—either because there are many messages or the messages are unusually large, or both—the message will be delayed in the queue until the MTA processes the messages ahead of it.</span></span></span></p>
</div>
<div lang="en">
<div>
<div>
<div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;"><strong>Step E:</strong> MTA to MTA transfer</span></span></span></p>
</div>
</div>
</div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">When transferring an email, the sending MTA handles all aspects of mail delivery until the message has been either accepted or rejected by the receiving MTA.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">As the email clears the queue, it enters the Internet network cloud, where it is routed along a host-to-host chain of servers. Each MTA in the Internet network cloud needs to "stop and ask directions" from the Domain Name System (DNS) in order to identify the next MTA in the delivery chain. The exact route depends partly on server availability and mostly on which MTA can be found to accept email for the domain specified in the address. Most email takes a path that is dependent on server availability, so a pair of messages originating from the same host and addressed to the same receiving host could take different paths. These days, it's mostly spammers that specify any part of the path, deliberately routing their message through a series of relay servers in an attempt to obscure the true origin of the message.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">To find the recipient's IP address and mailbox, the MTA must drill down through the Domain Name System (DNS), which consists of a set of servers distributed across the Internet. Beginning with the root nameservers at the top-level domain (.tld), then domain nameservers that handle requests for domains within that .tld, and eventually to nameservers that know about the local domain.</span></span></span></p>
<div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;"><strong>DNS resolution and transfer process</strong></span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">There are 13 root servers serving the top-level domains (e.g., .org, .com, .edu, .gov, .net, etc.). These root servers refer requests for a given domain to the root name servers that handle requests for that tld. In practice, this step is seldom necessary.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">The MTA can bypass this step because it has already knows which domain name servers handle requests for these .tlds. It asks the appropriate DNS server which Mail Exchange (MX) servers have knowledge of the subdomain or local host in the email address. The DNS server responds with an MX record: a prioritized list of MX servers for this domain.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">An MX server is really an MTA wearing a different hat, just like a person who holds two jobs with different job titles (or three, if the MTA also handles the responsibilities of an MDA). To the DNS server, the server that accepts messages is an MX server. When is transferring messages, it is called an MTA.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">The MTA contacts the MX servers on the MX record in order of priority until it finds the designated host for that address domain.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">The sending MTA asks if the host accepts messages for the recipient's username at that domain (i.e., username@domain.tld) and transfers the message.</span></span></span></p>
</div>
</div>
<div lang="en">
<div>
<div>
<div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;"><strong>Step F: </strong>Firewalls, spam and virus filters</span></span></span></p>
</div>
</div>
</div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">The transfer process described in the last step is somewhat simplified. An email may be transferred to more than one MTA within a network cloud and is likely to be passed to at least one firewall before it reaches it's destination.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">An email encountering a firewall may be tested by spam and virus filters before it is allowed to pass inside the firewall. These filters test to see if the message qualifies as spam or malware. If the message contains malware, the file is usually quarantined and the sender is notified. If the message is identified as spam, it will probably be deleted without notifying the sender.</span></span></span></p>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">Spam is difficult to detect because it can assume so many different forms, so spam filters test on a broad set of criteria and tend to misclassify a significant number of messages as spam, particularly messages from mailing lists. When an email from a list or other automated source seems to have vanished somewhere in the network cloud, the culprit is usually a spam filter at the receiver's ISP or company. This explained in greater detail in Virus Scanning and Spam Blocking.</span></span></span></p>
</div>
<div lang="en">
<div>
<div>
<div>
<p><strong><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">Delivery</span></span></span></strong></p>
</div>
</div>
</div>
<p><span style="color: #000000;"><span style="font-size: 12pt;"><span style="font-family: arial,helvetica,sans-serif;">In the diagram, the email makes it past the hazards of the spam trap...er...filter, and is accepted for delivery by the receiver's MTA. The MTA calls a local MDA to deliver the mail to the correct mailbox, where it will sit until it is retrieved by the recipient's MUA.</span></span></span></p>
</div>
<meta content="text/html; charset=utf-8" />
<meta name="ProgId" content="PowerPoint.Slide" />
<meta name="Generator" content="Microsoft PowerPoint 11" />
<!--v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} p\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} v\:textbox {display:none;}-->