Positive Fusion

We’ve been noticing that the option in CPanel labeled “Email Domain Forwarding” has a tendency to be used incorrectly on a regular basis. Hopefully this post will help explain what that section is actually about.

Most users appear to be setting the email domain forwarding up intending it to act as the catch-all email address. In order to have any local part (before the @ symbol) forwarded to a single ‘default’ address, you actually want to set that in the “Default Address” section instead.

Email Domain Forwarding is for when you want to laminate two domains together, particularly useful for parked domains. Please do not enter an email address in the Email Domain Forwarding section, it’ll result in tremendous quantities of email errors.

The result of entering an email address (which Cpanel should not allow, but appears to for some unknown reason) is emails attempting to be sent to addresses like you@yourotheraddress@yourdomain. Ooops! The email server will reject those instantly, but that adds a lot of unnecessary work for the server.

Please only use the Email Domain Forwarding if what you want to do is like this:
you@your2nddomain -> you@your1stdomain. It’ll also automatically forward like this: thatotherfellow@your2nddomain -> thatotherfellow@your1stdomain.

The most useful situation for this option is if you have a .com domain, but also have the .net, .org, etc, domains parked on the .com.

Also, we strongly, very, very strongly, recommend against ever setting the default address. The end result is almost always a flood of dictionary spam. We recommend the default address always be set to :fail: instead. If someone is emailing you, they really ought to know what your email address is, don’t you think?

If you do actually want any random local part to be delivered to your inbox, you can enable that by setting the default address in the default address section.

We’ve isolated the cause of the problem, it’s actually misbehaving software installed by a user. We’re in the process of having that situation remedied.

The server is currently under heavy load. We’re looking into the cause, but as of yet have not been able to determine the precise reason.

23:34 - The situation is now under control, though the reason for the heavy load as still not been determined, we believe it was related to statistics processing.

It has been a very long time that we’ve used Mod_Security filtering. Within the past few weeks we have modified and updated some rules. Due to these changes some users have experienced 406 errors for the first time.

If there’s a 406 error, it simply means that our rules we are filtering with have caught something listed as objectionable. It’s rare that 406 errors will effect the typical website visitor, unless of course they’re trying to do something bad. Most often a 406 error will result when a user is posting something using a content management system, or installing software for the first time.

We do encourage you to let us know when you experience problems, because if a rule is causing a lot of false-positives we’d be better off not using that particular rule.

You, the user, can actually turn off mod_security filtering yourself by using standard .htaccess syntax. This method was first described here in relation to Wordpress, but the method applies to any file on your website.

Create or edit an .htaccess file within the particular file’s directory, enter the following (this is an example for WordPress):

If the file is index.php, for example, place that filename in the directive instead.

We can also tag specific rules with an ID code, in that manner we can give you a code to turn off that particular rule, while allowing all other mod_security filtering to continue.

We noticed a problem today with the hosting invoices, they’ve not been being issued automatically. Today we ran the the invoicing manually and many were generated several days later than they normally would have been. This has not effected billing, just the actual invoices being sent.