Jump to content

Suggestion: Controlling my own report max age


axlq

Recommended Posts

Posted

I just noticed that the maximum age of a report SpamCop will send out has been reduced from 72 to 48 hours.

Can this be user configurable? I'd like to shorten mine to 24 hours or less.

This could be implemented either as a user-account attribute, or as a link on the "report spam" page:

1. As a user account attribute, the maximum age of a report would be set up in each user's account configuration, up to the maximum allowed by spamcop.

2. As a link on the "report spam" page, there would be a text box to specify the maximum age in hours, and then a button to "clean up the queue."

Right now I can either delete the whole queue or report the whole queue one at a time.

Granted, I can look for the age in the parser output and cancel the report manually, but I shouldn't have to. The parser already checks the age. Why not make it variable, and give users the ability to shorten it?

Having a user configurable report age setting would save me time while reporting. I will often log in 3 or 4 times per day and report spam that's come in, to make sure my reports are fresh, but occasionally I have to travel and not log in for a few days, during which time my queue grows. Being able to clear out the old spam from my queue before reporting would be a great help.

-Alex

Posted

No, this is not anything that is user configurable (thus far anyway) .. This "change" occurred sometime last night, nwsgroup traffic is on-going. And the actual time-check actually seems to be around 2 days +7 hours .... noting that the error message is still referencing 3 days ... at the moment, the best guess is some code change that has been inderted into the parser, but no one outside of Julian would have a clue as to why, whether it was intentional, etc. Suspicions are that it will probably either move back to the three day thing or the error message will change ... this is just an opinion at this point based on previous "fixes" that just happen with no fanfare.

OK, newsflash on a page I can't get to ... funny, funny, funny ... anyway, as just reported over in the newsgroups by another user;

-=-=-=-=-=-=-=-

I read the following on http://mailsc.spamcop.net/

------------------------------<knip>------------------------------

News:(Last modified:Friday, 29-Oct-2004 09:40:50 PDT) (Email-account

news)

2-day-old spam no longer accepted

SpamCop and the ISPs who receive reports from it need fresh spam.

Previously, SpamCop would accept spam up to 72 hours old. However, this

old spam was essentially useless. SpamCop now requires that spam being

reported be less than 48 hours old.

Furthermore, we recommend that users not bother reporting spam that is

more than 24 hours old. Usually, sources of spam over 24 hours old have

already been dealt with one way or another. As always, the fresher your

spam, the better.

------------------------------<knip>------------------------------

Strange thing is that my current / refreshed a dozen times <g> view of http://mail.spamcop.net/news.php doesn't reflect this, the last entry being back on 6 Oct .... Apparently JT hasn't caught wind of it yet either, or just hasn't had time to include on that particular page ....

New update ... ok, this information is now seen on the Parsing page at the logged-in mode of www.spamcop.net .... Added this to the Announcements section of this Forum Structure. Now for the FAQ entries ..????

Posted

I'd always assumed that the 72 hours was so the 9-5 crowd, myself included, could report spam from the weekend. This restriction would prevent that partially.

How does the restriction work exactly though? What happens if you report a spam within the initial time period, so that it passes restriction testing, but then don't get back to actually clicking "Send Reports" until much much later?

Unless the tracking URL automatically expires at the time period as well, I don't see the restriction being much use because anybody could set up their mail to automatically submit spam for parsing over the weekend the instant it lands in their inbox, and yet not report it until Mon morning.

...Stu

Posted

Back when the massive storage upgrade was made, the entire spam is now kept. I'm not exactly sure that a Tracking URL does expire at this point. Your query as to submit one day, report a week later (exaggeration) will result in the error message "spam is too old" .... Again, the "date / time" of the spam is taken from the top-most valid header line, normally this owuld be from your ISP. So yes, the report must be "sent" within 2 days of receiving it (at your account, not your InBox) ....

Yes, it all started with the report the Saturday spam Monday morning, but ... over time there have been other changes, like the BL, which used the 48 hour max listing time and this had had some considerable debate over the logic behind 72 hours here and 48 hours there .... discepancy now resolved <g>

