Configuring your cPanel settings so that you see less spam can turn into a never-ending battle once you start – and admittedly, some of you never start. So, this post we’re going to go over the default settings your account is installed with, and introduce you to some tricks that can assist you in filtering out unwanted email.

Exim

We process email through Exim – the way that mail works is that servers essentially knock on each other’s doors, provide a few key bits of information, and the receiving server decides whether to accept the sending server’s mail and if it accepts it, what to do with it. When an email is received, it goes through it’s first layer of security, which is not directly controlled by you. This level checks:

- whether the IP is whitelisted from all security, and delivers the mail.
- that the HELO is there, and if it is empty or not sent, the email is rejected.
- that the HELO is a fully qualified domain name. If not, it is rejected.
- If the IP Only is sent as the HELO, it is rejected.
- if someone sends our IP as their IP, it is rejected.
- against recent dictionary attacks, and is rejected it found.
- checked against the dictionary attack whitelist, and sent if found.
- checked against the RBL whitelist, and sent through if found.
- Is checked against zen.spamhaus.org, and rejected if found.
- Is checked against bl.spamcop.net, and rejected if found.
- checked against sender verify whitelist, and sent if found.
- sender is verified as real on sending server, and rejected if not.
- The recipient of the email is verified as here, and rejected if not.

After an email passes all of these checks, it is delivered to your mail system where your own MailScanner configuration and mail configuration handles the spam from there. While you don’t have the ability to change any of the above settings, we do have white lists set up to bypass almost every check just in case, so if you ever have an issue you can always ask DrakNet to whitelist one of your senders so that they simply step around the above if their mail is ever filtered and there’s no evidence their server is a threat to ours.

MailScanner

Our MailScanner installation is not a cPanel product, it’s an additional spam-fighting software that we installed to better address the spam. While MailScanner incorporates SpamAssassin (the default spam tagging and scanning software that does come default), our MailScanner also incorporates Distributed Checksum Clearinghouse and Vipulus Razor as well as SpamAssassin.

Upon your account’s installation, your MailScanner is pre-configured for the least restrictive use. Low scoring spam is considered a 5, high scoring spam is a 20, everything is set to be delivered, and virus scanning is actually turned off despite it appearing in your configuration area as many people complained of false positives and seemed to prefer handling their own virus scanning. At this point, MailScanner will only tag your spam – you will still see it all (or at least all the mail that gets through the RBL). You can change all of these settings under the “MailScanner Configuration” icon.

The Default Spam scoring numbers are pretty good – but feel free to play with them. Changing them around will change how MailScanner decides what is spam and what is not. There are two choices that you have insofar as what you want MailScanner to do with the spam it finds.

Those who set MailScanner to deliver the spam usually do so because they have set up their own filtering rules to filter spam-tagged mail into a folder so that they can peruse it all and make sure nothing is mis-tagged before nuking it. You can accomplish the same thing by creating an email address specifically for spam, having MailScanner deliver it there, and checking it/cleaning it out frequently.

You can also set it to discard – which is, admittedly, the most pleasant. The domain name drak.net has been around for ten years now, and has had lots of time to be sold and resold again to a variety of spam lists, so the spam that it gets thrown at it is a veritable flood. A few years ago, the tagging was just too much to deal with, and we began discarding both high and low scoring spam so that we don’t see any of it. A few still get through, but the helpdesk is now far more manageable. The risk is, of course, that something is mis-tagged, and you won’t see it to know it got discarded.

Then there’s a third measure you can take that people often overlook – cPanel’s mail filtering.

Filtering

There are two filtering options in your cPanel – account level, and user level. The two buttons are exactly what they say – you can use account level to filter emails for everyone on your account, and user level to come up with specific filtering directives just for one or a few email accounts.

So that this doesn’t get too long, we’re going to give you just one example to get you started.

At the top of account level filtering, it says:

Please create or edit a filter below. You can add multiple rules to match subjects, addresses or other parts of the message. You can then add multiple actions to take on a message such as to deliver the message to a different address and then discard it.

Click on “Create a New Filter”. Once you’re there, you’ll see that you have a number of options to filter out certain emails. Let’s say that you keep getting emails from a spam company that MailScanner just doesn’t seem to get with that Viagra mis-spelling – this newsletter always says “Vi@gra” in the subject line, and no matter how you play with the settings in MailScanner and even though you have it set to discard, you keep seeing it (or you tag email and know that no email with Vi@gra in the subject line is one that you ever need to see).

