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
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 singlemail()call, each log line will include the
fullpath of the file and the line where themail()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:
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 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 bymail(), 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 singlemail()call, each log line will
include the fullpath of the file and the line where themail()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.gzYes, 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
Ilia Alshanetsky 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
bymail(), 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 singlemail()call, each log line will include the
fullpath of the file and the line where themail()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.gzYes, 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
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
-----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
- Markus
iD8DBQFFgSq71nS0RcInK9ARAsKzAJ4opZQlVwJD3YsKIiJeG+QanQBOgwCbBtcH
uzEyiEawrJwz+b0JTmaz9wc=
=PVjq
-----END PGP SIGNATURE
Markus Fischer wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Ilia 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
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.
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?
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!
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 bymail(), 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 singlemail()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
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
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?
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
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
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
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
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
It did not make it into 5.2.2, it will be in 5.3 most likely.
Hi,
Ilia Alshanetsky wrote:
I am going to finalize the patch and add it to 5.2.2 in the coming
weeks.
IliaThere is no trace of such patch in PHP 5.2.2 changelog.
Any news on it? Thanks.Mathieu
Ilia Alshanetsky
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