All email headers contain the server and client information that controls the process of mail delivery. Many people...
who use email clients have probably heard of SMTP servers and POP3 servers. Within your email client you are asked to put in your email settings related to these servers, as shown in Figure 3.
Figure 3.3 Email Settings
Within the typical setup for email, two ports are typically used: port 25, and port 110. Port 25 is the Simple Mail Transfer Protocol (SMTP), and its job is to transmit and receive mail—basically what is called a Mail Transfer Agent, or MTA. An MTA is comparable to the mail carrier who picks up the mail and sends it off to where it needs to go. Just as the mail carrier drops off and picks up mail, so does the MTA. Port 110 is the Post Office Protocol, version 3 (POP3), and it is essentially the mailbox from which users pick up their mail up. This has an authentication process that allows users to log in and retrieve their email, which, in most cases, depending on your settings, is set to delete the mail from the server once you have completely retrieved it.
Raw SMTP Communication
A quick way to comprehend the operations of SMTP is to send an email using the Telnet protocol. Telnet is a communication protocol that allows you to connect to and communicate with a port in a terminal. In this case, we will Telnet to port 25 of mail.sendingemail.com:
me@unixshell~$ telnet mail.sendingemail.com 25 Trying 127.0.0.1... Connected to mail.sendingemail.com. Escape character is '^]'. 220 mail.sendingemail.com ESMTP
We have successfully established a session with the SMTP or ESMTP (Extended STMP) server, and it has given us a return code of 220. We can now send it commands. The commands typically used to send email are HELO, MAIL FROM, RCTP TO, DATA, and QUIT. Basically, five primary commands control the majority of the protocol.
To start, we have to identify ourselves by simply saying HELO:
220 mail.sendingemail.com ESMTP Postfix HELO sender.sendingemail.com 250 mail.sendingemail.com Hello sender.sendingemail.com [xx.7.239.24], pleased to meet you
As you can see, the server greeted us back and identified us by displaying our IP address. Technically, we could make up anything describing who we are; most SMTP servers will allow that because they know our IP, and it will mark our IP within the Received headers.
To send email after the meet and greet, we want to tell the mail server who the email is from and where it is going:
MAIL FROM: email@example.com 250 firstname.lastname@example.org... Sender ok RCPT TO: email@example.com 250 firstname.lastname@example.org… Recipient ok
This code states that the inputs we've entered are okay. In the real world, we would be rejected for the RCTP TO: from Telnet, since relaying to another network should be denied. But since we're on our own network and run our own mail server locally, this is allowed. Note that this is a quick and easy way to forge headers right at the MAIL FROM: and RCPT TO: fields. From our local network, we can put anything we want in both those fields and it will be accepted. This is one basis for some forgery; the other is the open relays, which we will get to shortly.
To send our message, we will use the DATA command:
DATA 354 Enter mail, end with "." On a line by itself Subject: Test Email
Here is my data that I would like to send to email@example.com. This is essentially the body of the message and we will close by skipping a line and entering "." -me
. 250 I6A2341RR Message accepted for delivery QUIT 221 mail.sendingemail.com closing connection
Note that the 250 return code revealed an ID for our message; this is the message ID we see in the headers on the way out. Once we tell the mail server QUIT, it will send our message. This is the internal protocol that SMTP works with. As you can see, it's simple and flexible, which is the exact reason the technology enables so many problems while also offering convenience.
The mail server infrastructure works in such an efficient fashion that we did not use only four servers but, at minimum, eight servers to deliver our email. In the process of sending email, we query multiple DNS servers to obtain information about where the mail servers are on the Internet.
Here is an example of the complete process for sending an email (see Figure 4):
Figure 4 Standard Email Infrastructure
- Create the email, specifying the From, To, Subject, and content.
- After you click Send, the mail client will access the DNS server of your ISP to locate your local mail server.
- The local mail server (mail.sendingemail.com in our example) receives your email and uses the local DNS to determine who sent it by doing a reverse IP lookup of Sender.
- After verification, the local mail server adds the headers and relays the mail to the mail.receivingemail.com mail server. To do this, mail.sendingemail.com has to look up what is called a mail exchange, or MX, record within DNS. This MX says, "Hello mail.sendingemail.com, mail.receivingemail.com is handling mail for receivingemail.com." Once that has been identified by our mail server, it can relay to the proper mail server.
- Once mail.receivingemail.com receives the email, it applies more header information, including routing data and receiving time; checks the DNS server for a reverse lookup regarding mail.sendingemail.com; and looks up the user you for the domain it is handling mail for.
- Client email user Receiver contacts mail.receivingemail.com (again, local DNS is used), makes a request to the POP3 port (110), and asks to retrieve its email. The email is delivered to the email client, and Receiver happily reads the email.
10 tips in 10 minutes: Phishing exposed
Tip 1: Email basics for Exchange admins
Tip 2: Understanding email delivery
Tip 3: Anonymous phishing email
Tip 4: How phishers forge email headers
Tip 5: Phishers use of open relays and proxy servers
Tip 6: How phishers send anonymous email
Tip 7: Phishers techniques for email harvesting
Tip 8: Phishers, hackers and insiders
Tip 9: Sending spam; phishing tools of the trade
Tip 10: Phishing email and spam filters
Dig Deeper on Email Protocols