Re: One more time, please...
J G <[email protected]>
| Newsgroups | gmane.mail.spam.spamcop.help |
|---|---|
| Organization | SpamCop |
| Message-ID | <[email protected]> |
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: <[email protected]> > > 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... > >