Jump to content

sigalarm


craigt

Recommended Posts

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.

Link to comment
Share on other sites

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.

32807[/snapback]

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.

Link to comment
Share on other sites

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?

32809[/snapback]

Did you try the "Cancel" Button, or does the Parser not get that far? Thanks!
Link to comment
Share on other sites

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?

32809[/snapback]

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.
Link to comment
Share on other sites

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

32812[/snapback]

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. :)

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

32822[/snapback]

Created new topic in New Feature Request Forum quoting this post

Add second Cancel Report button, Allow report cancel when report hangs up

Link to comment
Share on other sites

Created new topic in New Feature Request Forum quoting this post

Add second Cancel Report button, Allow report cancel when report hangs up

32824[/snapback]

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. :angry:

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

Link to comment
Share on other sites

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.  :angry:

32859[/snapback]

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.
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

Technical clarification of Steven's post.

It does not matter when you click on "Remove all unreported spam"

32877[/snapback]

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

32903[/snapback]

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.

32903[/snapback]

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).
Link to comment
Share on other sites

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

32904[/snapback]

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.

Link to comment
Share on other sites

Thanks Jeff - I was overlooking Quick Report "which only SpamCop Email System Customers may access", it is not an option for me. 

32905[/snapback]

Well, my acount at work is of the free variety and I quick report there regularly. It is possible I am grandfathered in on that but I had to follow a procedure returned to me by submitting to quick.x.
Link to comment
Share on other sites

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.

32905[/snapback]

I'm sorry if I wasn't clear - you may have the option to Quick Report. Please review To Quick Report via email for details on Quick Reporting via email, and review FAQ Entry: Resubmitting to Get New Tracking URL (but pasting into your email program rather than the Parser), if necessary, for the mechanics of resubmitting via email. Thanks!
Link to comment
Share on other sites

... I had to follow a procedure returned to me by submitting to quick.x.

32907[/snapback]

Steven, thanks for that. The response on trying is:

"Quick reporting is disabled due to careless use.

It may be reactivated on a case-by-case basis.

Email service<at>admin<dot>spamcop<dot>net to request access.

Using normal confirmed reporting instead."

So, as you were thinking, it possibly is an option. I wasn't simply told to get lost in any event - which may or may not mean anything. I will ask service.

Link to comment
Share on other sites

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.

32870[/snapback]

Steven,

I have re-read the "work-around" and believe my original interpretation to be correct.

I am currently continuing to report spam, via the links returned in from the "SpamCop AutoResponder". Some are successfully submitted and some hang, because of the sigAlarm issue. When I've submitted all that I can successfully submit, I then flush the reporting queue, by clicking on "Remove all unreported spam".

My point, was that these sigAlarm-triggering spam messages are going unreported. Thus, these SPAMmers are (currently, anyway) able to spam with impunity. (I presume that they're quite pleased with themselves for figuring out a way to circumvent the SpamCop reporting system, but I don't know if that's really true or I'm just a cynical lout?!)

When I click on my recent report history, these unreported messages show up (as unreported), giving me some clue as to which spam messages contain the unresolvable links. But it is clear that these messages are going unreported to the offending admin/hosting site contacts.

I remain hopeful that SpamCop will find a resolution for this issue and we can continue to file reports for ALL spam messages - regardless of the integrity of the links contained in the message body.

-stk :D

EDIT: We are not currently set up for "quick reporting" (whatever that is).

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...