Netiquette IQ Blog Of 4/27/15 - How Email Works, A Great Article

================================================

LuxSci FYI Blog from LuxSci.com

by Erik Kangas, PhD, CEO

How Email Works This section describes the general mechanisms and paths taken by an email message on its route from sender to recipient. This should give you an overview of the different protocols (languages) involved, the different types of servers involved, and the distributed nature of email networks. The examples I present are representative of many common email solutions, but are by no means exhaustive. Sending an Email Message Sending an email message is like sending a postal letter. When sending a letter, you drop it off at your local post office. The local post office looks at the address and figures out which regional post office the letter should be forwarded to. Then, the regional post office looks at the address and figures out which local post office is closest to your recipient. Finally, the recipient’s local post office delivers your letter to its recipient. Computers are like “post offices”, and the “Simple Mail Transport Protocol” (SMTP) is the “procedure” which an “email post office” uses to figure out where to send the letter next (e.g. the “next hop”). Any program that sends an email message uses SMTP to deliver that message to the next “post office” for “relaying” it to its final destination. Most people send mail in one of two ways – with a web-based interface like Gmail, Outlook Web Access, or LuxSci WebMail, or with an “email client” program like Outlook, Thunderbird, iPhone Mail, Android, or Mac Mail. When you send a message with an email program on your personal computer (or your phone or tablet), you have to specify an “SMTP server” so that your email program knows where to send the message. This SMTP server is like your local post office. Your email program talks directly to the server using the computer protocol (language) known as SMTP. This is like dropping off a letter at the local post office. When you use WebMail, your personal computer uses an Internet connection to communicate with a web server. The “language” that the internet connection uses is HTTP – “HyperText Transfer Protocol”. When you send your message with WebMail, the web server itself takes care of contacting an SMTP server and delivering your message to it. Delivery of email from your SMTP Server to your recipient’s SMTP Server: When an SMTP Server receives an email message, it first checks if an account for the message recipient is configured on the server itself. If there is such an account, the server will drop the message in that person’s Inbox (or follow other more complex user-defined rules).  If there is no local account for that recipient, the server  must “relay” the email message to another SMTP server closer to the recipient. This is analogous to how your local post office forwards your letter to a regional post office unless it is for someone served by the post office itself.  (Post offices don’t actually work this way in general, but the concept is easily understood with this analogy.) This process is known as “SMTP relaying”. How does your SMTP Server know where to relay the message to? If the recipient’s email address is “bob@luxsci.net”, then the recipient’s domain name is “luxsci.net”. Part of the “DNS settings” for the recipient’s domain (these are the “mail exchange” or MX records for the domain; see also Understanding Domain Name Service (DNS)) includes a list of SMTP Servers that should be able to accept email for this recipient. Multiple servers can be listed and they can be ranked in terms of “priority”.  The highest priority SMTP Server listed is the recipient’s actual/main inbound SMTP Server; the others are “backup inbound SMTP Servers”. These backup servers may merely either queue email for later delivery to the recipient’s actual SMTP Server or may perform the same real-time delivery actions as the main SMTP server (e.g. they are there for redundancy). There are many scenarios that govern the path an email message may take from the sender’s to the recipient’s SMTP Server. Some of these include: The sender’s server successfully contacts the recipient’s server and sends the email message directly (black line in the figure). The sender’s server can not contact the recipient’s actual SMTP server (maybe the recipient’s server is busy, down, or has some other connection problem). In this case the sender’s server tries to contact and deliver the message to the recipient’s first backup server. The sender’s server can not contact the recipient’s actual SMTP server or its first backup server. In this case the sender’s server tries to contact and deliver the message the recipient’s second backup server. The sender’s server can not contact any of the recipient’s servers. In this case it will queue the message and try to send it later. It will keep retrying periodically for several days until it succeeds in sending or gives up. Any message delivered to the backup servers which queue email could go through the same process of trying to contact the recipient’s main SMTP Server, or higher priority backup servers.  Backup servers may also queue email for later sending or process the email themselves. (Note that a recipient may have zero or more backup servers, not necessarily two as in this example). Note: a sender’s and recipient’s email systems may have arbitrarily complex server configurations actually handling the delivery process … performing operations such as: backups, filtering, forwarding, queueing, etc. Any number of servers may be involved and and number of copies or backups of messages may be made. Once the email message arrives at the recipient’s SMTP Server and is finally delivered to the recipient’s email box, the recipient may pick up the message and read it whenever s/he chooses (as discussed below). Each server that receives your message adds its own “Received” stamp to the message headers. This stamp identifies what server received the message, at what time, and from what other server. This information allows the recipient to trace a message’s entire journey. The take away from this discussion so far is that: Most email servers communicate with each other using SMTP You never know how long it will take an email message to get from sender to recipient because you don’t know how busy the servers are, how much traffic there is on the Internet, what machines are down for maintenance, etc. Your messages may sit in queues on any number of servers for any amount of time. Some of these servers may belong to third parties (i.e. may not be under the purview of either the sender or the recipient, may be an external email filtering or archival organization, etc.). Your recipients can determine the Internet address and name of the computer from which you are sending your messages, even in the case of your email being spoofed by a spammer. (See: tracing the origins of an email address, and hiding it) Retrieving Email From an SMTP Server When you receive an email message it sits in a file (or database) in your email server. If you wish to view this email message you must access this content.  Any computer wishing to access your email must speak one of the languages the email Server does. With some exceptions (like MS Exchange and ActiveSync), there are really only main 2 languages that email servers understand (for email retrieval, as opposed to email sending, for which they use SMTP), one is called the “Internet Message Access Protocol” (IMAP) and one is called the “Post Office Protocol” (POP). (We will not discuss the details of these here, but you may be interested in Understanding Email Services for information about them.) As a recipient, you can generally retrieve your email by either using a web-based interface known as “WebMail”, or via an “email client” program, such as Microsoft Outlook or iPhone Mail, running on your personal computer or device. The email client programs will talk directly to your email server and speak IMAP, POP, or something similar. With WebMail, your computer will talk to a WebMail server using a web connection (speaking HTTP); the WebMail server will, in turn, talk to your email server using POP or IMAP or something similar (like a direct database connection). The Lack of Security in Email Email is inherently insecure. In the following sections, we will see just how insecure it is. At this stage, it is important to point out the insecurity in the email delivery pathway just discussed: ·         WebMail: If the connection to your WebMail server is “insecure” (i.e. the address is http:// and NOT https://), then all information including your username and password is not encrypted as it passes between the WebMail server and your computer. ·         SMTP: SMTP does not encrypt messages (unless the servers in question support SMTP TLS).  Communications between SMTP servers may send your messages in plain text for any eavesdropper to see. Additionally, if your email server requests that you send your username and password to “login” to the SMTP server in order to relay messages to other servers, then these may also sent in plain text, subject to eavesdropping. Finally, messages sent via SMTP include information about which computer they were sent from and what email program was used. This information, available to all recipients, may be a privacy concern. ·         POP and IMAP: The POP and IMAP protocols require that you send your username and password to login; these credentials are not encrypted (unless you are using an SSL-secured connection). So, your messages and credentials can be read by any eavesdropper listening to the flow of information between your personal computer and your email service provider’s computer. ·         BACKUPS: Email messages are generally stored on SMTP servers in plain, unencrypted text. Backups of the data on these servers may be made at any time and administrators can read any of the data on these machines. The email messages you send may be saved unexpectedly and indefinitely and may be read by unknown persons as a result. These are just a few of the security problems inherent in email. In the next section, we will talk about communications security problems in general so we can see what else can go wrong. Later on, we will see how these problems can be solved.

===================================================

Have you ever wondered how it would be if your email suddenly came to life? You are about to find out.
====================================================

https://www.youtube.com/watch?v=HTgYHHKs0Zw
===========================================================
**Important note** - contact our sister company for very powerful solutions for IP management (IPv4 and IPv6, security, firewall and APT solutions:

www.tabularosa.net

In addition to this blog, Netiquette IQ has a website with great assets which are being added to on a regular basis. I have authored the premiere book on Netiquette, “Netiquette IQ - A Comprehensive Guide to Improve, Enhance and Add Power to Your Email". My new book, “You’re Hired! Super Charge Your Email Skills in 60 Minutes. . . And Get That Job!” will be published soon follow by a trilogy of books on Netiquette for young people. You can view my profile, reviews of the book and content excerpts at:

 www.amazon.com/author/paulbabicki

 If you would like to listen to experts in all aspects of Netiquette and communication, try my radio show on BlogtalkRadio  Additionally, I provide content for an online newsletter via paper.li. I have also established Netiquette discussion groups with Linkedin and Yahoo.  I am also a member of the International Business Etiquette and Protocol Group and Minding Manners among others. Further, I regularly consult for the Gerson Lehrman Group, a worldwide network of subject matter experts and have been a contributor to numerous blogs and publications. 

Lastly, I am the founder and president of Tabula Rosa Systems, a company that provides “best of breed” products for network, security and system management and services. Tabula Rosa has a new blog and Twitter site which offers great IT product information for virtually anyone.

==============================================