James Merrill Posted January 20, 2006 Share Posted January 20, 2006 It appears that the current version of "Quick - report immediately and trash" reporting makes no effort to look for spamvertised sites and report them. (I don't know if it ever did. I know that I was a little surprised when I noticed that.) Shutting down spamvertised sites is much more valuable, I think, than telling ISPs responsible for the mail being sent that someone on their network has an open proxy or is a Windows box that's been taken over by the bad guys. I want to shut down the spamvertised sites, so that the people who run them stop thinking that it's so close to free to send a gazillion spams. I understand SpamCop not wanting to do the spamvertised-site reporting automatically. However, it takes a _lot_ more time to report spams manually than to quick-report them, largely because we have to wait for the parsing (though some of it is checking the appropriateness of the spamvertised site analysis and waiting for the reports to be generated). How about changing the behavior of "queue for reporting"? Now, when I go to the "Report spam" page and click "Unreported spam Saved: Report Now" I have to wait for them to be parsed one at a time, and the parsing is distinctly not instantaneous. I suggest that "queue for reporting" change (internally) to "queue for parsing" so that when I go to "report unreported spam" the already-parsed results are shown. (There would have to be a re-parse button in case I want to do that, and of course if there aren't any already-parsed results ready it would do a live parse.) That would reduce the waiting time for me to report the spams manually and thus hit the owners of spamvertised sites. In the implementation, some type of daemon task could throw away parse results that are more than 30 mins or 1 hour old. The queued parsing could run at a lower priority than live parsing (possibly running on older, slower, not-quite-recycled machines); that could improve response time for live parsing (by spreading out the parsing effort) while reducing see-parse-results wait time for people who are reporting many spams manually. This doesn't seem to me to be a particularly difficult thing to implement, and it offers significant benefits to SpamCop and not just its users. Thanks for listening. Link to comment Share on other sites More sharing options...
StevenUnderwood Posted January 20, 2006 Share Posted January 20, 2006 This doesn't seem to me to be a particularly difficult thing to implement, and it offers significant benefits to SpamCop and not just its users. Thanks for listening.39504[/snapback] While I like your idea (it has been brought up before) I only want to comment on this last part and please do not take this as a slam, just a question to ponder before you make similiar statements in the future. How would you know how easy or difficult something like this would be. Do you know how all the reported emails are organized inside spamcops DB? There are lots of requests for things which would seem even simpler than this (presenting the number of unreported spams is one that immediately comes to mind) that have not been implemented. The basic thought is that while it appears easy from this side of the screen, it probably is not as simple as it would seem. Link to comment Share on other sites More sharing options...
Wazoo Posted January 20, 2006 Share Posted January 20, 2006 It appears that the current version of "Quick - report immediately and trash" reporting makes no effort to look for spamvertised sites and report them. (I don't know if it ever did. I know that I was a little surprised when I noticed that.) What is Quick Reporting? What is Quick Reporting? It's not like the information is invisible ...??? I understand SpamCop not wanting to do the spamvertised-site reporting automatically. However, it takes a _lot_ more time to report spams manually than to quick-report them, largely because we have to wait for the parsing (though some of it is checking the appropriateness of the spamvertised site analysis and waiting for the reports to be generated). How about changing the behavior of "queue for reporting"? 39504[/snapback] Jerking the strings to open the curtains on the way-back machine ..... submitting spam by e-mail was an action developed in response to the complaints of folks having to sit and wait for each pasted-in parse to run through to completion. This 'new' feature was designed such that (for example) one could hit the office in the morning and while waiting for the first coffee pot to brew up, one could go through one's e-mail and submit the garbage that had shown up overnight, then handle the 'real' e-mail ..... sometime later in the day, when some time was available, then one could follow up on the parsed results and actually get those complaints sent. This worked so well, that some folks began to see the e-mail submittal process as being "instantaneous" and like this post, getting upset when there was any delay seen. It has always been an issue of getting so many users, adding more hardware, getting more users, getting more hardware, getting more users ..... Quick-reporting was something introduced to stop some of these complaints, as it skipped all the heavy work and only went for the spam source ... But even then, spam submittal by e-mail were/are not taken as "job #1" in the flow of things. Ages ago, I did make a post or two that had a list of things done by a priority basis, and as was designed, e-mail submittals were maybe three or four rungs down on that ladder ... again, designed around "submit now" .. "handle a bit later" ... You may think it's an easy task to change a few lines of code, but .... (looking at the Current and past Statistics ) are you used to dealing with the (world-wide) traffic flow involved with this part of the SpamCop.net tool-set? Moderator Edit: URL changed due to Forum and Mod update Link to comment Share on other sites More sharing options...
agsteele Posted January 21, 2006 Share Posted January 21, 2006 It appears that the current version of "Quick - report immediately and trash" reporting makes no effort to look for spamvertised sites and report them. (I don't know if it ever did. I know that I was a little surprised when I noticed that.) Shutting down spamvertised sites is much more valuable, I think, than telling ISPs responsible for the mail being sent that someone on their network has an open proxy or is a Windows box that's been taken over by the bad guys. I want to shut down the spamvertised sites, so that the people who run them stop thinking that it's so close to free to send a gazillion spams. 39504[/snapback] Hi James! The Quick reporting has always been set to report the sending IP address only. It stems, in part, from the fact that with Quick Reporting there is no final check that reports are going to the right place and the right sites getting a warning. However, I would disagree with your assertion that reporting spamvertised URLS is more valuable than identifying the source of the spam. The SCBL is designed to help mail admins identify spam based on where it has come from. It does this very efficiently. It alerts mail admins when a user is, for whatever reason, sending out spam and that works well because the ISP finds itself inconvenienced and wants to keep legitimate Email flowing. The reporting of spamvertised URLs, by contrast, does not typically seem to be at all effective. Some responsible ISPs will tackle customers who spam and advertise their own website but most seem unable or unwilling to to get a grip of the websites within their influence. Even with those that do, the removal of the domain doesn't stop the spam flow. They simply move elsewhere or set up their own servers. That said, I see merit in the idea of speeding up the parsing process as you describe but this has not proved to be a significant issue for me. Andrew Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.