Everything

php

mail() logging for PHP

php.internals

Ilia A.

19 years ago

Is there any interest in adding support for logging of mail() calls
and/or adding options that allow identification of who sent the e-mail.

I've wrote a quick patch that enables this functionality via two ini
settings controllable via php.ini or per-virtual host.

The first option, mail.add_x_header (boolean) allows you to enable
the addition of the X-PHP-Originating-Script header to each mail sent
by mail(), which will include the uid of the script and its name. The
combination of the two should be sufficient to identify the user to
whom the script belongs and via a simple find command locate the
actual script. This option is intended primarily for instances where
you have a bounced e-mail or a forwarded mail with a spam complaint,
allowing you to quickly identify the offender.

The second option, mail.log (takes a filename) allows you to enable
logging of every single mail() call, each log line will include the
fullpath of the file and the line where the mail() was called from in
addition to the "To" address and any headers (to keep track of CC,
BCC) that were part of the function call. To ensure that each log
line is 1 line long, \r and \n are replaced with spaces.

The patch that makes this possible can be found here:

http://ilia.ws/uploads/patches/mail_log.txt.gz

Ilia Alshanetsky

Stut

19 years ago

Ilia Alshanetsky wrote:

> Is there any interest in adding support for logging of mail() calls
> and/or adding options that allow identification of who sent the e-mail.
>
> I've wrote a quick patch that enables this functionality via two ini
> settings controllable via php.ini or per-virtual host.
>
> The first option, mail.add_x_header (boolean) allows you to enable the
> addition of the X-PHP-Originating-Script header to each mail sent by
> mail(), which will include the uid of the script and its name. The
> combination of the two should be sufficient to identify the user to whom
> the script belongs and via a simple find command locate the actual
> script. This option is intended primarily for instances where you have a
> bounced e-mail or a forwarded mail with a spam complaint, allowing you
> to quickly identify the offender.
>
> The second option, mail.log (takes a filename) allows you to enable
> logging of every single mail() call, each log line will include the
> fullpath of the file and the line where the mail() was called from in
> addition to the "To" address and any headers (to keep track of CC, BCC)
> that were part of the function call. To ensure that each log line is 1
> line long, \r and \n are replaced with spaces.
>
> The patch that makes this possible can be found here:
>
> http://ilia.ws/uploads/patches/mail_log.txt.gz

Yes, yes, yes, a thousand times yes. I'm assuming the filename is the
full path and filename? Couldn't that be considered a security risk?

IMHO it would be better to have an option that would provide the domain
name and the filename relative to the site root (if available).

Also, I'm assuming this is configurable via php_flag in an Apache
configuration file?

-Stut

Ilia A.

19 years ago

On 13-Dec-06, at 5:12 PM, Stut wrote:

> Ilia Alshanetsky wrote:
>> Is there any interest in adding support for logging of mail()
>> calls and/or adding options that allow identification of who sent
>> the e-mail.
>> I've wrote a quick patch that enables this functionality via two
>> ini settings controllable via php.ini or per-virtual host.
>> The first option, mail.add_x_header (boolean) allows you to enable
>> the addition of the X-PHP-Originating-Script header to each mail
>> sent by mail(), which will include the uid of the script and its
>> name. The combination of the two should be sufficient to identify
>> the user to whom the script belongs and via a simple find command
>> locate the actual script. This option is intended primarily for
>> instances where you have a bounced e-mail or a forwarded mail with
>> a spam complaint, allowing you to quickly identify the offender.
>> The second option, mail.log (takes a filename) allows you to
>> enable logging of every single mail() call, each log line will
>> include the fullpath of the file and the line where the mail() was
>> called from in addition to the "To" address and any headers (to
>> keep track of CC, BCC) that were part of the function call. To
>> ensure that each log line is 1 line long, \r and \n are replaced
>> with spaces.
>> The patch that makes this possible can be found here:
>> http://ilia.ws/uploads/patches/mail_log.txt.gz
>
> Yes, yes, yes, a thousand times yes. I'm assuming the filename is
> the full path and filename? Couldn't that be considered a security
> risk?

