[SC-Help] Re: One more time, please...

[J G]

On 6/15/2005 5:34 PM Mike Easter scribbled:

> J G wrote:
> 
>>Know I've asked before, I think, but can't find much in the way of
>>recomendations in the help docs and am lousy in searching the usenet.
>>
>>Which method is preferred - forwarding spam as attachments or copy,
>>paste, send?
> 
> 
> This is what I sed the other day:
> 
> From: "Mike Easter"
> Newsgroups: spamcop.help
> Subject: Re: spamvertisement reporting & a question...
> Date: Wed, 8 Jun 2005 18:33:00 -0700
> Message-ID: <d88684$ime$1 at news.spamcop.net>
> 
> Jeff G. wrote:
> 
>>Also, given the 2 methods of choice with reporting - copying and
>>pasting whole msg or forwarding, is there a benefit or preference to
>>using one or the other?
> 
> 
> The advantage of copying and pasting into the parser is that you get
> 'faster' rather quicker/sooner results.  The disadvantage is that there
> is 'deadtime' that you need to manage constructively.  If you can
> develop a 'rhythm' of keypresses to get to the message source and paste
> it into the webparser, or alternatively use a keypress macro, then
> 'feeding' the parser is actually very efficient, one spam at a time, per
> 1.5 second [hypothetical].
> 
> Then, you would need a strategy to manage the deadtime, one of which
> might be to use multiple iterations of parsers -- so your 'macro' of
> keypresses feeds a sequence of parsers so that the individual parser's
> results match up with your approval process.  That can result in no
> deadtime and a continuous sequence of feeding one spam at a time into
> multiple parsers whose results and approvals match up with the speed of
> the parser processing.
Please don't take so much of your time on my thickness - I can get along
with simple yes and nos where possible and thanks, Mike, that was the
post and it opened a can of worms for me here which fogged my memory of
last week.  Thunderbird isn't really a good usenet client - serves my
purpose, but the various settings make it difficult to bring back former
posts - lets leave that.
I took your idea for the past week - open 3-4 tabs of SC - any more
would be no benefit.  At 7-9 A.M.Pacific time, I'm getting 2 minute
waits per parse, if not total fail, which come out to maybe 1 out of 10
or so.  At one point, I thought a particular spam was a cause - I posted
a queston on etewatches and got a thud
If I were getting 1.5 sec. times, I'd be happy, but it ain't happening.
 Afraid I'm running a model T-box (only 600 mgz) or maybe my cable
provider is bogged down at that point, though no other browser use seems
affected.

Think pipelining may slow the process down??  I have it set to on - and
no firewall ...

> 
> The advantage of forwarding 'masses' of spams at a time is that you
> avoid the above sequence of having to have an efficient series of
> keypresses for each spamitem and of transitioning between parsers and
> their report options.
> 
> The disadvantage is that you have to wait for the mailforwarded items to
> get processed in their own sweet time.  The other disadvantage is that
> you still have to manage the problem of accessing the numerous link/s
> and and the report approval process however efficient or inefficient
> that is.

Heres where I got lost - does forwarding a spam, going to work and
coming back on  cause the "unsubmitted report notice" to pop up next
sign on?  This isn't explained anywhere I can find.  Due to the system
dragging, I've chalked this up to a failed send in the prior session,
which has occured 3 or 4 times this week.
And the forwarding solution /doesn't/ report spamvertisers - hmmm...


> 
> Some people who 'move toward' sending masses of spams at a time get
> frustrated by that links portion of the report confirmation and its
> slowdown and decide to 'degenerate' [or accelerate] into quick
> reporting.  Quick reporting dramatically changes the amount of time
> required to report some large number of spams.  It has its dangers and
> its limitations or disadvantages, but it does feed a lot of spamsources
> into the SCbl without as much 'personal' time expenditure [or
> oversight], and there isn't much lost these days by not reporting the
> spamvertisers to their providers.  There's always the ever-present
> danger of reporting your own provider if some kind of changes occur in
> the headerlines of your spams.

Yeh, I could get cox bl'd...
> 
>