Jump to content

Report page stalls before parsing header


Polyergic

Recommended Posts

Posted

...Check out the graphic labeled "Reporting Server Status" in the upper-right corner of the page. The end of the green bars to the right side suggests that the parser server or application is down right now.

Posted

An hour further down the track, the parsing and reporting server status looks good, you may need to get Don's help with this one - in case he doesn't see it here, write to service[at]admin.spamcop.net with that tracking URL.

Posted

>- (AES256-SHA)(AES256-SHA)(AES256-SHA)

The huge blocks of that item in the headers appear to be causing the trouble.

The only thing I could do about that is modify the headers before submission, which is not allowed. This looks like a new way to prevent reporting; I assume it will be added to the list and fixed eventually. For now, I could filter so I don't submit more messages with this problem - what would be the best criteria for that filter?

Also, is there a way to remove just this one unreported spam? I only see the link to remove all unreported spam.

Posted
...For now, I could filter so I don't submit more messages with this problem - what would be the best criteria for that filter?

Also, is there a way to remove just this one unreported spam? I only see the link to remove all unreported spam.

Don might be able to answer but the rest of us would probably need to know about your mail agent and the spam to know what filtering options might work to divert suspect messages. If "(AES256-SHA)" is unique you could interrogate the specific header lines ("Received:"?) for that. If there was some way to filter on the size of the header alone that would be ideal (just have to guess the critical value :D ) but maybe there's no way to determine that - certainly there's not with my mail application.

The usual advice for a log-jammed queue is to "Remove all unreported spam" and resume your reporting with anything not now too old. You have done your bit by notifying the problem and letting Don/the deputies have a look at it (thanks for that).

Posted

Don might be able to answer but the rest of us would probably need to know about your mail agent and the spam to know what filtering options might work to divert suspect messages.

I run my own personal email server, so I have an IMAP spam folder and a cronjob that reports any messages I move to that folder. The filtering options are pretty much anything that can run within the resources available on that machine.

Posted

Assuming I'm understanding the issue being reported here, I'm having the same issue here in BKK with http://www.spamcop.net/mcgi?action=verifyl...p;returnurl=%2F just a blank page. According to Safari's Activity monitor, the gateway timed out. :(

Getting the same blank page in Firefox as well.

End result is fwd'ed spam cannot be parsed, or whatever you call what happens in there, when I click the report button.

Posted

OK now I'm getting pissed and it's not SC that's doing it. I live in Thailand where the internet is not free as in the US , Europe, etc. So sites can be blocked and infrastructure issues can mess up your day.

That said, as a test, I used Tor browser just now, (which anonymizes one's IP so you can pretty much browse anonymously), on SC and I'm able to report with no issues.

So my issue is, for whatever reason, that the reporting page doesn't load properly and when trying to get TO the reporting page, the gateway "times out". Yeah thanks True internet Thailand.

Sorry guys, there's probably nothing you can do to help this issue.

Tor browser is pretty slow to use so I only use it on "misbehaving" sites. These sites are usually totally innocuous and it is really getting my goat the way site behavior lately is totally random. I don't know if somehow SC reporting got on Thailand's blacklist, but if so, as usual they got it wrong.

Posted

Thanks for checking it out emanmb. Yes, different case entirely - you would have to talk to somebody that end (maybe starting with ipadmin[at]trueinternet.co.th) about that. If you look up the IP address and its assignment for members.spamcop.net from your location, I think you will find trueinternet.co.th handle the deployment in Thailand of SpamCop through Akamai/Edgesuite (58.97.45.34 - maybe others) so the whole deal with blocking access sounds (that would be through Japan in the case of spamcop.net pages for Thailand - 117.104.139.213) a bit schizophrenic when you consider it that way. I don't imagine it's deliberate (else they/the Japanese carrier have some serious explaining to do).

Posted

Well it seems to have been a temporary thing in my case and SC is performing as it should now. Go figger. I had recently changed the DNS settings here and thought "great, I screwed up something I know nothing about!".

Things were acting up on different sites here with the toolbar in Yahoo mail not working to SC pages not working. Fortunately it seems OK now, SC and Yahoo are both as they should be.

I get suspicious when multiple sites get weird over here. The quality of the internet could be worse, but is not as good as the US which is what I'm used to. I'm living here now, so I'll make do. At least it isn't Burma where there's barely any connectivity at all! :)

Posted

Great, fixed for you. Sometimes it might just be "DNS issues" or a failing route. You can check connectivity from all around the globe to any address by using a web-based service such as http://just-ping.com/ - that can reveal if it's just a local node thing (with a good probability of "coming good") or "just you". SC though, with it's global deployment, is a bit different.

Meantime, the O/P would no doubt appreciate any suggestions on how to filter inordinately inflated headers - here:

84127[/snapback].

Hopefully it might prove to be an aberration, soon to go away (such novelties often are), but maybe not ...

Archived

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

×
×
  • Create New...