Many web hosts spend at least 2% of their time removing spam tickets. That is, tickets that are created via email messages.
The problem on the side of these companies is, they must have their email addresses publicly available; and even if they choose not to, their clients’ domains’ WHOIS output will always show an email address belonging to the organization, such as dns@company.com or billing@company.com.

Since Kayako eSupport is one of the most popular HelpDesk software available for website hosting companies, I decided to use it as an example for this mini-tutorial. Of course this method can be applied to more helpdesk software, it’s just a matter of configuring things correctly and using IMAP to check for new tickets instead of using Email Piping, which unfortunately is what most webmasters tend to use. So let’s start:

The first thing you should do if you are using Email Piping is to delete your forwarders and replace them with real POP3/IMAP mailboxes.
EG: Usually webmasters only create an email forwarder piping the email to /public_html/esupport-folder/admin/pop3pipe.php

All those valiases have to be removed permanently. Then create the email addresses as POP3/IMAP mailboxes.
Once you’ve done so, log into your Kayako eSupport Administration Area as an administrator and click on “Settings”.

Then, click on the Email icon. If you already had your email addresses configured in Kayako, they should be listed on this page with “PIPE” listed as “Method”.
On every account configured, you must do the following modifications:

1. Click on the “Edit” icon just on the right side of the configuration summary (just before the Delete icon)
2. Once the full configuration page for the selected email address opens, modify the “Method” variable to “PHP IMAP Functions”.
3. Add your “Host” and email username and password. This of course must match the credentials you have selected when you created your email account. As for the email host, I strongly recommend you to use “localhost” if your mail server is being hosted on the same machine as Kayako. This will bypass the need to resolve the mail server address, significantly decreasing the server load if you have a busy helpdesk.
4. Click on “Update” and do this for all your email addresses.

Once this part is completed, we should go to cPanel (if you’re using cPanel, that is) and enable BoxTrapper for all the email addresses you are using on your Helpdesk. It’s recommended to change the verification messages as well, so they look like they are coming from a Helpdesk. An example verification message would be:

“Thank you for contacting us. Our company is now using an Anti-Spam system in order to prevent spam on our helpdesk. As such we require our users to verify that they intended to send the message. This will only be required one time. Once you verify, your email address will be added to our company’s whitelist and you will no longer have to verify on future email messages sent to us.”

Of course this is just an example, and not a very elaborated one. Use your creativity for that
Most of the users will understand this. Just make sure you emphasize that you added the spam protection in order to reduce server load and also to reduce time removing all those daily spam digests you are receiving. Also, I would add that being a company, you must of course write press releases every now and then, and when this is done your email addresses will be listed on thousands of websites, making them easy-to-pick email addresses for SpamBots. Again, use your creativity and common sense to explain this to your clients.

The next and final step is to add a Cron Job so Kayako checks your mailboxes every 5 minutes. (of course this can be adjusted to your needs - just change the cron job if needed):
*/5 * * * * /path/to/php /FULL/PATH/TO/ESUPPORT/admin/pop3functions.php 2>&1 > /dev/null

For example, if you are using cPanel, the cronjob would be something like this:
*/5 * * * * /usr/bin/php /home/yourusername/public_html/PATH/TO/ESUPPORT/admin/pop3functions.php 2>&1 > /dev/null

Of course this depends on the system you are being hosted on, so if you’re not sure what to add there just point your system administrator to this tutorial and he’ll do it for you.

That should be all there’s to it. You should be now Spam-Protected.

Many web hosts converted or will convert to phpSUEXEC, mainly because phpSUEXEC is much more secure that the regular php being served with apache has API.

If you’re currently using the "regular php", a  few changes may be required on your website’s configuration files (.htaccess).

Every php_flag command in your .htaccess file will have to removed and moved to a new file with the name "php.ini", which you will have to create in your site’s public root folder.

For example:
.htaccess command » php_flag register_globals on
php.ini command » register_globals=on

The file php.ini will handle all the extra settings you need to set in php. It’s pretty much your own custom php configuration file.
So, basically you will have to move every command on .htaccess that starts with php_flag to the new php.ini configuration file.

Differences between phpsuexec and "regular php":
When using the common PHP installation on a webserver, php runs as "nobody" (just like apache) and it doesn’t require the execute flag to be enabled.

