Note: this is a re-publishing of a post I had on my blog back in 2007.  Lately I’ve been getting quite a few questions regarding this topic, so I decided it would be good to bring this material back to the forefront.

Every once in a while, I get asked the following question: “I just got an email that says I tried to send an email message to someone I’ve never heard of and it bounced back. Why?” Or it goes something like this: “I got a message that says I tried to send a virus to someone and the email was rejected. How is that possible?” Well, the answer is a little technical, but I’m going to show you how this happened.

The short answer is that someone created a fake email that shows you as the sender. The reasons for doing this are usually related to adware, spyware, or viruses. Basically, they’re trying to install a piece of software onto as many systems as possible without the users knowing about it. The end result can range from something that’s just plain annoying to stealing the contents of your bank account and you can bet someone is getting paid to do it. By naming another valid email account as the sender, they raise the potential to get their virus/adware/spyware installed onto at least one computer. If the recieving email account exists and there isn’t any antivirus software scanning the email, it might get installed on that user’s computer, if the reciever opens the message along with any attachments that are inside it. If the message bounces back to the email account named as the sender, the person named as the sender would naturally be confused by a message he or she didn’t send. Consequently, they investigate the content of the original message and wind up unintentionally installing the nastyware on their computer instead. It’s a win-win situation for the person who’s trying to infect as many machines as possible even though it leads to confusion for the recipients.

That leads us to the question of how it’s possible to create a message and name a false To: and From: address. To start, the malicious user connects to a SMTP server somewhere on the internet and issues the necessary commands to send a message with your email address in the From: field. This is possible because most SMTP servers do not require the user to authenticate themselves before issuing the necessary commands to send an email. Therefore, any anonymous user on the internet can send an email that pretends to come from anyone else in the world! This problem was introduced with RFC821 in the early days of email. If you go ahead and read that document, it will tell you how to manually send an email, but it’s rather long and complicated. Here’s an example of how to open a connection to a mail server, create a fake message, and get the mail server to deliver it: (Note that the ‘>’ characters have been added here to mark where I manually entered commands to the SMTP server. In reality, those characters don’t actually appear on the screen. Names of servers and email addresses have been changed to protect private information and I emphasize that this is only an example – not a real message I may have tried to send):

C:\> telnet smtp.somedomain.com 25

220 smtp.somedomain.com ESMTP Server (Microsoft Exchange Internet Mail S
ervice 5.5.2657.72) ready
> HELO nastyware.com
250 OK
> MAIL FROM: John.Smith@redmail.com
250 OK - mail from <John.Smith@redmail.com>

> RCPT TO: Joe.Johnson@bluemail.com
250 OK - Recipient <Joe.Johnson@bluemail.com>
> DATA
354 Send data.  End with CRLF.CRLF
Subject: Your password has been updated.
Date: September 10, 2005
From: support@somebank.com
To: Joe.Johnson@bluemail.com

Your password was recently updated in our system.  If you did not change your 
password, please use the link below to notify us that someone has illegally 
accessed your banking information.  Thank you.

http://www.S0mebank.com/support/unauthorized_access.asp
.
250 OK
> QUIT
221 closing connection

Connection to host lost.

C:\>

As you can see from the above example, I lied about who I am and why the message was being sent. Furthermore, I named John.Smith@redmail.com as the sender, but the actual body of the email indicates that email was sent by support@somebank.com. This is so the person who eventually recieves this email will think their bank is trying to alert them to some kind of unauthorized access. If this message bounces because the recipient’s email isn’t real or because their spam filter rejects it, John.Smith@redmail.com will recieve the message instead. It won’t bounce back to the support@somebank.com address because the addresses in the body of the message aren’t used for delivering the message. Those addresses are only used by mail client software such as Outlook, Netscape, or Thunderbird for replying to the messages after they are delivered. Digging a little deeper, you’ll also notice that the url at the bottom of the message body has a zero where there should be an ‘o’ so that when the user clicks on the link, they will be directed to a website that looks like the website of their bank. The reality is that the website is most likely run by the person who forged the email and is designed to lure the recipient into revealing their account information such as an account number and password.

Unfortunately, RFC821 allowed this sort of abuse and had no protections in place to prevent it. There were no provisions in the specification that would require end-users to provide any proof of their identity before an email message would be accepted for delivery. Furthermore, most implementations of the protocol didn’t check to see that the addresses given in the MAIL FROM: and RCPT TO: portions of the protocol matched those addresses given later on in the body of the message – the From:, To:, and Reply-To: lines. Consequently, it was very easy to create a message like the one above and nearly every mail server on the internet would happily accept the message for delivery.

Fortunately, many email providers today are starting to require that users authenticate to the server before the server will accept an email message for delivery. In addition to that, some mail servers have restrictions in place to help verify the email addresses specified on the MAIL FROM: line match those used in the body of the message. Another methon being adopted is to have the mail server verify that the MAIL FROM: address belongs to a valid account.

However, even with those restrictions in place, you will still get the occasional fake message because most mail servers don’t have a reliable way of verifying the authenticity of a message when it gets passed from one mail server to the next. The typical example is where Joe sends an email to John. The message goes to bluemail.com’s email server for routing and delivery. That server then passes the message to redmail.com’s mail server for delivery to the end user. Redmail.com’s mail server doesn’t have any way to verify that Joe.Johnson@bluemail.com is a real mailbox. It can’t because only bluemail.com’s servers know what addresses are registered in the system. As a result, redmail.com’s servers accept the message for delivery.

Thankfully, this situation is slowly changing and the holes in the system are being plugged. Unfortunately, until all of the insecurities in the system are eradicated, you’ll still get fake emails and there isn’t much that can be done about it in the short term. In closing, if you avoid opening attachments and refuse to just click on the links you recieve in your email, you will be much better protected from these kinds of problems.

Disclaimer: The above is an example of a malicious message and is not intended to represent an actual email that may have been sent or recieved. The information given is a result of a real email message, but the content has been changed significantly to illustrate the themes mentioned in this posting.