Email is by far one of the oldest uses of the Internet. Developed by a team of researchers during the ARPANET days, it’s grown into world wide communication tool with almost every person on the net having their own email address.
The first ever email was sent by Ray Tomlinson in 1971, it was Ray who developed the system, and decided on using the now popular ‘@’ symbol to separate the account name with the domain name. I don’t think Ray knew quite what he had when email was first invented, but today… it’s something modern business can’t be without.
I won’t bother explaining the benefits of email, it speaks for itself, so on that note lets look at a brief overview of email, and then we’ll take a closer look at some of the more complex aspects.
Email is a client\server application. Meaning a client reads, writes and manages emails, while the server simply forwards them around the globe, and stores them while they wait for the client to log in and check new messages. Most people will be more familiar with the client side of things – there are many to choose from, the main ones being:
- Microsoft Outlook (or Outlook Express\Windows Mail)
- Yahoo! Web mail
- Hotmail Web mail
I’m going to focus on Outlook as despite being rather large, it does handle email quite simplistically, they all may differ in features, but essentially they all do the same thing. The two web mail clients are technically clients, but they are located within the same domain as the server, so it’s just less of a journey for the email to travel.
The Anatomy of an Email Address
When you create an email in Outlook, you need to address it to someone. This is one of five pieces of information Outlook will need before it can deliver the message, an email address is made up of two parts: (technically three but we’ll keep things simple).
I’m going to use an old email account that no longer functions, (the old Winview support email address from back in the Payne747.tripod.com days!), the first portion of the address is everything before
@ – this is the account name.
Secondly, the domain name is everything after the
@ (technically everything after the period is the third portion, the top level domain - but email doesn’t really make a distinction). Outlook already knows the parts of the address just by looking at it, however it’s all completely irreverent to Outlook, because Outlook is simply going to forward this email directly to your own outgoing mail server.
An outgoing mail server is a server usually owned by an ISP (though could be anyone) who manages your own email account. For example, let’s say a user at Yahoo! wants to send an email to Winview@soon.com. The Yahoo! user called Bill, owns the email address firstname.lastname@example.org (sorry whoever you are… though kudos on the email addy!), using Outlook, Bill writes and email addressed to Winview@soon.com, Outlook won’t perform any queries of it’s own, it will simply pass the email to Yahoo’s outgoing mail server, which happens to be smtp.mail.yahoo.com.
It’s from here on where the checks are performed. Yahoo! now has your email, and will perform some pretty basic checks.
First off, Yahoo! will want to know if the email actually did come from one of its users. Handling outgoing emails that your users did not create is very bad for business so this is an important step. Fortunately it’s very simple. Almost all email providers require a username and password to log into the outgoing mail server, it’s usually the same details you enter to retrieve your own emails, so Bill has already authenticated with Yahoo! when Outlook connected. The username and password Bill sent are two more of the five pieces of information needed.
Once Yahoo! is happy that the email did indeed come from its own user, it can begin to find out where to send it. Yahoo! then performs what’s known and an MX record query for the domain name (everything after the
@ in the email address), an MX record query is similar to a DNS query. Basically Yahoo! asks the Internet routers what servers are accepting emails for this domain, hopefully it should get a reply, but if the domain doesn’t exist, the MX record returns no results to Yahoo!, and Yahoo! knows it cannot send the email, so will reply to the sender (Bill) with a mail failure delivery, something along the lines of ‘Couldn’t find host named soon.com’.
However, in this case… soon.com does exist and the email should be transferable, You can actually see the result of the MX query Yahoo! or anyone else does by doing a query yourself, simply use
nslookup in Windows to give it a try:
At a Windows command prompt, enter
nslookup on it’s own with no parameters.
set query=mx and press Enter. Now you can enter the domain name of anyone you like and see where email should be forwarded to. The output of soon.com is as follows:
> soon.com Server: local_router.home Address: 192.168.1.1 Non-authoritative answer: soon.com MX preference = 10, mail exchanger = soon-com.mr.outblaze.com soon.com MX preference = 20, mail exchanger = soon-com-bk.mr.outblaze.com soon-com-bk.mr.outblaze.com internet address = 126.96.36.199 soon-com-bk.mr.outblaze.com internet address = 188.8.131.52 soon-com-bk.mr.outblaze.com internet address = 184.108.40.206 soon-com-bk.mr.outblaze.com internet address = 220.127.116.11 soon-com-bk.mr.outblaze.com internet address = 18.104.22.168 >
The results may be different every time as much larger email providers load balance across sometimes hundreds of IP addresses.
From now on it’s pretty simple. Yahoo! sends the message to the highest priority listed IP address on the MX record, if it does not respond; Yahoo! can just try the others until one finally accepts it. But what is it that is listening for messages? That would be the incoming mail server.
NoteThe IP’s listed in the MX records may not be the incoming mail server, they are designed to handle potentially millions of emails so there will usually always be more then one, the actual incoming mail server(s) will most likely only receive the emails once the devices listed in the MX records (usually referred to as email gateways) have confirmed the email isn’t spam and that the incoming mail server(s) are ready to process more mail.
For now let’s assume that Yahoo! sent the email towards soon.com using its MX records above, one of those devices has vetted the email and it’s been dropped into the incoming mail server for soon.com.
The final stage involves soon.com confirming it actually has a username matching the first half of the email address (everything before ‘@’), if there is no match, soon.com returns the email to Yahoo!, stating the user does not exist. It’s up to Yahoo! how they report this back to Bill (they kindly inform users), but either way, that’s it complete. If however Winview does exist on soon.com servers – the email is placed into a holding directory for that user, along with all the other new messages. As soon as I log into Outlook and click ‘Receive’, Outlook logs into soon.com using my username and password – which gives me access to my directory only, and Outlook downloads the emails for me. Viola!
Email is surprisingly that simple, below is a brief diagram showing the main steps in delivering an email. Unfortunately it’s that simplicity that allows it to be exploited so easily. Spam email is the vast majority of all email on the planet, and it’s due partly to some miss-configured systems, and partly due to the fact that separate email systems do not require authentication to forward emails on. Let’s take a look at a quick example of the first problem with miss-configured systems.
NoteOpen relay mail servers are hard to find now, the only ones you will find belong to spammers, and however all it takes is one innocently miss-configured server to pump out a few million emails. Nevertheless you really shouldn’t try this on random servers. I’ve changed the names so these examples won’t work.
Open relay servers were a big problem in the late 1990’s. They basically allow an SMTP server to send emails on to another domain that didn’t originate from its own domain. The relay server doesn’t care because it believes the sending domains SMTP server should be checking the authentication, so it doesn’t bother. As a result, almost all reputable email providers now will not accept email from other domains through its own SMTP server.
An example helps! We know that SMTP uses port 25, so we actually telnet to any SMTP mail server and issue SMTP commands (if you know them off the top of your head). Most of them will tell you to go away if you don’t provide a username\password – but miss-configured ones designed to allow relaying, will not check.
Here’s an example that used to work in the late 1990’s, allowing you to send emails portraying to be from anyone you want. First we connect to a server configured to use relaying:
Connected to dumbuni.net on port 25 HELO the-whitehouse.com Hello, please to meet you the-whitehouse.com RCPT TO: email@example.com Rcpt ok. MAIL FROM: firstname.lastname@example.org Sender ok. DATA Enter data and end with a period '.' Hello bush, it’s you! . Mail sent. Have a nice day Connection terminated.
Yes, mail servers do actually say ‘please to meet you’ to each other.
What’s happened here is that we establish a connection to
dumbuni.net on port 25 (SMTP). We then issue the HELO command to identify ourselves as
the-whitehouse.com. Next, we tell the server we want to send the email to
email@example.com using the RCPT TO command, because this is an SMTP server, it doesn’t need to check the recipient, only the sender, which we supply with the MAIL FROM command.
The MAIL FROM command should be ringing alarm bells for this server, because it knows it is actually
dumbuni.net and not
the-whitehouse.com – so why is it sending an email there? If this server were properly configured, we would have the following output:
RCPT TO: firstname.lastname@example.org Rcpt ok. MAIL FROM: email@example.com Sorry. That domain is not in my list of allowed hosts.
However relay servers assume the authentication has either already been done, or will be done at the other end. We know it won’t be, and the email will be forwarded using the fields we’ve provided. The result is the owner of firstname.lastname@example.org will receive an email from himself!
It’s actually very easy to set up your own email system, complete with your own domain name! What’s slightly harder is choosing a good bit of software to do it! All email servers need software which manages the user accounts, storage and processing of emails that pass through them, as well as services listening on ports 25 for outgoing SMTP emails and port 110 for POP (Post Office Protocol) email incoming. Funnily enough, the most popular and powerful email server out there is free but highly complex.
qmail is the choice of many high profile email providers. Yahoo and PayPal to name a couple.
qmail is only available for UNIX and UNIX like operating systems, making it yet even more desirable. There are Windows mail servers out there, but you usually have to pay for them. Microsoft Exchange Server is one of the more popular business servers because it interacts well with Active Directory, and most MCSE’s don’t know alternatives exists ;)
qmail is the older Sendmail – the original email software that exists on almost all UNIX and Linux boxes out there. Sendmail still has the ability to manage email, but it is rather outdated now, and
qmail was designed to address the issues Sendmail suffers from (particularly security).
If however you don’t want to go through the pain of compiling your own version of
qmail, and don’t want to give a spare lung for MS Exchange, then
Pegasus Mail may be a good choice. It’s a free mail server for Windows, works well and is user friendly. It might just be worth installing on a spare machine, setting up a dynamic DNS address for home and being your own mail administrator for a day.