Most of us know spam when we see it, but seeing a strange email from a friend—or worse, from ourselves—in our inbox is pretty disconcerting. If you've seen an email that looks like it's from a friend, it doesn't mean they've been hacked. Spammers spoof those addresses all the time, and it's not hard to do. Here's how they do it, and how you can protect yourself.
Spammers have been spoofing email addresses for a long time. Years ago, they used to get contact lists from malware-infected PCs. Today's data thieves choose their targets carefully, and phish them with messages that look like they came from friends, trustworthy sources, or even their own account.
It turns out that spoofing real email addresses is surprisingly easy, and part of why phishing is such a problem. Systems Engineer, aspiring CISSP, and Lifehacker reader Matthew tipped us off to how it works, but also took us by surprise by emailing a few of us at Lifehacker from other Lifehacker writers' email addresses. Despite the fact that we knew it was possible—we’ve all gotten spam before—it was more disconcerting to actually be tricked by it. So, we talked to him about how he did it and what people can do to protect themselves.
Note: What follows is a rather technical writeup, designed for more computer-savvy individuals. If you want a more basic rundown on avoiding spam and scams, we've got one of those too.
A Little History: Why Email Addresses Are So Easily Spoofed
Today, most email providers have the spam problem resolved—at least to their own satisfaction. Gmail and Outlook have strong, sophisticated spam catching algorithms and powerful filtering tools. Back in the early 2000s, though, that wasn't the case. Spam was still a huge problem that mail servers had yet to seriously tackle, much less develop advanced tools to manage.
In 2003, Meng Weng Wong proposed a way for mail servers to "verify" that the IP address (the unique number that identifies a computer on the internet) sending a message was authorized to send mail on behalf of a specific domain. It's called the Sender Permitted Form (renamed to "Sender Policy Framework" in 2004), and Matthew explains how it works:
Each time an email message was sent, the receiving email server would compare the IP of origin for the message with the IP address listed in the SPF record for the email address’s host (the “@example.com” part.) If the two IP addresses match, then the email could pass through to the intended recipient. If the IP addresses did not match, then the email would be flagged as spam or rejected altogether. The burden of deciding the outcome was completely in the hands of the receiving server.
Over the years, SPF records have evolved (the most recent RFC was published in April 2014), and most domains on the internet have SPF records (you can search for them here).
When you register a domain, you also register a number of DNS records that go along with it. Those records tell the world which computers to talk to depending on what they want to do (email, web, FTP, and so on). The SPF record is an example, and ideally it would make sure all the mail servers on the internet knew that people sending email from, say, @lifehacker.com, were actually authorized users and computers.
However, this method isn't perfect, which is part of why it didn't catch on completely. SPF records require administration—someone actually adding new IP addresses and removing old ones, and time for the record to propagate across the internet every time a change is made. (Update: We previously tied SPF checks to user IP addresses, when the technology is actually used by mailhosts to verify that the server through which a message passes is an authorized sender on behalf of a given domain, not that the device used is authorized to send on behalf of a given address. Sorry for the confusion, and thanks to the commenters who pointed this out!) Most companies use a soft version of SPF anyway. Instead of risk false positives by blocking useful mail, they implement "hard" and "soft" fails. Email hosts also loosened their restrictions on what happens to messages that fail that check. As a result, email is easier for corporations to manage, but phishing is easy, and a big problem.
Then, in 2012, a new record type was introduced, designed to work alongside SPF. It's called DMARC, or Domain-based Message Authentication, Reporting, and Conformance. After a single year, it's expanded to protect a large number of consumer mailboxes (although the self-proclaimed 60% is probably optimistic.) Matthew explains the details:
The DMARC boils down to two important flags (although there are 10 total) - the "p" flag, which instructs receiving servers on how to deal with potentially phony emails, either by rejecting, quarantining, or passing; and the "rua" flag, which tells receiving servers where they can send a report about failed messages (usually an email address at the domain admin's security group). The DMARC record solves most of the issues with SPF records by taking the burden of deciding how to respond away from the recipient. The problem is, not everyone uses DMARC yet.
This handy tool allows for you to query any domain's DMARC record - try it out on a few of your favorites (gawker.com, whitehouse.gov, redcross.org, reddit.com). Notice anything? None of them have published DMARC records. That means that any email host that tries to conform to the rules of DMARC wouldn't have any instructions on how to handle SPF failed emails, and would probably let them through. That's what Google does with Gmail (and Google Apps), and that's why phony emails can get through to your inbox.
To prove that Google does pay attention to DMARC records, look at the DMARC record for facebook.com - the "p" flag idicates that recipients should reject emails, and send a report about it to the postmaster at Facebook. Now try to fake an email from facebook.com and send it to a Gmail address—it won't go through. Now look at the DMARC record for fb.com - it indicates that no email should be rejected, but a report should be made anyway. And if you test it, emails from @fb.com will go through.
Matthew also noted that the "postmaster report" is no joke. When he tried spoofing a domain with a DMARC record, his SMTP server was blocked in less than 24 hours. In our testing, we noticed the same. If a domain is set up properly, they'll put an end to those spoofed messages quickly—or at least until the spoofer uses a different IP address. However, a domain that doesn't have DMARC records is fair game. You could spoof them for months and no one on the sending end would notice—it would be up to the receiving mail provider to protect their users (either by flagging the message as spam based on content, or based on the message's failed SPF check.)
How Spammers Spoof Email Addresses
The tools necessary to spoof email addresses are surprisingly easy to get. All you need is a working SMTP server (aka, a server that can send email), and the right mailing software.
Any good web host will provide you with an SMTP server. (You could also install SMTP on a system you own, port 25—the port used for outgoing email, is usually blocked by ISPs. This is specifically to avoid the kind of mass-emailing malware we saw in the early 2000s.) For his prank on us, Matthew used PHP Mailer. It's easy to understand, easy to install, and it even has a web interface. Open PHP Mailer, compose your message, put in the "from" and "to" addresses, and click send. On the recipient's end, they'll get an email in their inbox that looks like it came from the address you typed in. Matthew explains:
The email should have worked without issue, and appears to be from whomever you said it’s from. There’s very little to indicate this didn’t come from their inbox, until you view the source code of the email (“View original” option in Gmail). [ed note: see image above] You’ll notice that the email “soft” failed the SPF check, yet it came through to the inbox anyway. It’s also important to note that the source code includes the originating IP address of the email, so it’s possible that the email could be traced, if the recipient wanted to.
It’s important to note at this point that there is still not a standard for how email hosts will treat SPF failures. Gmail, the host I did most of my testing with, allowed emails to come in. Outlook.com, however, did not deliver a single falsified email, whether soft or hard failed. My corporate Exchange server let them in without issue, and my home server (OS X) accepted them, but flagged them as spam.
That's all there is to it. We've skimmed over some details, but not many. The biggest caveat here is if you click reply on the spoofed message, anything sent back goes to the real owner of the address—not the spoofer. That doesn't matter to thieves though, since spammers and phishers are just hoping you'll click links or open attachments.
The tradeoff is clear: Since SPF never really caught on in the way it was intended, you don't need to add your device's IP address to a list and wait 24 hours every time you travel, or want to send email from your new smartphone. However, it also means that phishing remains a major problem. Worst of all, it's just so easy that anyone can do it.
What You Can Do to Protect Yourself
This all may seem arcane, or seem like a lot of fuss over a few measly spam emails. After all, most of us know spam when we see it—if we ever see it. But the truth is that for every account where those messages are flagged, there's another where they aren't and phishing emails sail into user inboxes.
Matthew explained to us that he used to spoof addresses with friends just to prank friends and give them a little scare—like the boss was angry with them or the receptionist emailed to say their car was towed—but realized that it worked a little too well, even from off the company network. The spoofed messages came through the company mail server, complete with profile pictures, corporate IM status, auto-populated contact information, and more, all helpfully added by the mail server, and all of which make the spoofed email look legit. When I tested the process, it wasn't much work before I saw my own face looking back at me in my inbox, or Whitson's, or even Adam Dachis', who doesn't even have a Lifehacker email address anymore.
Even worse, the only way to tell that the email isn't from the person it looks like is to dig into the headers and know what you're looking for (like we described above.) That's a pretty tall order for even the tech-savvy among us—who has time for that in the middle of a busy workday? Even a quick reply to the spoofed email would just generate confusion. It's a perfect way to cause a little chaos or target individuals to get them to compromise their own PCs or give up login information. But if you see something that's even a little suspicious, you at least have one more tool in your arsenal.
So, if you're looking to protect your inboxes from messages like this, there are a couple of things you can do:
-
Turn up your spam filters, and use tools like Priority Inbox. Setting your spam filters a little stronger may—depending on your mail provider—make the difference between a message that fails its SPF check landing in spam versus your inbox. Similarly, if you can use services like Gmail's Priority Inbox or Apple's VIP, you essentially let the mail server figure out the important people for you. If an important person is spoofed, you'll still get it, though.
-
Learn to read message headers, and trace IP addresses. We explained how to do this in this post about tracking down the source of spam, and it's a good skill to have. When a suspicious email comes in, you'll be able to open the headers, look at the IP address of the sender, and see if it matches up with previous emails from the same person. You can even do a reverse lookup on the sender's IP to see where it is—which may or may not be informative, but if you get an email from your friend across town that originated in Russia (and they're not traveling), you know something's up.
-
Never click unfamiliar links or download unfamiliar attachments. This may seem like a no-brainer, but all it takes is one employee in a company seeing a message from their boss or someone else in the company to open an attachment or click a funny Google Docs link to expose the entire corporate network. Many of us think we're above being tricked that way, but it happens all the time. Pay attention to the messages you get, don't click links in email (go to your bank's, cable company's, or other website directly and log in to find what they want you to see), and don't download email attachments you're not explicitly expecting. Keep your computer's antimalware up to date.
-
If you manage your own email, audit it to see how it responds to SPF and DMARC records. You may be able to ask your web host about this, but it's not hard to check on your own using the same spoofing method we described above. Alternatively, check your junk mail folder—you may see messages in there from yourself, or from people you know. Ask your web host if they can change the way your SMTP server is configured, or consider switching mail services over to something like Google Apps for your Domain.
-
If you own your own domain, file DMARC records for it. Matthew explains that you have control over how aggressive you want to be, but read up on how to file DMARC records and update yours with your domain registrar. If you're not sure how, they should be able to help. If you're getting spoofed messages on a company account, let your corporate IT know. They may have a reason for not filing DMARC records (Matthew explained his said they couldn't because they have external services that need to send using the company domain—something easily fixed, but that kind of thinking is part of the problem), but at least you let them know.
As always, the weakest link in security is the end-user. That means that you'll need to keep your BS sensors turned all the way up every time you get an email you weren't expecting. Educate yourself. Keep your anti-malware software up to date. Finally, keep an eye on issues like these, since they'll continue to evolve as we continue to fight spam and phishing.
Photo by Gwyneth Anne Bronwynne Jones.
Until now, AppGyver was mostly known for its app prototyping tools and Steroid.js, a command-line based tool for quickly building HTML5 apps. Today, the company is bringing both of these ideas together with the public beta launch of Composer, a drag-and-drop HTML5 app builder that can work with data from any REST API and integrates with popular backend services and tools like… 
Back in 2012, when the online coding-education platform Codecademy announced a $10 million round of funding, the startup said it would invest the money in international growth. Two years later, Codecademy is making some big moves to fulfil that ambition: it’s opening its first international office, in London, and it is announcing partnerships in five markets — the UK, France,… 
