Victory Over Spam
Alright, so we may have won the battle, but the war is probably never going to end. I wanted to post here about our recent email spam problems, as I have been chipping away at them for about a week. It all started with our community forums, and the issue of some robot that would create an account and then post spam on the boards. After changing the forum configuration to require that someone verify their email address, that one seems to have stopped. It's interesting, as we will get FAILURE NOTICE emails every once in a while as they try to create an account by providing a bogus email. Each notice that we get represents a malicious spammy robot that has been denied. Nice.
Then there are the emails. A normal amount of email spam is rather normal, and I am a believer in using my local mail application for junk mail filtering, just in case an important message doesn't make it through. However, we are talking about hundreds of emails a day, which is a problem. As I mentioned, there were two avenues that the spammers were abusing. The first was the reverse DNS lookup which leads to emails being blasted at random accounts on our domain. Simply denying all unrouted mail and using MAPS spam protection seems to have halted those. The second vector for blasting emails at us was through our online forms. Robots would apparently get the URL for the forms, and just hit those URLs with spam messages.
This one required me to change the scripts that handle the form. I'll admit that they should have been this way to begin with, but they weren't. Essentially, I wanted the script to verify that the form was being submitted by a visitor to our website, and not from some other source or robot. An effective way to do that, which will take care of most form abuse, is to compare the referring URL of the form data with your domain name. Simply put, unless the form data is submitted from our domain (the referring page) the script will not allow an email to be sent. I also added some other checks to ensure that the data is entered by a person and not by a robot.
One last note on email spam is that spammers scan website with robots to harvest email addresses. One of the things that I need to do to our site is to remove the email links as they are and have them written to the browser via JavaScript. For example, rather than having this code to create an email link:
<a href="mailto:sample@email.com">sample@email.com</a>
I would use JavaScript to write the code when the page is loaded in. Since getting the address then requires that a robot or spammer to run the script (which is probably not far off, but currently rare in automated email harvesters), they are a bit more protected. The JavaScript code (greatly simplified) would look something like this:
<script language="javascript">
var account = "sample";
var domain = "email.com";
var txt = "Email Us";
var link = "<a href=\"mailto:" + account + "@" + domain "\">" + txt + "</a>";
document.write(link);
</script>
This script would be placed in the same place that the other code would have been. Of course, this is a simple version which will work as is. There are also javascript encoders that will encrypt the email address to hide it. Using an encoder will be much more powerful than this, and is something to look at if you continue to have problems.