Bit of an update: While trying to research another issue and looking for "old" data, I did find that Tracking URLs from back in July came up "empty" ... OK, they do die off, I just have no idea when ... I seem to recall that even report numbers died a death, but I can't recall what that timeframe is either .... probable linked, but ...

Posted
Your query as to submit one day, report a week later (exaggeration) will result in the error message "spam is too old" .... Again, the "date / time" of the spam is taken from the top-most valid header line, normally this owuld be from your ISP.  So yes, the report must be "sent" within 2 days of receiving it (at your account, not your InBox) ....

19345[/snapback]

So, the timestamp is checked twice, once during the parse and then again during the actual reporting phase. Cool.

Next question: which one of those checks is used to calculate one's average reporting time?

Mine's been stuck at 17 hours for most of this year, and no matter how many times I make an effort to report spam over the weekend, it doesn't come down.

...Stu

Posted

Please ignore the average reporting time as it is useless. My acount went from a very nice (and expected) value of about 8 hours to 18 days overnight (with no reports submitted). It has slowly gone down over the past several months to where it is now:

Welcome, Steven P. Underwood (Home).

Your average reporting time is: 15.5 days; Not bad.

This is with qucik reporting via the webmail interface about every hour during the day and the longest reports being no more than 10 hours (11PM early bed -9AM late work) and full reporting anything that gets throgh the filters.

I suspect that only the full reporting values are used as I have never seen it budge after doing quick reporting but have after full reporting. That is only a guess, however.

Posted
Next question: which one of those checks is used to calculate one's average reporting time?

Mine's been stuck at 17 hours for most of this year, and no matter how many times I make an effort to report spam over the weekend, it doesn't come down.

Allegedly, the date/time in the topmost valid header (usually your ISP) as compared to the SpamCop clock at submittal time. However, reality says that this isn't the way it always works. Some people still point to their times with some pride, others complain mightily that there seems to be no reality in their numbers. I fall into the latter group. With my sleep issues, almost all spam was reported within minutes of receipt, the big delay being the 15 minute cycle on making the mail run. Yet, my "time" was once down to something close to 2 hours, then jumped to 8 days .... it's been at 10 hours for at leat the last 8 months (but then again, I don't report that much through SpamCop these days)

Posted

Er... this thread drifted instantly from the first followup to my initial question.

All I wanted to know was basically two things:

1. Is it feasible to have spam automatically removed from the reporting queue if it's too old? It wouldn't have to be something continually checked, but a link called "Remove old spam from queue" next to the "Report spam" link would be nice.

2. If it's feasible, it would also be nice to specify an expiration time less than the maximum allowed. I'd rather not be reporting spam more than 24 hours old, and I can avoid it by manually slogging through the queue. A function to delete the old spams for me would be useful.

-Alex

Posted
1. Is it feasible to have spam automatically removed from the reporting queue if it's too old? It wouldn't have to be something continually checked, but a link called "Remove old spam from queue" next to the "Report spam" link would be nice.

While I like both of those requests and the count of unprocessed submissions, the way I understand it, they would requier a complete rewrite of the way submissions are handled. The history I understand is that the email submission code was added after the copy/paste form.

I don't believe it is easily feasible but only one person can look at the code and determine the real possibility.

It took several years of requests and all that was provided was the simple "Remove all reports" and we were told even that was difficult to provide. Other requests have been a count of unreported spam and your request as well.

One problem, as I understand it, is that ALL spam reports are queued into one large queue, not seperated into queues for each user. So when you click on the report link, the parser needs to search the entire queue for submissions from you. I believe the "Remove all reports" simply runs in the background, running and cancelling all reports.

Another problem is that the age is not calculated until you begin to process the spam, so the process would need to determine the first valid header with a date (not always the first header) and calculate the age for each submission, delete as necessary, and proceed to the next one.

Your second request gets even deeper into the problem. While I like both of those requests and the count of unprocessed submissions, the way I understand it, they would requier a complete rewrite of the way submissions are handled.

Your second request gets even deeper into the problem.

Posted
I don't believe it is easily feasible but only one person can look at the code and determine the real possibility. 

19418[/snapback]

I kinda figured that was the answer, but I had to ask to make sure... :)

-Alex

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...