Only in the log file, for the header only the filename is included,
so there is no security risk here.

> IMHO it would be better to have an option that would provide the
> domain name and the filename relative to the site root (if available).
>
> Also, I'm assuming this is configurable via php_flag in an Apache
> configuration file?

It can be controlled via httpd.conf but not via .htaccess.

Ilia Alshanetsky

Stut

19 years ago

Ilia Alshanetsky wrote:

>
> On 13-Dec-06, at 5:12 PM, Stut wrote:
>
>> Ilia Alshanetsky wrote:
>>> Is there any interest in adding support for logging of mail() calls
>>> and/or adding options that allow identification of who sent the e-mail.
>>> I've wrote a quick patch that enables this functionality via two ini
>>> settings controllable via php.ini or per-virtual host.
>>> The first option, mail.add_x_header (boolean) allows you to enable
>>> the addition of the X-PHP-Originating-Script header to each mail sent
>>> by mail(), which will include the uid of the script and its name. The
>>> combination of the two should be sufficient to identify the user to
>>> whom the script belongs and via a simple find command locate the
>>> actual script. This option is intended primarily for instances where
>>> you have a bounced e-mail or a forwarded mail with a spam complaint,
>>> allowing you to quickly identify the offender.
>>> The second option, mail.log (takes a filename) allows you to enable
>>> logging of every single mail() call, each log line will include the
>>> fullpath of the file and the line where the mail() was called from in
>>> addition to the "To" address and any headers (to keep track of CC,
>>> BCC) that were part of the function call. To ensure that each log
>>> line is 1 line long, \r and \n are replaced with spaces.
>>> The patch that makes this possible can be found here:
>>> http://ilia.ws/uploads/patches/mail_log.txt.gz
>>
>> Yes, yes, yes, a thousand times yes. I'm assuming the filename is the
>> full path and filename? Couldn't that be considered a security risk?
>
> Only in the log file, for the header only the filename is included, so
> there is no security risk here.
>
>> IMHO it would be better to have an option that would provide the
>> domain name and the filename relative to the site root (if available).
>>
>> Also, I'm assuming this is configurable via php_flag in an Apache
>> configuration file?
>
> It can be controlled via httpd.conf but not via .htaccess.

Excellent.

I'm thinking about this from an ISP point of view... we get a lot of
abuse reports because people have poorly written form handlers. It would
be great if we could have PHP insert the full URL, domain name included,
in the mail headers for anything it sends. Would that be possible?

I know that would only affect emails sent using the mail function, but
it would be a massive improvement from where we are today.

-Stut

Ilia A.

19 years ago

On 13-Dec-06, at 5:53 PM, Stut wrote:

> I'm thinking about this from an ISP point of view... we get a lot
> of abuse reports because people have poorly written form handlers.
> It would be great if we could have PHP insert the full URL, domain
> name included, in the mail headers for anything it sends. Would
> that be possible?

That is way too much information to include into an e-mail header,
this would in fact be information disclosure vulnerability in many
eyes. The log file that you can enable provides you with the full
path to the script that called mail, which is more then enough to
identify the offending script and/or application.


Ilia Alshanetsky

Markus Fischer

19 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ilia Alshanetsky wrote:

>> I'm thinking about this from an ISP point of view... we get a lot of
>> abuse reports because people have poorly written form handlers. It
>> would be great if we could have PHP insert the full URL, domain name
>> included, in the mail headers for anything it sends. Would that be
>> possible?
>
> That is way too much information to include into an e-mail header, this
> would in fact be information disclosure vulnerability in many eyes. The
> log file that you can enable provides you with the full path to the
> script that called mail, which is more then enough to identify the
> offending script and/or application.

