Intercepting php mail() spam with sendmail and formail

I have noticed alot of people talking about mail header inections this past week. I have actually had a run in with this on one of my servers this last week too. On one of our servers where we host around 50 clients I have recieved in the neighboorhood of 7000 delivery failure notices to the server’s postmaster account. Almost all of them being failed spam messages. I was told that sendmail client on the server was for sure configured such that it couldn’t be used directly via smtp as an open relay, which means the e-mails were most likely coming from a compromised mail form script. So I spend an entire day tracking all of them down and patching them. I was pretty sure I got them all, but then the next day I got a bunch more failures which dated the original e-mail about 26 hours after the holes were all patched.

So, I was trying to think of a way to be able to monitor the php mail() so I can have it flag me when it detects possible spam being sent with it. Then I was reminded of an article fom the November 2005 php|architect by Ben Ramsey title mail() hacks. The article basically looks at various ways to intercept the mail() function for site testing purposes. So I am now using a variant of the same technique to catch spam being sent through php.

Php allows you to specify the path of your sendmail program via the sendmail_path ini option. Whatever program this points to is then passed a formatted e-mail message (with headers) via its STDIN whenever the php mail() program is called. So simply put you can swap out any program/script for sendmail to allow you to log e-mails, redirect it, or even modify it’s headers.

A while ago I wrote a script that I use with my servers’ postmaster accounts to notify me whenever there are any serious problems. This lets me know when there are any abnormalities (a large number of delivery failures, missing accounts, server errors, reports etc.) without me ever actually having to sift through each an every e-mail. So I figured it would be fairly trivial to just add some logic in there to sift through mail submitted via the mail() functions. The only problem was to find a way to intercept the messages.

Unix has a handy little program called formail (yes with one ‘m’) that makes it extremely easy to edit an email’s headers via the command line. So using this program I am now able to add a Bcc line with my address to any function sent with mail. In order to make it easy for my script to determine which e-mails come from php I am also adding a custom header: "x-php-formmail: yes." Also since I amp having a severe problem with injections I have taken the extra, temporary step of removing all other Bcc Addresses but my own and moving them to a different custom header.

The script looks like this:

Eventually, once I am sure that I have all the holes patched I will remove the ‘-R bcc x-original-bcc’ and at that point usage of this script will be completely transparent from a programming perspective.

Curse the spammers.

For those of you who would like more information about mail header injections I found this site. It has some pretty decent information: What they are, how they happen, how you fix them, it’s all covered.

Chris Shiflett also did a podcast with Marcus Whitney recently about mail header injections.

Then of course there is always the good ‘ole php manual. The comments have quite a bit to say about mail header injections. However, I recommend caution when reading through them, as always there of some good recommendations and some very, very bad recommendations.

Late Static Binding in PHP

I have just sent an e-mail to the internals list for PHP that implements late static binding. Many of you probably remember hearing about all of this a few months ago not too long after the Zend Framework webcast where they showed off an API that appeared to be somewhat impossible to create short of some poor hacks with terrible performance.

A good summary of the problem this patch fixes can be found on Joshua Eichorns blog: http://blog.joshuaeichorn.com/archives/2006/01/09/zactiverecord-cant-work/

So, for a more detailed summary :) of why this doesn’t work yet.

Take the following code:

The above code seems fairly straight forward. What happens behind the scenes is that a Foo class is created and has the static function added to it’s function table (among other things.) At that time the class Foo is also added to the Foo::test function struct that is added to that table. So, the when Foo::test() is called, the engine looks for the Foo class, finds the test function in Foo’s function table and executes it.

So, when Bar is defined, it creates the Bar class. Then it notices that Bar extends foo and adds all of Foo’s functions, properties, and what not to the function table, property table, etc. Now, when this is done no additional changes are made to the Foo::test function struct to show that there is a new class (Bar) that can call it. So when you call Bar::test() it will find Bar, and find Foo::test but when the test function is ran no information is passed to the function to let it know that Bar was the class that called it. To put it more succinctly, Foo and Bar both know about ::test, but ::test has no idea who Bar is. The function will always execute in Foo’s class scope. So self:: always calls Foo::. Now, this isn’t always a problem. The only time it becomes an issue is if you have an inherited static function that wants to call another static function, static property, or constant that has been redefined in a child class.