The problem on this is that if mod_openbasedir is not installed (every host has this nowadays), every user will be able to read your php files because everyone is virtually sharing the same username (nobody).

As most of you already know, PHP Files are not meant to be read, but parsed, and that is where the problem resides. PHP Files have to be parsed, otherwise everyone who is able to read your php file will see settings that you would probably want to keep private, such as your MySQL username and password.

PHPSUEXEC eliminates this security concern because it requires php to be run as the file owner’s username. (for example: andre)
This will also make system administors’ lives easier because they can now directly monitor the usernames running php, as such it becomes easier to track overload causes, etc.

This is not everything it does, though. phpSUEXEC is also here to fix file ownership issues; which is a common issue on a few Content Management Systems such as Joomla or even the popular blog platform: WordPress.

It will also add security to your files as you can use permissions such as 600 or 700 on them and your visitors will still be able to access them (parsed) in their browsers.

A system compiled with phpSUEXEC will also refuse to serve any pages that are at security risk, for example with 777 as permissions. (this will trigger an Internal Server Error)

Troubleshooting Internal Server Errors (Error 500):
Everytime an internal server error occurs, an entry will be added to your Error Log in cPanel. (cPanel »» Error Log).
This will usually give you a clue on where the error is coming from. In most cases it will be either a permission problem (for security’s sake) or a then invalid command in your .htaccess configuration file (remember that all commands started by php_value have to be migrated to your new php.ini configuration file).

Directories that need to be written onto will no longer require 777 as permissions and phpSUEXEC will also refuse to write or read on directories insecure with such permissions. You will have to keep their permission settings as 755.

To simplify it, just keep in mind that you shouldn’t have a file or folder with world-writeable permissions (777), because you no longer need to.

MIME Types:
If you added a Mimetype to the system in order to run parse html files as php scripts (using AddType as a .htaccess command), you will have to replace it with an ApacheHandler instead. Just replace "AddType" by "AddHandler" and you should be good to go!

QuickStart for impatient users:
Technically, phpSUEXEC will make sure your files and directories abide by the following security restrictions:

• User executing the wrapper is a valid user on the webserver.
• The command that the request tries to execute cannot contain a / (must be clean).
• The command being executed must reside under the user’s website’s document root (wwwroot or public_html depending on the system).
• The current working directory must not be world-writeable.
• The command being executed cannot be a symlink (again for security’s sake).
• The command being executed cannot be a setuid or setgid program, these will be ignored.
• The target UID and GID must be a valid user or/and group on the webserver.
• The UID and GID, must match file/directory ownership.

Protecting your php.ini file:
You can set php.ini’s permissions to 600. This will make sure no one will be able to read it through a browser, while the configuration file will still work for you.

Webalizer is compiled with cPanel and sometimes, non-native english speakers like me forget about this and will use a non-english user to run Webalizer for the first time. Huge mistake. Webalizer will be compiled with the language that the user has set to be the default.

It can be Spanish, Portuguese even Russian. And all your clients will have to deal with this.
Not anymore. After trying to fix this for months, I am sharing the solution I wanted to be available online but couldn’t find: The webalizer binary and the english language file for it.

Instructions:
1) Backup your original webalizer binary and language file by running the following commands on a root shell:

• mv /usr/local/cpanel/3rdparty/bin/webalizer /usr/local/cpanel/3rdparty/bin/webalizer.backup
• mv /usr/local/cpanel/3rdparty/bin/english/webalizer /usr/local/cpanel/3rdparty/bin/english/webalizer.backup

2) Then you’ll need to get the english binary and language file (I have those prepared for you, so don’t worry).
Run the following commands:

• cd /usr/local/cpanel/3rdparty/bin/
• wget http://www.andrefaca.com/non-deletable-files/andrefaca.com/files/webalizer-binary.zip
• unzip webalizer-binary.zip
• chmod 0755 webalizer
• cd /usr/local/cpanel/3rdparty/bin/english
• wget http://www.andrefaca.com/non-deletable-files/andrefaca.com/files/webalizer-english.zip
• unzip webalizer-english.zip
• chmod 0755 webalizer

3) Now it’s time to run webalizer:

• /scripts/runlogsnow

Note: You should allow the runlogsnow script a few hours to run, depending on how many domains you have. If you want to just test it out on an account, you can instead use the command:

• /scripts/runweblogs

That’s it! Your webalizer is now in english! Now tell me how cool is that