In case someone would use a library installed on the server were the
mail() call e.g. in /usr/lib/PEAR/lib/php/Mail/Transport/PHP_Mail.php
(just an example) would this really help identifying the cause of the
problem? No Domain, no URL, I think it would be hard to determine who
used it.

- - Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFgSq71nS0RcInK9ARAsKzAJ4opZQlVwJD3YsKIiJeG+QanQBOgwCbBtcH
uzEyiEawrJwz+b0JTmaz9wc=
=PVjq
-----END PGP SIGNATURE-----

Stut

19 years ago

Markus Fischer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ilia Alshanetsky wrote:
>
>>> I'm thinking about this from an ISP point of view... we get a lot of
>>> abuse reports because people have poorly written form handlers. It
>>> would be great if we could have PHP insert the full URL, domain name
>>> included, in the mail headers for anything it sends. Would that be
>>> possible?
>>>
>> That is way too much information to include into an e-mail header, this
>> would in fact be information disclosure vulnerability in many eyes. The
>> log file that you can enable provides you with the full path to the
>> script that called mail, which is more then enough to identify the
>> offending script and/or application.
>>
>
> In case someone would use a library installed on the server were the
> mail() call e.g. in /usr/lib/PEAR/lib/php/Mail/Transport/PHP_Mail.php
> (just an example) would this really help identifying the cause of the
> problem? No Domain, no URL, I think it would be hard to determine who
> used it.

Cracking point. Putting the domain in a header would make this far more
useful, and I don't think that's too much info to include in a header.
Ideally it would be the full URL, and I have to say that I don't think
that's too much information for a mail header, and it's exactly what
would be needed.

-Stut

Rick Widmer

19 years ago

Stut wrote:

> Cracking point. Putting the domain in a header would make this far more
> useful, and I don't think that's too much info to include in a header.
> Ideally it would be the full URL, and I have to say that I don't think
> that's too much information for a mail header, and it's exactly what
> would be needed.

I agree.  The most useful information you can possibly put in the header
is the full URL of the script that sent the message.

Richard Lynch

19 years ago

On Thu, December 14, 2006 11:29 am, Rick Widmer wrote:

>> Cracking point. Putting the domain in a header would make this far
>> more
>> useful, and I don't think that's too much info to include in a
>> header.
>> Ideally it would be the full URL, and I have to say that I don't
>> think
>> that's too much information for a mail header, and it's exactly what
>> would be needed.
>
> I agree.  The most useful information you can possibly put in the
> header
> is the full URL of the script that sent the message.

So if it's a cronjob in a shell script, what do you get?...

The full path to the script?

Just askin', not trying to score points or anything.

I suspect ISPs would LOVE to have this.

I know my ISP had to write a perl script to search all his clients'
source for calls to mail() and then patched their PHP scripts for them
to shut down the huge surge of header-injections awhile back.

He emailed us all and told us what he did, and I daresay most of his
clients had no idea what he was talking about, but were happy to let
him fix their scripts to help fight spam.

If it defaults to "off" and the host turns it "on" and that opens up
the security hole of exposing the inner workings of a site...

This does need some consideration, I think, but I suspect 99.9% of
installations would love this feature, and it wouldn't expose anything
at all that isn't already exposed -- And most of the remaining 0.1%
would be run by people who have half a clue and understand the
implications of turning it on in the first place.

Or are y'all thinking default it to "on" in future releases?

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Sander Steffann

19 years ago

Hi,

>> That is way too much information to include into an e-mail header, this
>> would in fact be information disclosure vulnerability in many eyes. The
>> log file that you can enable provides you with the full path to the
>> script that called mail, which is more then enough to identify the
>> offending script and/or application.
>
> In case someone would use a library installed on the server were the
> mail() call e.g. in /usr/lib/PEAR/lib/php/Mail/Transport/PHP_Mail.php
> (just an example) would this really help identifying the cause of the
> problem? No Domain, no URL, I think it would be hard to determine who
> used it.

