[SC-Help] Re: got sigalarm, taking too long to process, aborted.

[Mike Easter]

Mike Nuss wrote:
> When I try to parse this spam, it dies saying "got sigalarm, taking
> too long to process, aborted. Perhaps you can wait a few minutes and
> reload?" I've tried reloading a few times and it happens every time.
>
www.spamcop.net/sc?id=z767382389z893a7c2da918417b72328b2c45d05f2bz

Maybe we should make 3 different threads out of this because the tracker
is making 3 completely different kinds of mistakes.

This is a mailhosts parse, it is also too old, 37 hours.

  Abbreviated Received lines *comment
  from clifford.webservepro.com ([66.205.65.100]) by mail2.ammasso.com
*serves you?
  from c-24-21-53-70.hsd1.or.comcast.net
(c-24-21-53-70.hsd1.or.comcast.net [24.21.53.70]) by
clifford.webservepro.com *sourceline
  from 248.160.90.32 by 24.21.53.70 *bogusline

SC misparses the headers and wants to name webservepro before it bails
on the sigalarm, so it names nothing.  When parsing the same spam for me
not mailhosted, it correctly sources the proxified comcast, but bails on
the body and names nothing.

It seems to me that the parser is handling the body problem badly.
Where 'the body problem' is what causes the sigalarm.  In addition, it
parses the headers wrong before it gets down to the body and bails.  At
least the 'bailing' keeps it from wanting to make a bad report on the
source on your tracker .

The problem is that the spambody consists of 6 similar URLs, all of
which SC finds and then spends an inordinate amount of time trying to
resolve each one, fails on all of them, and then aborts with the
sigalarm on the last one..

http://customersupport.thewatchconnection4u.com/
http://helpdesk.thewatchconnection4u.com/
http://support.thewatchconnection4u.com/
http://shipping.thewatchconnection4u.com/
http://customerservice.thewatchconnection4u.com/
http://processing.thewatchconnection4u.com/

Those all resolve properly for me to 219.254.32.69 no rDNS.
abuse at hanaro.com  which is spamhaused with a ton of websites, so nothing
much would be lost by just 'showing' them and not trying to resolve
them..

If I manufacture a spam with only one of those, SC offers to report
properly, even tho' it is 37 hours old

http://www.spamcop.net/sc?id=z767863052z9d2cacecf09672891660f642b5505938z

Tracking link: http://shipping.thewatchconnection4u.com/
No recent reports, no history available
Cannot resolve http://shipping.thewatchconnection4u.com/

Report Spam to:
Re: 24.21.53.70 (Administrator of network where email originates)
   To: abuse at comcast.net (Notes)

So, now we're up to 3 different SC problems for one spam.  In your
mailhosted one, it parses the item's headers wrong, unless webservpro
doesn't serve you, in which case it parses mine wrong for trusting
webservpro to be a server.  It offers to report a 37 hour old spam for
my manufactured one.  And in some ways the worst part because of the
waste of resources is the gagging and bailing on the flakey nameserved
body urls.  It should 'quit' working on the body issues before it spends
too much time there and has to bail.

This is another example of how I think the parser should be changed
about how it handles body parses.  This could all be done very smoothly
by simply finding all of the url/s and providing a devnull address for
them.

I have a feeling that this parser signalarm is being caused by the
parser trying too hard to resolve too many urls for which it is blocked
or the domainname has flakey nameservice, which it does:

  Looking up at ns1.magellan25.com.... Reports 1 A record(s). 719ms.
  Looking up at ns1.samantha10.com.... Timed out.
  Looking up at ns2.magellan25.com.... Reports 1 A record(s). 706ms.
  Looking up at ns2.samantha10.com.... Timed out.

Average of all 4 nameservers: 956ms (plus 2159ms overhead).
Score: F

It has 4 nameservers, 2 of them timeout and the other 2 are pokey.

-- 
Mike Easter
kibitzer, not SC admin