The change I made basically allows the engine to store the class calling the static function. The caller can then be accessed using ‘static’ (as opposed to self.) This should open the door to many other framework implementation possibilities (First thing that comes to mind for me is a Rubyish Active Record object.)

So, if you take part in the PHP-DEV mailing list and you want late-static-binding let them know.

TAP Compliant PHP Testing Harness

I have been doing a fair bit of thinking concerning testing over the last couple of days. This was partially driven by a couple of emails Paul and I have sent back and forth as well as a posting in his blog. I am of course a big proponent of TAP. I think it provides alot of possibilities for integrating the current libraries that offer TAP support (test-more.php, SimpleTest + TAP-Reporter, PHPUnit2.) However, having libraries that support TAP compliant output are honestly of little extra value if there isn’t a way to read it and subsequently aggregate the data.

TAP Compliancy allows you to use any framework/harness that supports TAP. However, to date, the only harness I could find for reading TAP was perl’s Test::Harness and the only framework was Apache-Test. Now, I will be the first to admit that there is a fairly steep learning curve when it comes to using Apache-Test. Once you get the hang of it, things get pretty simple. Getting the hang of it though tends to be a problem. Because of this I thought it was time for someone to create a harness in php that is capable of being used to build a framework.

So, I spent my free time the last couple of days working on such an item and this is what I came up with: test-harness.php

This is a very rough first draft, if you will. I have successfully used it to run a 1,000 file testing suite that I use for my firm’s internal API. It should be stated immediatly that my goal is NOT to mimic Test::Harness. My goal is to simply provide another option for people to use in their testing.

It is fairly simple to use. All you need to do is place it in your tests’ folder, make a few configuration changes (if necessary) and you will be ready to go. The script does depend on your test-files being self sustaining (to a point) and they must also output TAP compliant results. So basically if you can run your individual test files from the command line you should be alright.

There are three different configuration settings that need to be looked at. They can all be found at the top of the test-harness.php file. The first one is the TAP_PHP_CLI constant. This simple needs to be the path to your php-cli. The second one is TAP_PHP_CLI_ARGS. This can be used to pass command line arguments straight to php. I anticipate (as the default value shows) that this will be used most often to set the include_path for the testing scripts. The final setting is the $_EXCLUDE_FILES array. This is used to specify which files the harness should ignore when cycling through the directories. test-harness.php should of course always be set. I have also set test-more.php as I was using this library for most of my testing.

Here is a brief list of the current features:

  • Executes each test file in its own environment. This is accomplished by executing each test seperatly in it’s own php-cli process.
  • Supports the full TAP protocol. Currently there is no PHP library (afaik) that fully supports TAP however I do know there are plans to enable this in at least test-more.php. So when that happens the harness will be ready.
  • Supports Multiple levels of verbosity. -s will not output anything (this can be used in automated build processes when you only need to know if the tests as a whole pass or fail.) –detail will output the overall test results as well as the TAP output of each test. By default only the overall pass/fail result of each file and a summary of failed tests, skipped tests, and bonus tests are displayed.
  • Uses a return value to indicate overall success or fail. The program will return 1 on success and 0 on fail.

This is the first version of this file and I plan on releasing many more in the very near future. Some features I have in mind for the future are:

  • Better test filtering. Executing every file in the directory is just not always the best way to do things. I would like to set it so that only *.php (and maybe *.phpt) files are run as well as maybe introducing a default directory to store php files that aren’t to be tested. Basically I want to get rid of the $_EXCLUDE_FILES array.
  • Support for running the harness over http and recieving pretty output.
  • Make the script more interactive (optionally for the cli)
  • There is also a host of additional features that I scribbled down on a notepad. If anybody else has any good ideas you are more than welcome to post them.