True. Maybe adding both the main-script-name and the name of the script that
contains the mail() call might be a good idea. Another solution would be to
apply encryption to the information. Then you could put much more
information in the extra header without disclosing anything. You could even
put all this in:
- Timestamp
- Server hostname
- IP address of the client invoking the script
- Requesting URL, including query string
- Full path+filename of the main script
- Full path+filename of the script that calls mail()
- etc

Put all this is a nice text, encrypt it (i.e. 3DES, or even RSA/DSA), base64
encode it, and add it in a header. The header might be a little big, but I
don't think that will be a big problem for those who want to use it.

A small example:

Put the following information in the extra header:

1166094481
www.computel.nl
83.137.22.2
http://www.computel.nl/stuff/bla.php?mailto=sander@steffann.nl
/var/www/sites/www.computel.nl/stuff/bla.php
/usr/lib/PEAR/lib/php/Mail/Transport/PHP_Mail.php

Encrypt this with 3des, using password 'something'. (the password could be
configured in php.ini, or per virtual host):

U2FsdGVkX18+F3ghXdsE6Wkv0mJwtes2Ue0jMHrKfM+vNODH592rrEMZpDdbPtIe
vkSnERInTNA86XqZQtlQV+JJneAJexeNWKqhxRh+QHSsishzrq0+l9gfhu9G06LR
X3SrZCXtg9irvGIdA1OD5sDkUi7NJTJ7GnrJd6fnrv3wGZTAQlwjIeFm7LRSl8N+
tpkQckXfXYhVzOkGMU6/InE9q3Wo228wkazmXZKW1k1GVYtXPJL7f0JS9DMa3gEr
lJR5rnZqNcBVtCW6eVVl9jYU2g58bZLV

This can be put directly into a header in the message. The total extra
message size would be about 300 bytes. That should be no problem at all. I
have seen bigger received: headers in a message.

I think this would help a system admin a lot when trying to figure out where
all those annoying messages are coming from. What do the rest of you think
about this?

Thanks,
Sander

PS: If you need help implementing it, let me know!

Mike Robinson

19 years ago

Ilia Alshanetsky writes:

> Is there any interest in adding support for logging of mail()
> calls and/or adding options that allow identification of who
> sent the e-mail.
>
> I've wrote a quick patch that enables this functionality via
> two ini settings controllable via php.ini or per-virtual host.
>
> The first option, mail.add_x_header (boolean) allows you to
> enable the addition of the X-PHP-Originating-Script header to
> each mail sent by mail(), which will include the uid of the
> script and its name. The combination of the two should be
> sufficient to identify the user to whom the script belongs
> and via a simple find command locate the actual script. This
> option is intended primarily for instances where you have a
> bounced e-mail or a forwarded mail with a spam complaint,
> allowing you to quickly identify the offender.
>
> The second option, mail.log (takes a filename) allows you to
> enable logging of every single mail() call, each log line
> will include the fullpath of the file and the line where the
> mail() was called from in addition to the "To" address and
> any headers (to keep track of CC,
> BCC) that were part of the function call. To ensure that each
> log line is 1 line long, \r and \n are replaced with spaces.
>
> The patch that makes this possible can be found here:
>
> http://ilia.ws/uploads/patches/mail_log.txt.gz
>
> Ilia Alshanetsky

A fabulous addition. How fast can this make it into PHP? 5.2.1?   8-)

Best,

Mike Robinson

Sander Steffann

19 years ago

Hi Ilia,

> Is there any interest in adding support for logging of mail() calls
> and/or adding options that allow identification of who sent the e-mail.
>
> I've wrote a quick patch that enables this functionality via two ini
> settings controllable via php.ini or per-virtual host.

Hehe. I was just starting to work on exactly the same, Thanks for saving me
the work :)  So, yes, I would realy like this extra logging!

Thanks!
Sander

Richard Lynch

19 years ago

On Thu, December 14, 2006 4:21 am, Sander Steffann wrote:

>> Is there any interest in adding support for logging of mail() calls
>> and/or adding options that allow identification of who sent the
>> e-mail.
>>
>> I've wrote a quick patch that enables this functionality via two ini
>> settings controllable via php.ini or per-virtual host.
>
> Hehe. I was just starting to work on exactly the same, Thanks for
> saving me
> the work :)  So, yes, I would realy like this extra logging!

Would the logfile also include the Message-ID generated by SMTP or
sendmail or whatever?...

I should think that for fixing broken scripts that accidentally leak,
this would be very useful.

Obviously for somebody intentionally spamming, it's not all that, as
they probably are messing with Message-ID as well.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Ilia A.

19 years ago

The full path is only for the log files, the header only contains the
script name. As far as requests to include the domain name, we cannot
do it reliably. In some instances value can be fakes or outright
injected by the user, nor will this be at all useful for scripts
running on the command line.

Ilia

Mathieu Gagné

19 years ago

Hi,

Any news about it?
This would be very interesting having this feature.
As Richard Lynch said, ISPs would love it.

Mathieu

On 2006-12-14 15:50, Ilia Alshanetsky wrote:

Ilia A.

19 years ago

I am going to finalize the patch and add it to 5.2.2 in the coming
weeks.

Ilia

On 8-Feb-07, at 10:44 AM, Mathieu Gagné wrote:

> Hi,
>
> Any news about it?
> This would be very interesting having this feature.
> As Richard Lynch said, ISPs would love it.
>
> Mathieu
>
> On 2006-12-14 15:50, Ilia Alshanetsky wrote:
>> The full path is only for the log files, the header only contains
>> the script name. As far as requests to include the domain name, we
>> cannot do it reliably. In some instances value can be fakes or
>> outright injected by the user, nor will this be at all useful for
>> scripts running on the command line.
>> Ilia

Ilia Alshanetsky

Mathieu Gagné

19 years ago

Hi,

Thanks for the update! Much appreciated.
Is there any chances to get this patch for PHP 4.x too?

Mathieu

On 2007-02-08 10:50, Ilia Alshanetsky wrote:

Derick Rethans

19 years ago

On Thu, 8 Feb 2007, Mathieu Gagné wrote:

> Hi,
>
> Thanks for the update! Much appreciated.
> Is there any chances to get this patch for PHP 4.x too?

Depends a bit on how much of a change it is. If it touches almost no
exsisting code we might want to consider it.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Francois Saint-Jacques

19 years ago

This is the tip of the iceberg. We're facing the problem with spam and
php inclusion on a mass-hosting server. Not only I want to know how many
times mail() was called but other dangerous function too!
(exec,system,mail,etc...)


What would be nice is a variable similar to "disable_functions", like this:

log_functions="mail, exec, system, etc..."
log_file="/var/log/apache/php-calls.log"

This could log: date, parameters, http-host. It would make post-hacking
intrusion much easier to debug...

Frank

Ilia Alshanetsky a écrit :

Mathieu Gagné

19 years ago

Hi,

Ilia Alshanetsky wrote:

> I am going to finalize the patch and add it to 5.2.2 in the coming weeks.
>
> Ilia

There is no trace of such patch in PHP 5.2.2 changelog.
Any news on it? Thanks.

Mathieu

Ilia A.

19 years ago

It did not make it into 5.2.2, it will be in 5.3 most likely.

On 5-May-07, at 12:39 AM, Mathieu Gagné wrote:

> Hi,
>
> Ilia Alshanetsky wrote:
>> I am going to finalize the patch and add it to 5.2.2 in the coming
>> weeks.
>> Ilia
>
> There is no trace of such patch in PHP 5.2.2 changelog.
> Any news on it? Thanks.
>
> Mathieu

Ilia Alshanetsky

Mathieu Gagné

19 years ago

Hi,

Any news about it?
This would be very interesting having this feature.
As Richard Lynch said, ISPs would love it.

Mathieu

On 2006-12-14 15:50, Ilia Alshanetsky wrote: