|Intro|  |News|  |Threats|  |Alerts|  |Papers|  |Events|  |Reading|  |Links|  |About Me|  |Powered-by...|
Who the heck is Joe Job?
[Back to Main]

Once there was a guy named Joe.  He ran a web hosting business, and one of his ex-customers (who had been terminated for AUP/TOS violations) decided to get back at Joe by sending millions of spams and putting Joe's e-mail address on the From: line.  Needless to say, this caused many complaints, and even a denial of service attack against Joe, whom people mistakenly believed had spammed them.  In the end, Joe was forced to shutdown his business and move his domain.  This unfortunate incident coined a new term:  The Joe Job, i.e. to send unwanted mail and purposely put someone else's address on it so all the complaints wrongfully go to a third party.

A Joe Job is one of the most infuriating of all Internet attacks to deal with.  Not only does the Joe Jobee have to deal with a massive flood of bounce messages that result from the spam campaign, but they also get to deal with a swarm of complaints from people who believe the Jobee actually sent the original messages.  In the worst cases, the Jobee will end up on DNS Blacklists or come under Denial of Service attack by overzealous anti-spammers.  In the past, there wasn't much you could do besides create some content filters to block the incoming bounce messages and put a notice on your website that you did not send the original message.

The good news is there is now something much more pro-active that you can do.  It's called Sender Policy Framework, or SPF for short.  In a nutshell, it's a special syntax for setting up TXT records in your forward DNS zone that will tell other sites what IPs and hosts are allowed to send e-mail on behalf of your domain.  When another domain receives mail, they can check your DNS to make sure it's really permitted to come from your domain.  If the messages are being spoofed, the remote site can make note of that and take the appropriate action.

There are some limitations, however.  First, you have to go to the effort of setting up SPF records for all the IPs and hosts that should be sending your mail.  Some times this is a challenge if your site uses partners or third party firms to send out e-mail campaigns for you, or if you have a number of web-enabled applications that send their own mail.  One thing you can do to simplify things is to make sure that all mail from your organization is routed through a few centralized servers.  Web servers shouldn't be sending mail directly to the Internet, it should go through SMTP gateways first.  Once you have your SMTP presence consolidated as much as possible, publish SPF records in your forward DNS.

Now you've taken care of your part of the bargin, but it's up to each remote site to implement SPF checking in their inbound MTAs.  Fortunately SPF is catching on relatively fast and is backed by some very large sites, so it should only be a matter of time before a majority of SMTP precenses are checking SPF records.  More good news:  most Open Source MTAs are being patched to include SPF checking, and several commercial products either support it already, or are planning to in a future release.

Other than publishing SPF records, if you notice that you have been Joe Jobbed, immediately post a message about it on your web site with the original contents of the message and a very strong disclaimer stating you didn't send it.  It may be helpful to point out technical details, such as the fact that it didn't originate from an IP address that you own.  It's important to get the message up quickly and on a prominent part of your site, so that Google and other search engines have a chance to discover it by the time angry people start searching the Internet for information about the message.




This site © copyright 2003-2011 Brian Keefer.  Unauthorized republication is forbidden.