Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10226
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <019901c447ff$44956310$0200a8c0@rusko>
To: "Sara Golemon" <pollita@php.net>
Cc: <internals@lists.php.net>
References: <024e01c4464c$f8dbf500$0200a8c0@rusko> <200405301333.34754.ilia@prohost.org> <02c001c4466f$6aa3cb50$0200a8c0@rusko> <200405301407.19977.ilia@prohost.org> <02d801c44674$1a3d4470$0200a8c0@rusko> <20040601172614.5493.qmail@pb1.pair.com>
Date: Tue, 1 Jun 2004 13:38:36 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [patch] abuse-proof zif_mail()
From: paul@rusko.us ("Paul G")

sara,

----- Original Message ----- 
From: "Sara Golemon" <pollita@php.net>
To: <internals@lists.php.net>
Sent: Tuesday, June 01, 2004 1:06 PM
Subject: Re: [PHP-DEV] [patch] abuse-proof zif_mail()

--- snip ---

> The whole matter is moot because no matter how aggressively you block
access
> to mail(), sendmail, et. al.  The user can still make socket calls
directly
> using SMTP commands.  The protocol is not hard to understand and it's the
> neerdowells that you're talking about stopping not the innocent
accidentals.

i disagree. first off, at least on our setup, users can *try* to make socket
calls directly but it won't get them too far - we have iptables ACLs
preventing that. second off, the direct socket connections take more time
than calling sendmail and dumping it all in our spool and the abuser would
have to keep reloading the page (i know this can be automated) because of
the 30 second exec time limit. additionally, you could say that i care less
about them spewing directly than i care about them dumping twenty thousand
messages into our spool, when the relative effects on other clients' service
are considered. third off, this patch does not *stop* them per se, it just
helps us identify who is responsible so we can act on the abuse reports fast
enough not to get baclklisted by some maniac.

i am not arguing for making this the default, but quite honestly i do not
see a substantive reason not to make this a compile-time or a run-time
option. if there is a problem with the *how* of it, i will be glad to
correct the patch. i am also willing to produce a patch that will make it an
option, whether a compile or a run time one, if people tell me it is going
to be included. since we will always want this turned on, there is no point
in me mucking about with that if the patch is not going to be accepted.

cheers,
paul