Question

I’ve tried to include as much info in this post as possible.

I’m using Postfix on an Amazon EC2 Ubuntu server and it seems that a PHP script I have aliased to an address isn’t firing. Mailing works fine but the script just isn’t firing. I’ve probably missed something easy and would appreciate any other ideas with this.

The code below is that of the script. At the moment it is just a basic script to write to a file the contents of php://stdin. I’m not sure if this is the best way to write this script but it seems to be ok for now as it’s just a temporary one to use for troubleshooting this problem.

#!/usr/bin/php -q
<?php
$data = '';
$fileName = "parsedData.txt";
$stdin = fopen('php://stdin', 'r');
$fh = fopen($fileName, 'w');
while(!feof($stdin))
{
     $data .= fgets($stdin, 8192);
}
fwrite($fh, $data);
fclose($stdin);
fclose($fh);
?>

I have verified this works by passing it a .txt file containing some text.

./test2.php < data.txt

Now that my PHP script seems to work fine locally, I need to make sure it is being called correctly. sudo chmod 777 has been run on the test2.php script. Here is the relevant /etc/aliases file entry.

test: "|/usr/bin/php -q /var/test/php/test2.php"

I run newaliases every time I change this. This seems to be the most correct syntax as it specifies the location of php fully. test@mydomain receives emails fine from both internal and external when it is not set to be aliased. According to syslog this is successfully delivered to the command rather than maildir.

postfix/local[2117]: 022AB407CC: to=<[e-mail]>, relay=local, delay=0.5, delays=0.43/0.02/0/0.05, dsn=2.0.0, status=sent **(delivered to command: /usr/bin/php -q /var/test/php/test2.php)**

The alias has also been written in the following ways without success (either because they go to maildir instead of the command due to wrong syntax or the script just isn’t firing).

test: |"php -q /var/test/php/test2.php"
test: "|php -q /var/test/php/test2.php"
test: |"/usr/bin/php -q /var/test/php/test2.php"
test: "| php -q /var/test/php/test2.php"
test: "|/var/test/php/test2.php"
test: |"/var/test/php/test2.php"

The relevent part of my postfix main.cf files looks like this –

myhostname = domainnamehere.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = domainnamehere.com, internalawsiphere, localhostinternalaws, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command =
home_mailbox = Maildir/
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

I had error_log("script has started!"); at the beginning of test2.php so that it would appear in the php log file if the script was successfully being called. I made sure to go into the php.ini to turn on error_logging and specify a location for it to save to but I couldn’t get this to work. It would help to be able to get this to work because I could tell if the script was failing when it go to the php://stdin function as there may be some problem with it handling emails rather than cat’ed .txt files.

My end goal is to get a service that will save emails on a certain addresss, with their attachments, to a MySQL database and then return a unique code for each file/email to the user. Is there an easier way to do something like this than use php scripts? does something like squirrelmail or dbmail do this?

I’ve completely exhausted my ideas with this one. Maybe I should just try another email service?

Oh wise people of StackOverflow, help me!

Answer 1

First things first, chmod 777 <foo> is almost always a gigantic mistake. I recognize that you’re in a state of desperation — as indicated by the fact that you ran this command. You want to configure your systems with the least amount of required privilege for each portion of the system to properly do its job. This helps prevent security breaches and reduces needless coupling. But executable files should not be writable by anyone except the executable owner — and even then, I strongly recommend against it.

Now, onto your problem:

#!/usr/bin/php -q
<?php
$data = '';
$fileName = "parsedData.txt";

You’re referring to a file using a relative pathname. This is fine, if you’re always confident of the directory in which it starts, or if you want the user to be in control of the directory in which it starts, but it is usually a bad idea for automated tools. The /etc/aliases mechanism may run the aliased commands in the postfix home directory, it might pick an empty directory in /var created just for the purpose, and future releases are more or less free to change this behavior as they wish. Change this path name to an absolute pathname showing exactly where you would like this file to be created — or insert an explicit chdir() call at the start of your script to change directories to exactly where you want your data to go.

Next:

$fh = fopen($fileName, 'w');
while(!feof($stdin))
{
     $data .= fgets($stdin, 8192);
}
fwrite($fh, $data);

You did not ensure that the file was actually opened. Check those return values. They will report failure for you very quickly, helping you find bugs in your code or local misconfigurations. I do not know PHP well enough to tell you the equivalent of the perror(3) function that will tell you exectly what failed, but it surely can’t be too difficult to get a human-readable error code out of the interpreter. Do not neglect the error codes — knowing the difference between Permission Denied vs File or directory not found can save hours once your code is deployed.

And, as Michael points out, a mandatory access control tool can prevent an application from writing in specific locations. The “default” MAC tool on Ubuntu is AppArmor, but SELinux, TOMOYO, or SMACK are all excellent choices. Run dmesg and look in /var/log/audit/audit.log to see if there are any policy violations. If there are, the steps to take to fix the problem vary based on which MAC system you’re using. Since you’re on Ubuntu, AppArmor is most likely; run aa-status to get a quick overview of the services that are confined on your system, and aa-logprof should prompt you to modify policy as necessary. (Don’t blindly say “Allow”, either — perhaps active exploit attempts have been denied.)

(If you aren’t using a MAC system already, please consider doing so. I’ve worked on the AppArmor project for twelve years and wouldn’t consider not confining all applications that communicate over the network — but that’s my own security needs. More paranoid people may wish to confine more of their systems, less paranoid people may wish to confine less of their systems.)