Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26962
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain l-i-e.com from 67.139.134.202 cause and error)
Message-ID: <4571.216.230.84.67.1166129158.squirrel@www.l-i-e.com>
In-Reply-To: <458189E0.4040700@developersdesk.com>
References: <10536315-883E-4C1A-AF35-386DF4D73F84@prohost.org>
    <45807AC8.8020907@gmail.com>
    <515375DA-C752-4F5D-A244-3394C56846DA@prohost.org>
    <45808461.9070505@gmail.com>
    <98F4FCCE-94A0-448D-AA27-EABF7E82A7DB@prohost.org>
    <45812ABB.4060309@fischer.name> <45812FC2.3050500@gmail.com>
    <458189E0.4040700@developersdesk.com>
Date: Thu, 14 Dec 2006 14:45:58 -0600 (CST)
To: "Rick Widmer" <vchkpw@developersdesk.com>
Cc: "PHP internals" <internals@lists.php.net>
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] mail() logging for PHP
From: ceo@l-i-e.com ("Richard Lynch")

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?