log emails sent using mail()

[jasonc]

I have been asked by a mate to fix his scripts he has bought as it contains coding that sems to be sending out spam!

 

There are way too many to search them all so I hope to opt for a simpler way like tracking the mail send using the PHP mail() method which is the only way i can think the mail is being sent.

 

can this be done?

 

[hitman6003]

Assuming you are using Unix, change the sendmail_path or mail.force_extra_parameters variable(s) in php.ini to silently include a bcc

[steviewdr]

This works fine in a production environment:

 

Edit your php.ini and change to the following:

sendmail_path ="/usr/sbin/sendmail_wrapper"

 

Then create the following file: /usr/sbin/sendmail_wrapper with this in it:

#!/bin/sh

logger -p mail.info vhostmail: site=${HTTP_HOST}, client=${REMOTE_ADDR}, script=${SCRIPT_NAME}

/usr/sbin/sendmail -t -i $*

 

Chmod 755 /usr/sbin/sendmail_wrapper

 

Your off. Tail /var/log/mail.info for a log of email sent via php's mail().

 

-steve

 

[forethought]

I'm having the same problems as the original poster, and I followed steviewdr's advice, but my maillog file shows this entry whenever PHP sends email:

 

logger: vhostmail: site=, client=, script=

 

Is there something I'm missing in regards to the environment variables?

[j4m32]

I would be very surprised if ${HTTP_HOST}, ${REMOTE_ADDR} and ${SCRIPT_NAME}

even exist as Environment Variables, I'm pretty sure you have to define them in the Shell Script else it returns NULL strings.

 

You'll have to work out what Arguments are taken by SendMail and in what order because it certainly appears to work by command line switches and arguments:

/usr/sbin/sendmail -t -i $*

 

That line tells me that it must be taking ALL Arguments parsed to the script by the Shell as the input because $* = $1 + $2 + $3 + $i ...

 

So, by total guess work and logic, I think it should have read along the lines of:

#!/bin/sh
logger -p mail.info vhostmail: site=$1, client=$2, script=$3
/usr/sbin/sendmail -t -i $*

 

If you want it to mean more sense you could do:

#!/bin/sh

set HOST=$1
set ADDR=$2
set SCRIPT=$3
set ARGS_SENDMAIL=$1 $2 $3

logger -p mail.info vhostmail: site=$HOST, client=$ADDR, script=$SCRIPT
/usr/sbin/sendmail -t -i $ARGS_SENDMAIL

 

and fidel until it returns correctly

 

Please correct if I'm totally wrong!  :-X

 

Jim,

[forethought]

It's weird, because it doesn't seem to pass any arguments to the script. If I do this:

 

logger -p mail.info vhostmail: site=${HTTP_HOST}, client=${REMOTE_ADDR}, script=${SCRIPT_NAME}, arguments=$#

 

I get in my maillog file:

 

logger: vhostmail: site=, client=, script=, arguments=0

 

And if I try to output everything:

 

logger -p mail.info vhostmail: site=${HTTP_HOST}, client=${REMOTE_ADDR}, script=${SCRIPT_NAME}, arguments=$*

 

I get:

 

logger: vhostmail: site=, client=, script=, arguments=

 

I've officially got no clue...  :-\

[trq]

It's weird, because it doesn't seem to pass any arguments to the script.

 

Its not wierd, because as has just been explained the variables ${HTTP_HOST}, ${REMOTE_ADDR} and ${SCRIPT_NAME} are not defined within your shell.

 

The only thing I can think of is you'll need to pass these variables concatinated together as the 5th argument to the mail() function. I would assume they will then show up in "${5}" in your sendmail_wrapper.

[forethought]

Its not wierd, because as has just been explained the variables ${HTTP_HOST}, ${REMOTE_ADDR} and ${SCRIPT_NAME} are not defined within your shell.

 

I know that, what I was saying was I found it weird that there are no arguments being passed to the script, not that the variables are not defined. I know they're not defined in the shell, they are environment variables specific to Apache, but this code was presented by one of the previous posters, and I'm unable to have it work the way it's intended to, and I'm trying to figure out why, mainly, how to pass these Apache specific environment variables to the shell script.

 

The only thing I can think of is you'll need to pass these variables concatinated together as the 5th argument to the mail() function. I would assume they will then show up in "${5}" in your sendmail_wrapper.

 

But I've tested this by trying to write "$#" (for the number of arguments passed to the wrapper), "$*" (for all arguments passed to the wrapper), and even "${1}" (what should be the first argument passed to the wrapper), and as I previously indicated, "$#" is "0" (no arguments passed), "$*" is "" (blank), as is "${1}".

[forethought]

Just had a moment of clarity, I don't think PHP calls whatever you have defined for "sendmail_path" in your php.ini file with arguments, I think it calls that program and then dumps the email data out on STDIN, which is why $* is blank. I changed the wrapper script to:

 

#!/bin/sh
logger -p mail.info vhostmail: site=${HTTP_HOST}, client=${REMOTE_ADDR}, script=${SCRIPT_NAME}
/usr/sbin/sendmail -t -i

 

With the same result, so now I'm still just trying to find out how to pass the Apache environment variable to my shell script, that's all.

[trq]

As I said earlier....

 

The only thing I can think of is you'll need to pass these variables concatinated together as the 5th argument to the mail() function.

 

The wrapper.

 

#!/bin/sh
logger -p mail.info vhostmail: site="${1}", client="${2}", script="${3}"
/usr/sbin/sendmail -t -i

 

 

Now, I'm not sure how usefull this is going to be because it means changing your calls to mail() within your scripts, but it works.

<?php

  mail('foo@foo.com','subject','message','',$_SERVER['HTTP_HOST'] . " " . $_SERVER['REMOTE_ADDRESS'] . " " . $_SERVER['SCRIPT_NAME']);

?>

[steviewdr]

I'm very sorry.

 

I missed one key line in my above config.

 

Edit your php.ini and add the following:

auto_prepend_file ="/etc/set_php_headers.php"

 

Then /etc/set_php_headers.php has:

<?php

putenv("HTTP_HOST=". $_SERVER["HTTP_HOST"]);

putenv("SCRIPT_NAME=". $_SERVER["SCRIPT_NAME"]);

putenv("REMOTE_ADDR=". $_SERVER["REMOTE_ADDR"]);

?>

 

Job done. Jab me here again if it still doesnt work.

 

-steve

[forethought]

Steve,

 

That did it, much obliged!