sigalarm, Reporting system confused by some spams? Options

[craigt]

I've recently encountered some spams that seem to confuse the reporting system and result in sigalarms. I've dealt with this by hitting the 'remove all unreported' button to flush my queue and then reports flow normally.

The spam currently on the top of my queue ( id=z806190795z5c23d81ae33580db10e35d4157245721z ) is one of these -- I haven't flushed this yet so that someone with SpamCop may be able to take a look and sort out what is causing the sigalarm.

*EDIT*: Tracking URL created from Tracking ID.

This post has been edited by StevenUnderwood: Sep 15 2005, 12:45 PM

[StevenUnderwood]

I've recently encountered some spams that seem to confuse the reporting system and result in sigalarms.  I've dealt with this by hitting the 'remove all unreported' button to flush my queue and then reports flow normally.

I believe this is a known problem with the parser but it is that way for a reason. This spam sample has 6 links that all do not resolve. Spamcop has a timeout that is being hit because of all those failures. If the timeout did not exist, spammers could make the parser "hang" for quite a while by adding even more unresolvable links. If you have quick reporting capabilities, it might work since that does not bother with the body at all.

[craigt]

OK, if the sigalarm is a desired result (in this case) is there a method of removing ONLY the offending spam rather than clearing the entire queue?

[Jeff G.]

OK, if the sigalarm is a desired result (in this case) is there a method of removing ONLY the offending spam rather than clearing the entire queue?

Did you try the "Cancel" Button, or does the Parser not get that far? Thanks!

[StevenUnderwood]

OK, if the sigalarm is a desired result (in this case) is there a method of removing ONLY the offending spam rather than clearing the entire queue?

Since I did not write or have access to the software, I don't know if it is the desired result or simply a default "security blanket". I for one would like a more elegant exit to any parse.

[craigt]

Did you try the "Cancel" Button, or does the Parser not get that far?  Thanks!

When it stops on a sigalarm it hasn't gotten to the point of displaying the normal 'Cancel' button.

[Jeff G.]

When it stops on a sigalarm it hasn't gotten to the point of displaying the normal 'Cancel' button.

I'm sorry to hear that. After you follow Don's suggestion to "use your links to report all your other spam, and then log in and use the "Removed[sic] all unreported spam" link on the 'Welcome' page to get rid of the problem spam" as quoted in Linear Post #13 below, your best options (suggested workarounds) while you wait for the underlying problem to be fixed are as follows, in no particular order:

• Report using Copy and Paste on the website, to minimize data loss if one of those messages causes a sigalarm and you have to flush the queue with the "Remove all unreported spam" Link on the "Welcome" Page.
• Email Submit and Report one spam email message at a time, also to minimize data loss if one of those messages causes a sigalarm and you have to flush the queue.
• Quick Report.
• Pause your spam reporting and enjoy the rest of your life for a while. (IMG:style_emoticons/default/smile.gif)

Edit: 2005/09/17 11:53 EDT -0400 Jeff G. updated with Don's quoted suggestion and then clarified a bit.

This post has been edited by Jeff G.: Sep 17 2005, 10:53 AM

[turetzsr]

<snip>
At this point, your best options ... are ... :
<snip>

• Pause your spam reporting and enjoy the rest of your life for a while. (IMG:style_emoticons/default/smile.gif)

...Hey, for some of us, spam reporting is our life! Sad, ain't it? (IMG:style_emoticons/default/biggrin.gif) <big g>

[Farelf]

The emails causing this problem are a real "poison pill" for the reporters receiving them - and I'm not sure that even just clicking the tracking link in the OP's first post mightn't cause a bit of a resource haemorrhage for SpamCop while the (no doubt crafted) link resolution situation prevails. I'm glad this topic is receiving a sypathetic review by those responding (not always the case in the past, on a quick review). Now if only the "powers that be" could take a serious look at more elegant solutions. Why does the parser drop some/most resolution difficulties without a drama, but press through to the sigalarm situation with others? Admittedly very few of them at this time. I don't know, "SpamCop" doesn't act like "it" knows, the worrying thought is some spammer knows. Nah, that's akin to conspiracy theory, isn't it.

[craigt]

I do have a suggestion for SpamCop which won't solve the sigalarm situation but would allow the dumping of any such offending spams without having to purge the entire queue -- how about placing the 'Cancel' button at the top of the process page? This would hopefully allow any single spam that was capable of creating this problem to be dropped by itself.

[dbiel]

I do have a suggestion for SpamCop which won't solve the sigalarm situation but would allow the dumping of any such offending spams without having to purge the entire queue -- how about placing the 'Cancel' button at the top of the process page?  This would hopefully allow any single spam that was capable of creating this problem to be dropped by itself.

Created new topic in New Feature Request Forum quoting this post
Add second Cancel Report button, Allow report cancel when report hangs up

[geo_splash_12]

Spamcop is very slow at the moment.

Actually, on of the reports hung itself up in the processing, dear developers / cops or whoever is responsible for this otherwise so helpful service, THIS IS A BUG AND YOU SHOULD FIX IT!!!!

[stk]

Created new topic in New Feature Request Forum quoting this post
Add second Cancel Report button, Allow report cancel when report hangs up

Apparently, SpamCop is looking into this possibility.

I've been reporting SPAM, using SpamCop, for several months. I cut'n-paste from Gmail, but from Yahoo accounts, I send SPAM, as an attachment, to SpamCop. All has been fine, till this past week.

Then I too, started getting lots of "sigalarm" hangs and began experiencing difficulty with the system.

I wrote to SpamCop Admin, outlining the problem, and received this response:

The sigalarm problem has been sent to the engineers for resolution.

It happens when the parse times out trying to resolve the URLs in the body
text.  The problem is that the parse shouldn't just bail out and leave the
user hanging.  Figuring out why it happens could be a challenge.  In the
meantime, we're looking for ways to at least let you cancel a submission
that won't process.

The workaround is to use your links to report all your other spam, and then
log in and use the "Removed all unreported spam" link on the 'Welcome' page
to get rid of the problem spam.

The "workaround" (I hope) is only temporary, as it means that reports are not sent and the spam message is (effectively) immune from the SpamCop reprting system. It galls me to think that these SPAM messages are now being delivered with impunity. (IMG:style_emoticons/default/mad.gif)

I hope that SpamCop can find a better way to deal with unresolved links in the body text of SPAM mail.

In the meantime, it appears they are considering the suggestion to allow for a way to cancel such a hung submission.

-stk

[Jeff G.]

Apparently, SpamCop is looking into this possibility.

Thanks for the update and for quoting Don's response. I have incorporated it into my suggestions in Linear Post #7 above.

[StevenUnderwood]

The "workaround" (I hope) is only temporary, as it means that reports are not sent and the spam message is (effectively) immune from the SpamCop reprting system.  It galls me to think that these SPAM messages are now being delivered with impunity.  (IMG:style_emoticons/default/mad.gif)

Please re-read the "work around" They want you to follow the links you are provided via email for all subsequent reports accepted, reporting those then only Delete all reports when only the problem spams are queued. If confgured, you can always submit those spams for quick reporting.

[dbiel]

Technical clarification of Steven's post.
It does not matter when you click on "Remove all unreported spam"
Clicking on "Remove all unreported spam" does not actually delete the submitted spam; it simply purges the reporting queue. The submitted spam remains in the "archive" referenced by its tracking URL.
The confirmation email simply contains a link to the tracking URL that allows you to submit the spam referenced by the tracking URL to the parser for processing. There is some sort of flag that gets set when either the "Send Spam Report(s) Now" or "Cancel" buttons get clicked that prevents the duplicate sending of reports as well as the appending of the "report sent to" information to the file.

The "Cancel" report button does not actually cancel the reports in the normal sense, but rather sends the reports to "cancelled[at]devnull.spamcop.net" which effectively does the same thing.
If you cancel the reports and attempt to run the tracking URL again you will notice the following:
Reports regarding this spam have already been sent:
Reportid: xxxxxxxxxx To: cancelled[at]devnull.spamcop.net

If reported today, reports would be sent to:

If you submit the reports and then attempt to run the tracking URL again you will notice the following:
Reports regarding this spam have already been sent:
Re: 140.184.51.143 (Administrator of network where email originates)
Reportid: 151xxxx256 To: geoff.james[at]smu.ca
Re: http://0pc2rj42dst.mycheapestgenericmedz.com/c0ff6a47b9 (Administrator of network hosting website referenced in spam)
Reportid: 151xxxx260 To: abuse[at]hanaro.com
Re: 140.184.51.143 (Third party interested in email source)
Reportid: 151xxxx259 To: spamcop[at]imaphost.com

If reported today, reports would be sent to:
Note: the report ID and following info is unique to each tracking URL

If you click on the tracking URL and simply close the window (view the results of the parse but do not click on either "send spam report(s)s now" or "cancel"; then you can click on the tracking URL again at a latter time and submit the reports or cancel them at that time (as long as the reporting time window has not closed).

[StevenUnderwood]

Technical clarification of Steven's post.
It does not matter when you click on "Remove all unreported spam"

Thank you. I was under the impression that the Remove all unrepported spam actually put all of them in the "cancelled" state, but had never tested that theory. That was why I worded it the way I did.

*Edit* Tested to confirm dbiels version of the facts

[Farelf]

Still getting the odd spam causing the sigalarm. I would like to raise a couple of issues with this situation.

1. Given that the parser struggles with these, how smart is it for an instance to be linked on this forum? When someone clicks on that tracking link, the parser goes through its thing all over again, doesn't it? Imagine, in addition to the regular reporting and further cases being processed routinely (with attendant individual slowdowns), hordes of interested/curious/spiteful surfers also clicking on that link. Might that not cause a general slowdown? Might it not be a good idea to at least pull the url tag (so the link is no longer "live" to the effortless click)? I'm not a Newsgroup user but I notice in the recent archives there's a similar tracking link from last Saturday posted there too, so presumably there's another two links (NG + archive), at least, open to both idle and informed "clicking".

2. Not to put too fine a point apon it, I notice in "my" cases that the offending IP address has always been reported already. That might be coincidence but considering the "material alterations" rule, what on earth would be wrong anyway, with a reporter editing the spam for a webmail submission to remove the link or links that cause the problem? Things change, but I'm reasonably sure the "no alterations" rule was never intended to prevent this sort of prophylaxis. It should be sanctioned (so spammers will eventually learn that) - it is not as if any innocent party is being affected.

This post has been edited by Farelf: Sep 18 2005, 10:53 PM

[Jeff G.]

1.  Given that the parser struggles with these, how smart is it for an instance to be linked on this forum?

I would hope that the SpamCop Admins would have systems in place to prevent such abuses of their resources (if not, I hereby suggest them).

2.  Not to put too fine a point apon it, I notice in "my" cases that the offending IP address has always been reported already.

Please don't make such changes unless a SpamCop Employee says it's ok to do so. You can always Quick Report (to Report the Source) and Manual Report each URL (to bypass the sigalarm problem).

[Farelf]

... You can always Quick Report (to Report the Source) and Manual Report each URL (to bypass the sigalarm problem).

Thanks Jeff - I was overlooking Quick Report "which only SpamCop Email System Customers may access", it is not an option for me. So far, there may be enough "Quick Reporters" to list the perpetrators in a reasonably timely manner. Not sure I would count on that, but of course it is not my decision.