You’d name the rule – “Vi@gra Subject Filter”, or something that lets you know what it does. Then use the drop down list to choose to filter the subject, then choose “contains” (since you have no idea what else they’ll say in the subject line), and on the second line put Vi@gra. “Discard Message” should be the default chosen – then just hit the button to activate the rule., and bye bye messages There’s even a testing mechanism for the spam you used to make sure that the system is doing what you want with it.

This is a pretty robust system, and this post is meant to show you the ability that you have to manage the mail routing and the different abilities you have to deal with spam, not fully explain every aspect of the system (which would be extremely long and involved). If you have any questions about mail routing, you can always leave a comment here or email support, and we’ll be happy to help.

This past week has brought up some very interesting illustrations of just how careful you have to be when downloading or purchasing software off of the Internet. Everyone knowns not to download “too good to be true” free programs to their computer, and almost everyone now runs virus and malware scanners for their desktop to protect their computer from a wrong decision. Can the same scheme that infects your computer infect your site?

You bet.

Just this week, it was discovered that a massive number of Wordpress Blogs were hacked by an organized scheme, including installations at ZDNet, utilizing an xml-rpc vulnerability. Some of the hacks also came in through users downloading Wordpress themes that were infected (likely deliberately, but maybe not). Remember the old Lost Boys vampire thing where you have to invite him in for the vamp to be able attack you in your own home? Yep, same thing.

Frankly, we here at DrakNet are not immune to this – this past week, I was toying around with the idea of installing a directory of Soholaunch hosts. I had looked at this software and when I tried to order, it checked me out at a different site – which should have been my first clue. $90 later I had software that I hadn’t checked out, and the awakening came only after I purchased it.

When I unpacked it, there were immediate indications that something was amiss – the files provided were all dated May of 2005. “Good” PHP practices in May of 2005 compared to April of 2008 have changed significantly, and what everyone thought it was a-ok to do back then in the intervening years has been shown in some cases to be insecure and downright dangerous, so I began to do the due diligences that I should have done before I plunked down my money.

What I discovered was that multiple XSS And SQL Injection Vulnerabilities were found in the software in May of 2006 – a year after all the files provided me were created. Checking their web site, I found that the company advertised that their last update to the files was in December of 2006, implying that the software had been updated after these vulnerabilities were found – and yet as I searched through the installation I had downloaded, there wasn’t a single file provided that was dated after 08-18-2005, two days before it’s first official release date, and a year before it’s landing on multiple security advisory lists.

Had I done a search for the company, I would have seen that their company name and the word “nightmare” comes up multiple times on their first search page and I would have gotten some indication that, perhaps, this software wasn’t exactly my best choice. Had I simply done a search for their company name and the word vulnerability, I would have seen that there were 9,390 entries. I was in a hurry, and I didn’t – it was my own fault, and I admit it. I do know better, but I was in a hurry, and skipped that part.

As a consequence, I’m now arguing for my $90 back. I first went to the company who, of course, doesn’t do refunds and offered to work out what the issue was. When I outlined and detailed what I perceived as a suspicion that the company fraudulently advertised an update that didn’t take place to make it seem that they had patched insecure software that they hadn’t, suddenly, they were silent.

I then went to their payment processor for a refund, and thusfar the company has refused to speak to them, either. I will likely wind up having to drive to my bank, fill out paperwork, print out all of this evidence, and file a chargeback. Lesson learned… again.

So, how do you not fall into a trap like this?

Remember that old software is usually insecure – there’s even a term for it. Abandonware. Abandonware is old software, no longer maintained by the company or creator, and is no longer updated or patched when security issues are found within it. Microsoft FrontPage is actually now abandonware – as of late 2006, it is no longer supported, updated, or patched. There are thousands of scripts like this floating around on the Internet.

Google the script and the company with the word vulnerability and security. See if problems have been found with the programs, and whether the software developers are actually paying attention to the security community – good software companies (or good open source software developers) will jump when a vulnerability is found in their software, and will report back to the alert lists that it’s been patched after they release that patch to protect their users. If they don’t, that should be a red flag.

Google the script and the company to see what people are saying about them – everyone that does business on the Internet is going to aggravate someone, and finding something negative isn’t always a reason to run. You should, though, find more good opinions than bad opinions about the software and the company, and if you don’t find any opinions the software may not be widely used enough to have had it’s vulnerabilities discovered. This is the Internet – people talk. If they aren’t talking about you… well…

Don’t download Wordpress Themes, scripts, and so on from spammy looking sites. Get it from spammy sites, get a spammy product. Realize that anything that you put on your site is potentially open door to the developer and/or anyone else if there’s a hole – make sure that developer is trustworthy insofar as you can both not to take advantage, and to stand behind what they created with a sense of responsibility towards the people that use their software.

