# mail() logging for PHP

- Thread: https://externals.io/message/26940
- Original archive: https://news-web.php.net/php.internals/26940
- Started by Ilia Alshanetsky on 2006-12-13T21:51:08+00:00
- Messages: 20
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #26940 — Ilia Alshanetsky — 2006-12-13T21:51:08+00:00

URL: https://externals.io/message/26940#26940

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

---

## #26941 — Stut — 2006-12-13T22:12:24+00:00

URL: https://externals.io/message/26940#26941 · In reply to: #26940

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

---

## #26942 — Ilia Alshanetsky — 2006-12-13T22:48:38+00:00

URL: https://externals.io/message/26940#26942 · In reply to: #26941

> Ilia Alshanetsky wrote:
> > […]
>
> 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

---

## #26943 — Stut — 2006-12-13T22:53:21+00:00

URL: https://externals.io/message/26940#26943 · In reply to: #26942

Ilia Alshanetsky wrote:
> 
> 
> 
> > […]
> 
> Only in the log file, for the header only the filename is included, so 
> there is no security risk here.
> 
> > […]
> 
> 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

---

## #26944 — Ilia Alshanetsky — 2006-12-13T22:58:21+00:00

URL: https://externals.io/message/26940#26944 · In reply to: #26943

> 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

---

## #26947 — Mike Robinson — 2006-12-14T02:53:50+00:00

URL: https://externals.io/message/26940#26947 · In reply to: #26940

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

---

## #26953 — Sander Steffann — 2006-12-14T10:21:43+00:00

URL: https://externals.io/message/26940#26953 · In reply to: #26940

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

---

## #26949 — Markus Fischer — 2006-12-14T10:43:07+00:00

URL: https://externals.io/message/26940#26949 · In reply to: #26944

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

Ilia Alshanetsky wrote:
> > […]
> 
> 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

---

## #26950 — Stut — 2006-12-14T11:04:34+00:00

URL: https://externals.io/message/26940#26950 · In reply to: #26949

Markus Fischer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ilia Alshanetsky wrote:
>   
> > […]
>
> 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

---

## #26954 — Sander Steffann — 2006-12-14T11:16:57+00:00

URL: https://externals.io/message/26940#26954 · In reply to: #26949

Hi,

> > […]
>
> 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!

---

## #26960 — Rick Widmer — 2006-12-14T17:29:04+00:00

URL: https://externals.io/message/26940#26960 · In reply to: #26950

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.

---

## #26962 — Richard Lynch — 2006-12-14T20:45:58+00:00

URL: https://externals.io/message/26940#26962 · In reply to: #26960

> > […]
>
> 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?

---

## #26963 — Richard Lynch — 2006-12-14T20:48:22+00:00

URL: https://externals.io/message/26940#26963 · In reply to: #26953

> > […]
>
> 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?

---

## #26964 — Ilia Alshanetsky — 2006-12-14T20:50:22+00:00

URL: https://externals.io/message/26940#26964 · In reply to: #26963

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

---

## #27909 — mgagne@generationphp.net — 2007-02-08T15:44:56+00:00

URL: https://externals.io/message/26940#27909 · In reply to: #26964

Hi,

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

Mathieu


> 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

---

## #27910 — mgagne@generationphp.net — 2007-02-08T15:45:14+00:00

URL: https://externals.io/message/26940#27910 · In reply to: #26964

Hi,

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

Mathieu


> 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

---

## #27912 — Ilia Alshanetsky — 2007-02-08T15:50:39+00:00

URL: https://externals.io/message/26940#27912 · In reply to: #27909

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

Ilia




> Hi,
>
> Any news about it?
> This would be very interesting having this feature.
> As Richard Lynch said, ISPs would love it.
>
> Mathieu
>
> 
> > […]

Ilia Alshanetsky

---

## #27947 — Derick Rethans — 2007-02-09T16:33:13+00:00

URL: https://externals.io/message/26940#27947

> 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

---

## #29205 — mgagne@generationphp.net — 2007-05-05T04:39:58+00:00

URL: https://externals.io/message/26940#29205 · In reply to: #27912

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

---

## #29207 — Ilia Alshanetsky — 2007-05-05T14:54:08+00:00

URL: https://externals.io/message/26940#29207 · In reply to: #29205

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




> Hi,
>
> Ilia Alshanetsky wrote:
> > […]
>
> There is no trace of such patch in PHP 5.2.2 changelog.
> Any news on it? Thanks.
>
> Mathieu

Ilia Alshanetsky