[geeklog-devtalk] geeklog-devel digest, Vol 1 #508 - 2 msgs
geeklog-devel-request at lists.geeklog.net
geeklog-devel-request at lists.geeklog.net
Sat Feb 12 13:00:02 EST 2005
Send geeklog-devel mailing list submissions to
geeklog-devel at lists.geeklog.net
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
geeklog-devel-request at lists.geeklog.net
You can reach the person managing the list at
geeklog-devel-admin at lists.geeklog.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."
Today's Topics:
1. Re: Home-made problems with forum spam (Dirk Haun)
2. Re: Home-made problems with forum spam (Tom Willett)
--__--__--
Message: 1
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Home-made problems with forum spam
Date: Fri, 11 Feb 2005 19:49:31 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net
Tom,
>It seems to me by the time you get here you have already done most of
>the processing (when lib-common is included), about all you would save
>is the template processing and a small portion of the bandwidth.
The code I was quoting was the one that processes a post, e.g. in the
forum plugin. Currently, we then send a redirect to index.php, which the
spammer's scripts now seem to follow. So rendering index.php causes extra
load - it's an entirely separate HTTP request.
I was proposing that instead of the redirect we abort the script right
when we recognized the post as being spam and output a short message
instead there and then.
bye, Dirk
--
http://www.haun-online.de/
http://geeklog.info/
--__--__--
Message: 2
Date: Fri, 11 Feb 2005 14:06:34 -0500
From: Tom Willett <tomw at pigstye.net>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Home-made problems with forum spam
Reply-To: geeklog-devel at lists.geeklog.net
This is a multi-part message in MIME format.
--------------020807090307050503030406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 2/11/2005 1:49 PM, Dirk Haun wrote:
>Tom,
>
>
>
>>It seems to me by the time you get here you have already done most of
>>the processing (when lib-common is included), about all you would save
>>is the template processing and a small portion of the bandwidth.
>>
>>
>
>The code I was quoting was the one that processes a post, e.g. in the
>forum plugin. Currently, we then send a redirect to index.php, which the
>spammer's scripts now seem to follow. So rendering index.php causes extra
>load - it's an entirely separate HTTP request.
>
>I was proposing that instead of the redirect we abort the script right
>when we recognized the post as being spam and output a short message
>instead there and then.
>
>bye, Dirk
>
>
>
>
Ok I thought you were going back through the whole process again. If
you just aborted it when spam was detected that might help with the load
a bit.
I had someone trying to download for offline use a site I have with
almost 2000 stories. The person was very impolite and was asking for a
story a second ate up all my bandwidth and brought the site to its
knees. I put them in the geeklog ban (which just stops processing when
it hits a ban an exits) but it didn't help because even though it didn't
get anything he kept on coming and the server load stayed about the
same. I finally instituted an apache rewrite ban that freed up my
bandwidth and server resources. For that reason I am skeptical of any
technique that causes geeklog to be loaded even though it doesn't return
much.
--
Tom Willett
tomw at pigstye.net
--------------020807090307050503030406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 2/11/2005 1:49 PM, Dirk Haun wrote:
<blockquote cite="mid20050211184932.13346 at smtp.haun-online.de"
type="cite">
<pre wrap="">Tom,
</pre>
<blockquote type="cite">
<pre wrap="">It seems to me by the time you get here you have already done most of
the processing (when lib-common is included), about all you would save
is the template processing and a small portion of the bandwidth.
</pre>
</blockquote>
<pre wrap=""><!---->
The code I was quoting was the one that processes a post, e.g. in the
forum plugin. Currently, we then send a redirect to index.php, which the
spammer's scripts now seem to follow. So rendering index.php causes extra
load - it's an entirely separate HTTP request.
I was proposing that instead of the redirect we abort the script right
when we recognized the post as being spam and output a short message
instead there and then.
bye, Dirk
</pre>
</blockquote>
Ok I thought you were going back through the whole process again. If
you just aborted it when spam was detected that might help with the
load a bit.<br>
<br>
I had someone trying to download for offline use a site I have with
almost 2000 stories. The person was very impolite and was asking for a
story a second ate up all my bandwidth and brought the site to its
knees. I put them in the geeklog ban (which just stops processing when
it hits a ban an exits) but it didn't help because even though it
didn't get anything he kept on coming and the server load stayed about
the same. I finally instituted an apache rewrite ban that freed up my
bandwidth and server resources. For that reason I am skeptical of any
technique that causes geeklog to be loaded even though it doesn't
return much.<br>
<br>
<pre class="moz-signature" cols="72">--
Tom Willett
<a class="moz-txt-link-abbreviated" href="mailto:tomw at pigstye.net">tomw at pigstye.net</a>
</pre>
</body>
</html>
--------------020807090307050503030406--
--__--__--
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
End of geeklog-devel Digest
More information about the geeklog-devtalk
mailing list