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.

Lots of people that sign up never bother to read the Terms of Service. We know this - we also know, as you do, that you’re bound by it whether you read it or not. Unfortunately, more and more people are getting caught by the mass-email restrictions, so we wanted to give you some tips regarding those, and working around them to do what you need.

First, obviously, you need to make sure that if you run an announcement list, you keep good records. You’re sharing a server with a few hundred other people and as much as we may personally like you and as fun as you may be on the DrakChat list, if you get the server blacklisted, we’re very likely going to show you the door unless you can prove they opted in. Blacklisting is something that disrupts communications for hundreds of people, and in our best Texas drawl we report unequivocally that “we just won’t be having it“. Part of the reason why blacklists have become almost obsolete here is that we’re jackbooted thugs when it comes to this kind of stuff.

The first rule, which is automatically enforced, is that absolutely no web script anywhere is allowed to send more than 100 emails in an hour. We have software that will detect it and simply shut off your script automatically. It’ll lock it down before it even emails us to let us know it’s happened, its that automatic of a process.

This is partly for performance reasons - when you share a server with hundreds of other people, they don’t want to wait for your 10,000 emails to go out before their email can go out. A queue is exactly what it sounds like, a line that everyone waits in. More than 2 domains send out 10,000 emails on one server at the same moment, and mail processing comes to a screeching halt. For fairness, no one gets to repeatedly own all the resources at $5 a month. Sorry.

The second reason is security. The vast majority of spam goes out through innocent servers that have compromised, insecure, mis-configured or “old and should have been updated in 2003″ web scripts. As much as we harp on updating, some of you ignore that, too, and leave scripts that were written in 1999 sitting on your web site because you like it and it appears to work.

While we inventory and try to catch them, there’s always a chance that we don’t. One wrong configuration, one hole not patched, and your site is sending out thousands of emails touting the benefits of Viagra, which gets the server (and everyone on it) blacklisted, and causes us to focus days on patching, securing, and getting off the blacklist as well as answering emails from irate customers who are angry their mail is bouncing - and we usually do this while your site sits suspended. To avoid that, we lock down anyone that sends more than 100 emails in an hour from any web script on the server in an attempt to ensure that you can function, don’t lose your account, and that if a compromise happens we have a minimal chance of dealing with a blacklisting since so few emails got out.

Does that mean you simply can’t run an announcement list on our servers? No, it doesn’t - it does mean that you have to work within the system to do it.

PHPList, which is the most common mailing list software used on our servers as it is offered in Fantastico, allows you to set and configure your mailings so that you can have your mailing list, your neighbors aren’t unduly burdened, and we can still stop spammers when they find compromised scripts pretty fast. This process is called “throttling” - programming PHPList to send out email in batches just under the server limitation to avoid being locked.

Full directions to throttle PHPList are located here. The process is very simple, and involves changing just a few parameters in the configuration file. For the longer version, visit their site - the short version (and the settings we recommend as we do run php-cgi) are:

1. Find config.php and edit in in an ascii test editor like Notepad (or Pico or Vi for the shell-aware).
2. Edit define("MAILQUEUE_BATCH_SIZE",0); so that it says define("MAILQUEUE_BATCH_SIZE",16);
3. Make sure define("MAILQUEUE_BATCH_PERIOD",600); says 600, which is 10 minutes.
4. If you want to be nice to your neighbors, changing define('MAILQUEUE_THROTTLE',0); to define('MAILQUEUE_THROTTLE',3); would be a nice touch.

This allows you to send 96 emails per hour, avoid the timeouts, and make sure the script won’t get locked. You do not have to worry about leaving room for other scripts on your site to email out that hour, as the 100 email an hour limit is per specific script, not per any web script on the entire domain.

If you run something other than PHPList, check with your software vendor regarding how to throttle or batch your mass-mailings.