Remember that your web site is a veritable playground of mischief, and be as selective as you can in what you decide to snag and put on there – any program has the ability to put a back door into your site and subvert your site for its own ends. Do as much as you can to make sure that it doesn’t happen – and don’t get lazy like we did – because it’s the one time when you decide to just hurry up and do it that you may get burned.

We still see an awful lot of people forwarding email offsite to their ISP’s email address. This is very bad. Very, very bad. We wish cPanel had a way to stop you from doing it, and we wish we had time to contact every one of you individually to explain why it’s bad because we can see in our handy, dandy config files who’s doing it and where it’s going. Since we cannot do that, we’re going to explain here why this is very, very, very bad both for you and for us.

Your cPanel email system is fairly robust. You have POP email accounts, IMAP accounts, and forwarding capabilities. You can get mail through webmail on this server, pop it into a client, get it on your Blackberry – the choices are numerous. Out of all those choices, there’s only one that can really harm your ability to get your mail, and that’s forwarding your email to your ISP (or GMail, Yahoo, or Hotmail).

When someone emails our system here, there are some tests that the email goes through when another mail server knocks on the door. First, we see if the sending server is on an RBL and if so, we won’t take the mail. Next we check if the recipient email address is defined as accepting mail (which includes installed accounts or forwarders) and if it is not, we don’t accept the mail. If the sending server isn’t on an RBL, the email address exists here, and it passes some other criteria that insures it’s a correctly formatted email, then our servers take the mail and processes it. If you simply have a POP account for that address, we drop it in there, and it waits for you to pick it up.

If you have an offsite forwarder, we then take that email and forward it to your ISP (or webmail provider) – this forwarding step changes the nature of that email in that the email is no longer from the server that originally delivered it here. The email is now originating from your server here at DrakNet.

This is an unbelievably important distinction. If you have MailScanner set to deliver and simply tag spam, and you also have your account set up to forward that email to you, you and your domain (and since this is shared hosting, the entire server and everyone on it) then appear to be the spammer to your ISP because the email being sent to you is being delivered by us. Even if you have MailScanner configured well, some spam mail will still get through – once that happens Comcast, or AOL, or SBCGlobal, or RoadRunner will look at our server and says:

“Dude! You keep sending spam to our user! You won’t stop! You can’t email here anymore!”

And before you can blink, all mail from here to there bounces. All of it – from everyone on the server with you trying to email anyone they know at that ISP. (As well as, remember, all the mail you are forwarding, both good and bad, which you now won’t ever see).

The AOL folks are particularly guilty of causing problems with this because of the unbelievably easy way AOL lets you report spam – simply click a button, and report the server instantly, right? Well, if it’s a forwarded email, you just reported your DrakNet server, upping the likelihood that one of our servers will get blacklisted for forwarding your mail to you, just like you told it to, and ensuring that you’ll lose a significant amount of mail, as well as disrupt communications for everyone with you.

Another issue with this is that if you forward your mail offsite, we simply have no way to help you if you have a question about lost mail. Once your ISP accepts the mail, our part is over with. If a mail doesn’t make it to you and your ISP accepted it, it simply isn’t our issue anymore and we have no ability to ask them what they did with the mail once they took it – and most ISPs are so large that whether you lost one email from your Aunt Martha really isn’t their concern.

Forwarding should only be used to define multiple addresses that accept mail on the server, and they should only be used to forward that mail to email addresses on the server itself. drak.net itself has about 20 email aliases and only one actual pop account – there is no limit to how many email aliases you can have. Once you begin using those forwards to forward offsite, though, you risk setting off a blacklist that will disrupt mail service for you, and the communication ability of all your neighbors. And yes, it can get your account asked to leave should it happen more than once.

All the major webmail providers (Gmail, Yahoo, Hotmail) allow you to pop email into your webmail – set this up instead of forwarding. Almost all popular email programs allow you to pop mail from multiple accounts into one area to manage it – set this up instead of forwarding to your ISP. Don’t forward email to your ISP out of laziness – the risk is fairly significant that you could blacklist your own domain, tick off everyone on the server with you, and greatly annoy us when we have to deal with it.

One more word about forwarding – if you install a pop account on the server, and you install a forwarder on the server to send the email offsite with the same address as the pop account, you will get two copies of that email. One copy will be archived on the server here, and one is sent to you – your mail can fill up very, very quickly that way, eventually overtaking your quota if you install a pop account and never check it or clean it out. If you are using an address as a forwarder only, do not install a pop account for it – it’s an alias, and it doesn’t need it.