Sifting Through Spam

If you are setting up email filters for an account, some useful tactics are:

Display the headers of the emails in the account:

grep -iE "^(subject|from|reply-to|X-Spam-Level):" *

Once you identify messages of interest, you can use more to view them.

If you're using cPanel's filter interface with a RegEx, you can use this to exclude all .eu and .us (and any other) TLDs.


Type it in exactly as displayed. I put it on both the From and Reply-To headers.

Another good rule is to match on the spam score in the X-Spam-Status header, like so:


Emails with a spam score of 3 or 4 are rejected with a message that the sender should use the contact form on the site. Almost all of these will be spam, but for the few that aren't, the sender will have a way to resubmit their message.

Be sure to test to make sure it works the way you want it to.

If you find domains that are clearly just spammers, block them explicitly.

Report spam to, and scams to the organization that's being misrepresented.

Linux Command Line - Convert XML to JSON

This was the answer to a question that came in an email - "Do you know of a good XML to JSON converter?"

Obviously you need php-cli, JSON, and SimpleXML. :)

The "xml" is the name of the file that contains the XML, the output can be piped to a different file.

php -r 'echo json_encode(simplexml_load_file("xml"));'

If you would like it pretty printed, this page is really nice:

Upgrading PHP 5.3 to 5.4 - Checking your code (Linux)

If you are upgrading PHP from 5.3 to 5.4 for an existing application, you can use the following commands to check for parse errors.

tree -fi application | grep -E '.php|.phtml' | sed "s/^/php -l /" > files
source files > results

The output is really what comes out of stderr, which will be the parse errors.

Be sure to check out the short_open_tag directive (

By default <?= is enabled, to use <? for statements other than echo, you must enable the short_open_tag option in /etc/php.ini.

HTML5 Tag Challenge

For years I've enjoyed I have never named all the tags, but I return periodically to see if I can.

For fun, I created and HTML5 version.

I still can't name all the tags.

How to set environment variables that can be referenced by Apache, shells and cron jobs

In some cases, environment variables are used to store configuration information. If the values are referenced from different sources, such as through a web server and on the command line, it is a good idea to define them in a single place and gracefully make them available.

This is one way to set the environment variables in one place, then source them into accounts for use (CentOS 6.4):

1. Create /opt/webapp/etc/appconfig/common and put the environment variables in it

export TEST_ENV_VAR="Test Environment Variable"

2. Add these two lines to /opt/webapp/etc/sysconfig/httpd

if [ -f /opt/webapp/etc/appconfig/common ]; then
. /opt/webapp/etc/appconfig/common

3. Add these two lines to /etc/sysconfig/httpd

if [ -f /opt/webapp/etc/sysconfig/httpd ]; then
. /opt/webapp/etc/sysconfig/httpd

4. Add this line to /etc/httpd/conf.d/webapp.conf (webapp Apache conf file)


4. Restart Apache with service httpd restart

5. Test with http://webapp/phpinfo.php (<?php phpinfo(); ?>

6. Add these two lines to /home/admin/.bashrc - or whatever the account is that will use the variables.

if [ -f /opt/webapp/etc/appconfig/common ]; then
. /opt/webapp/etc/appconfig/common

7. Test with echo $TEST_ENV_VAR

What this does is creates a common place to store the environment variables and makes them accessible to both Apache and the shell of admin (and any other account that includes them). That way, when a script is run as a cron job or on the command line, it has the environment variables all set. If new environment variables are needed, or if they change, the common file is updated as well as any others that reference the new variables. Then you restart Apache.