Jump to content

Cannot reach www.spamcop.net


A.J.Mechelynck

Recommended Posts

:angry: :(:o

I have been in town for a few hours (since about 16.30 GMT) and now, when I try to browse http://www.spamcop.net/ (or the same without the www) I get "Invalid URL" and in smaller type 'The requested URL, "/", is invalid' That's all. I can still browse others sites, including (obviously) this forum, and I can even load the 4 "statistic histogram" images (on alpha.cesmail.net). The only page which appears to be suddenly "misbehaving" is the reporting page itself. Is it only me or does someone else see it too?

I can do a traceroute to www.spamcop.net (which seems to be an alias of a369.g.akamai.net [194.78.133.224]) but using that dotted-quad instead of the symbolic address gives me the same answer.

In case it makes any difference, I'm using Firefox, version "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0", on Windows XP 5.1.2600 SP2.

Link to comment
Share on other sites

It is working for me from here.

> www.spamcop.net

Server: ns1.ma.charter.com

Address: 66.189.0.29

Non-authoritative answer:

Name: a369.g.akamai.net

Addresses: 64.215.169.40, 64.215.169.70

Aliases: www.spamcop.net, www.spamcop.net.edgesuite.net

>

There was a similiar problem last week (1-jan-2005) described right here: http://forum.spamcop.net/forums/index.php?...indpost&p=21795

There was no specific solution there and no word from the deputies about a known outage. There is a workaround dexcribed in there, however that you might be able to use.

Link to comment
Share on other sites

It is working for me from here.

> www.spamcop.net

Server:  ns1.ma.charter.com

Address:  66.189.0.29

Non-authoritative answer:

Name:    a369.g.akamai.net

Addresses:  64.215.169.40, 64.215.169.70

Aliases:  www.spamcop.net, www.spamcop.net.edgesuite.net

>

There was a similiar problem last week (1-jan-2005) described right here: http://forum.spamcop.net/forums/index.php?...indpost&p=21795

There was no specific solution there and no word from the deputies about a known outage.  There is a workaround dexcribed in there, however that you might be able to use.

22877[/snapback]

:(

Well, apparently you reach akamai via another of their "distributed servers". I'm in Belgium (a small country between France, England, Germany and the Netherlands, not to mention Luxemburg), at its "historical" phone operator, on a 3M/192K ADSL line, and I can traceroute to akamai in 4 hops and 18 ms; but trying to reach http://www.spamcop.net/ (symbolic) or any of the akamai servers I've tried (by dotted-quad) give me the same "Invalid URL" message.

I'm not using a proxy, and ATM my addy is 80.200.115.201. As mentioned above, I'm using Firefox on XP.

I've read that thread (at least twice), and even posted to it; but if a workaround was mentioned I failed to notice it. Could you be more specific?

--

P.S. I can still submit by mail and get spamcop autoresponses. Clicking a tracking URL in the autoresponder email opens a new browser tab with nothing in it, nothing in the URL bar either, and only the word "Done" in the status bar.

Link to comment
Share on other sites

http://www.spamcop.net/ works just fine for me in Arizona, with Firefox on the XP platform.

It might be a problem with your local DNS, backbone provider, or the like.

DT

22882[/snapback]

Yeah, sure it "might", how can I know for sure?

Can you name a proxy in the US which would accept connections from Europe? But for anything _but_ SC I don't need a proxy anyway.

Or can you name the dotted-quad for a DNS server which would let me connect? And I don't even remember where in this sh**ty Bill Gates crap the DNS server addies are hidden.

-- P.S.

Found it -- 4 levels down in IE6. It is currently set to "automatic". Now what should I input? Where the **** did I write my own ISP's DNS server? (It was 192.something.2.21, but was that "something" 236 or 238? Let's try 238 and see if I can still browse.)

Ah, that one at least is a DNS server: 195.238.2.21; but still no go. (And every change requires disconnect, reconnect, including re-entering the password). Next I'm gonna try adding a second DNS server (195.238.2.22) unless someone has something really interesting to suggest.

Link to comment
Share on other sites

Quick (?) where is it, what's in it, how do I clear it (for XP) .... http://www.winnetmag.com/Article/ArticleID/27023/27023.html

The work-around ... use of the Hosts file to re-target the DNS results .. however, not really recommended .. problem is that it might work today, it might work tomorrow, then you forget about that "addition" to the Hosts file, and the next time some data changes, you'll be going nuts troubleshooting everything under the sun until someone asks you if you made any changes to the Hosts file <g>

Link to comment
Share on other sites

Quick (?) where is it, what's in it, how do I clear it (for XP) .... http://www.winnetmag.com/Article/ArticleID/27023/27023.html

The work-around ... use of the Hosts file to re-target the DNS results .. however, not really recommended .. problem is that it might work today, it might work tomorrow, then you forget about that "addition" to the Hosts file, and the next time some data changes, you'll be going nuts troubleshooting everything under the sun until someone asks you if you made any changes to the Hosts file <g>

22884[/snapback]

Thanks. Flushed the cache, displayed its contents, there was only 1.0.0.127-addr-arpa -> localhost and localhost = 127.0.0.1, set Firefox offline then online to flush _its_ cache, clicked "Go" on www.spamcop.net, got invalid URL, a lot of spamcop and akamai names are now listed by ipconfig /displaydns...

IOW, thanks for the info, but I still got nowhere. :(

Link to comment
Share on other sites

:o I just could report a spam using IE6. But still no go with Firefox. Should we tell Julian to remove that small-print line at the bottom of the reporting page? Or should I write a Bugzilla report? Somehow both sound unappealing to me.
Link to comment
Share on other sites

OK, forget Hosts file for now. Am playing here and getting myself all confused. For example, a trace-route to www.spamcop.net takes me to one IP ... however, a browser request takes me to a different IP, which a trace-route on that leads me from Iowa to Dallas to Nw York to an "Akamai Technologies - US machines connected to FT AS5511" (French Telephone) ...???? not sure right now if this is strictly the dynamics of load-balancing in work or is it based on the types of calls? ... I can't recall seeing this kind of weirdness before ...

Tracing to you just fine;

01/10/05 21:03:30 Slow traceroute 80.200.115.201

Trace 80.200.115.201 ...

212.187.128.2 RTT: 129ms TTL:128 (so-1-0-0.mp2.Brussels1.Level3.net ok)

4.68.113.206 RTT: 124ms TTL:128 (so-10-0.hsa2.Brussels1.Level3.net ok)

212.3.234.22 RTT: 126ms TTL:128 (intl1-gigabitethernet2-1.evere.brussels.skynet.be bogus rDNS: host not found [authoritative])

194.78.0.205 RTT: 129ms TTL:128 (No rDNS)

80.201.237.214 RTT: 125ms TTL:128 (214.237-201-80.adsl.skynet.be ok)

80.200.115.201 RTT: 137ms TTL:109 (201.115-200-80.adsl.skynet.be ok)

You say in your post in the other Topic;

a369.g.akamai.net which resolves to 194.78.133.222 or 194.78.133.224

From here; 01/10/05 21:07:08 Slow traceroute a369.g.akamai.net

Trace a369.g.akamai.net (65.119.205.135) ...

205.171.8.230 RTT: 47ms TTL:128 (ewr-core-02.inet.qwest.net fraudulent rDNS)

205.171.17.34 RTT: 50ms TTL:128 (ewr-core-03.inet.qwest.net fraudulent rDNS)

205.171.217.2 RTT: 48ms TTL:128 (No rDNS)

65.119.205.135 RTT: 48ms TTL: 51 (host-65-119-205-135.tvpath.com fraudulent rDNS)

01/10/05 21:08:14 Slow traceroute 194.78.133.222

Trace 194.78.133.222 ...

144.232.9.162 RTT: 115ms TTL:128 (sl-bb22-lon-12-0.sprintlink.net ok)

213.206.129.42 RTT: 119ms TTL:128 (sl-bb20-bru-14-0.sprintlink.net ok)

80.66.128.46 RTT: 119ms TTL:128 (sl-gw10-bru-14-0.sprintlink.net ok)

* * * failed

194.78.0.154 RTT: 125ms TTL:128 (ethernet1-2.iedgebnc5.isp.belgacom.be bogus rDNS: host not found [authoritative])

194.78.133.222 RTT: 126ms TTL: 46 (No rDNS)

01/10/05 21:09:28 Slow traceroute 194.78.133.224

Trace 194.78.133.224 ...

144.232.9.162 RTT: 114ms TTL:128 (sl-bb22-lon-12-0.sprintlink.net ok)

213.206.129.42 RTT: 118ms TTL:128 (sl-bb20-bru-14-0.sprintlink.net ok)

80.66.128.46 RTT: 120ms TTL:128 (sl-gw10-bru-14-0.sprintlink.net ok)

* * * failed

194.78.0.54 RTT: 124ms TTL:128 (ethernet1-1.iedgebnc5.isp.belgacom.be bogus rDNS: host not found [authoritative])

194.78.133.224 RTT: 131ms TTL: 46 (No rDNS)

I can't say that these resullts are "wrong" .. but they sure are different .... There's nothing at all about an akamai server in the IP addresses you seem to be getting. What is "failing" in these SamSpade for Windows trace-routes in not clear, but noting that different servers are touched on the way in ... not a lot of answers here, I know .. but still playing with things .. off to try some other tools ...

Link to comment
Share on other sites

I don't know your Iowa IP, but before I reboot (and get a different IP) here's a "reverse traceroute" on the one you showed (sorry, I had my HDD replaced last week, and those Dutch *$%£ put a Dutch-language Windows on it.)

Bezig met het traceren van de route naar so-1-0-0.mp2.Brussels1.Level3.net [212.187.128.2]

via maximaal 30 hops:

1 20 ms 15 ms 15 ms 1.113-200-80.adsl.skynet.be [80.200.113.1]

2 17 ms 14 ms 15 ms at-0-0-0--0-41.iadslbnc2.isp.belgacom.be [194.78.255.249]

3 15 ms 15 ms 15 ms ge0-0.intlmar1.isp.belgacom.be [194.78.0.47]

4 14 ms 16 ms 16 ms ge-8-1.hsa2.Brussels1.Level3.net [212.3.234.177]

5 12 ms 16 ms 16 ms so-1-0-0.mp2.Brussels1.Level3.net [212.187.128.2]

De trace is voltooid.

Link to comment
Share on other sites

It's been an interesting last few hours, going crazy with some really odd results from all over the place. The explanation for all kinds of 404s and timeouts turns out to be my fine cable company, doing some unannounced maintenance, and of course, doing it a bit atfer midnight as "no one is awake" at these hours. I just happened to be moving a laptop when I saw the cable-modem lights telling me that it was looking for a connection ... while checkings its logs, happened to notice that a normally blinking light on one of my routers wasn't blinking (wht idiot ngineer came up with a "blinking lite means things are good?) .. found two of my routers locked up, not sure when that happened ... writing this while the cable-modem is hooked up

Link to comment
Share on other sites

But still no go with Firefox. Should we tell Julian to remove that small-print line at the bottom of the reporting page? Or should I write a Bugzilla report?

I think that both of those options are very premature, considering that the rest of us using the same platform and browser as you are able to reach the site. In fact, I just logged into several other Linux-based web servers on different backbones and used Lynx to browse to the site without problems. The connectivity issue seems to be closer to your end.

DT

Link to comment
Share on other sites

I think that both of those options are very premature, considering that the rest of us using the same platform and browser as you are able to reach the site. In fact, I just logged into several other Linux-based web servers on different backbones and used Lynx to browse to the site without problems. The connectivity issue seems to be closer to your end.

DT

22894[/snapback]

Lynx... now that's an idea. Haven't reinstalled it yet after the disc crash but I'm going to. I still would like to know why IE can access SC with no problems and FF doesn't even see it.

Link to comment
Share on other sites

I had thought that my first two posts in http://forum.spamcop.net/forums/index.php?showtopic=3288 had clearly shown the issue.  It is internal to akamai.net, and is clearly a case of their own servers timimg out internally (look at the "telnet" tests).

P.S.  I haven't seem the problem myself since my last post on  the subject.

22905[/snapback]

That doesn't explain, or at least not satisfactorily for me, why I can reach www.spamcop.net/ without the least problem when I use IE6, while at the same time FF is incapable of showing anything of it: If I start on an "about:" tab in Firefox, then modify the contents of the URL bar to http://www.spamcop.net/ and click Go, then "Done" reappears after about a second but the displayed contents don't change. If I click on a tracking URL in an Autoresponder email open in Thunderbird, then Firefox -- my default browser -- opens a new tab but it is uniformly grey and the tab is titled "(Untitled)". All the while IE6 happily chugs through email parsing and reporting as if nothing were the matter.

Link to comment
Share on other sites

I had thought that my first two posts in http://forum.spamcop.net/forums/index.php?showtopic=3288 had clearly shown the issue.  It is internal to akamai.net, and is clearly a case of their own servers timimg out internally (look at the "telnet" tests).

I don't think so. You don't test a web server's response using either Telnet or Ping. You test it only via attempted HTTP connections. A long time ago, you could ping and/or telnet to servers, but due to the various types of DOS (denial of service) issues in recent years, server admins have closed all the non-essential ports on web servers and the routers/firewalls that lead to them, so this type of testing only works on servers that aren't fully protected.

I think that the problem for both of you OP's is local to your own connectivity and/or computers.

DT

Link to comment
Share on other sites

Please note slight change in this Topic title.  There seems to be some divergence between two discussions.

22968[/snapback]

Thanks. Apparently there are two distinct problems (one with Akamai and the other with Firefox). This change helps to tell which is which.

Link to comment
Share on other sites

https://bugzilla.mozilla.org/show_bug.cgi?id=233420 ... although mozilla oriented, seems to have some close symptoms ....

http://computercops.biz/postt89945.html offers a command-line things that allegedly works ..????

And worst case. http://www.akamai.com/en/html/misc/support_faq.html has some details about port usage, connection details ...

Link to comment
Share on other sites

I don't think so. You don't test a web server's response using either Telnet or Ping. You test it only via attempted HTTP connections. A long time ago, you could ping and/or telnet to servers, but due to the various types of DOS (denial of service) issues in recent years, server admins have closed all the non-essential ports on web servers and the routers/firewalls that lead to them, so this type of testing only works on servers that aren't fully protected.

I think that the problem for both of you OP's is local to your own connectivity and/or computers.

DT

22916[/snapback]

% telnet www.spamcop.net 80

is a HTTP connection (for those who are Windows-based clueless).

With no third argument telnet defaults to TCP port 23 (for anything else, on any *nix, remember to disable the enviroment passing and protocol negotiation in most cases -- the MS client will not initiate them, so it is actually easier to use in a few cases). One of its great abilities is to connect to any TCP port, and if you know the protocol well enogh, you can test it "by hand". Even the MS version will do this for you - try sometime connecting to a SMTP, HTTP, SSH or any other tcp based server (if you're stuck on a MS box, "putty" works very well and in older versions always requires you to enter the port, current versions default to port 22 - SSH, which really is the intended purpose of the program).

In fact, I spent about an hour and a half, this week, helping a registrar debug a problem with his proprietary 'whois' server (which was/is returning short replies) - much of that time was spent with "telnet host.xx.tld 43" and typing the queries manually -- BTW. many name name servers will still respond to "obsolete commands" that have either been removed from bind9 (and some bind8 versions on Redhat) clients or aren't supported by the MS Windows client (the "ls" comand is the most useful and common of these - it does an AXFR of the domain's entire database - if allowed). Learning to use telnet for more than just tcp port 23 is one of the first tools to master if you ever hope to do *real* network debugging. After you get that done, learn a few more tools (in particular netcat or "nc") so you cat debug/test non-tcp ports also (trickier mostly because the protocols are more likely to be binary, and lots of UDP stuff has weird handshaking rules - to make up for the lack of reliable delivery - that you must remember to abide by, or your connection just drops). After you understand "real" connections, we can talk about forged packets, MiM attacks, traceroute spoofing and the variety of "tricks" that both the white and black hat communitees use.

You could also have taken a look at the posts and seen that I posted HTTP sessions, just using telnet to initiate them (it shows much more detail than a browser *because* the HTML is uninterpreted (re. "raw").

Also, I have multiple ISPs and lines coming in here, these connections were not only to different addresses, but were done using different source IPs and different outgoing networks (on different ISPs, on completely separate AS's - read as routes, if you don't know what an AS is - once they got outside of my network).

Anyway, "my" posts show what clearly is akamai timing out on tallking from the host a369.g.akamai.net to the caching proxy behind it, but internal to akamai's own network (look up the difference between a "404" and a "408" in the protocol) ; I also noted that the connections were immediate with the timeout coming from the other side (something you can't determine from most browsers, though lynx in debugging mode can give you some information).

Also, just as a note, all of my 300+ addresses "appear" to respond to pings, traceroutes and *many* other "non-essential" ports, just my first level firewall forges packets in response to the probes to prevent any trivial probing from providing much info (though tools like nmap and hping, can be used to "see' that some of those responses are forged). Administrators who just shut ports usually don't know what they are doing (often creating path-MTU blackholes by blocking ICMP); Unfortunately "common" wisdom is mostly incorrect (particularly the "stealth" vs. "drop" arguments). My network uses the same defenses as those I have built for Fortune 100 companies (and mostly large computer or electronics companies at that). So your only correct statement might be that you can't trust the results you see with ping until you've probed further and with an arsenal of other tools also (I use the "firewalk" project as a guideline, as long as they can't catch the defenses, I feel mostly safe - depending on how you want to count I was "attacked" on various address spaces between 10,00 & 25,000 times last week, logging 347,000 packets that were blocked and either dropped or generated forged responces, so I can tell you that there are plenty of "black" hats out there who know some of this too).

The comsumer level "firewall" boxes, even the lower-end Sonicwall , Cisco PIX, etc. boxes aren't really any protection from a knowlegable hacker; Fortunately most home users *are* safe if they don't run any servers AND sit behind a NAT box with at least some SPI. But personally, I know of too many flaws in all the major brands, and so do too many other people, to use them for *anything* which allows *any* incoming connections (i.e. don't let your browser do any active ftp, a hacker or someone like me can hijack the back channel trivially). As a side note, many/most spammers don't bother with firewalls, they do tend to run SEL-Linux and OpenBSD quite a bit on their machines (a real firewall takes a *lot* of resources, and examining the logs is not for the faint-hearted).

% telnet www.spamcop.net 80

Trying 209.247.88.168...

Connected to a369.g.akamai.net.

Escape character is '^]'.

HTTP/1.0 408 Request Time-out

Server: AkamaiGHost

Mime-Version: 1.0

Date: Sun, 26 Dec 2004 13:39:08 GMT

Content-Type: text/html

Content-Length: 163

Expires: Sun, 26 Dec 2004 13:39:08 GMT

<HTML><HEAD>

<TITLE>Request Timeout</TITLE>

</HEAD><BODY>

<H1>Request Timeout</H1>

The server timed out while waiting for the browser's request.<P>

</BODY></HTML>

Connection closed by foreign host.

and

% telnet www.spamcop.net 80

Trying 166.90.133.200...

Connected to a369.g.akamai.net.

Escape character is '^]'.

HTTP/1.0 408 Request Time-out

Server: AkamaiGHost

Mime-Version: 1.0

Date: Mon, 27 Dec 2004 12:40:38 GMT

Content-Type: text/html

Content-Length: 163

Expires: Mon, 27 Dec 2004 12:40:38 GMT

<HTML><HEAD>

<TITLE>Request Timeout</TITLE>

</HEAD><BODY>

<H1>Request Timeout</H1>

The server timed out while waiting for the browser's request.<P>

</BODY></HTML>

Connection closed by foreign host.

Fatal error in process.

Link to comment
Share on other sites

Thanks for the long "tutorial," but in this particular case, I think you're off track. Here's why.... of course I know that web servers listen on port 80, and yes, the "telnet to port 80" method *used* to be one way of checking on a web server, but it doesn't seem to work like you think it does anymore.

Before I posted my "ping and telnet don't work for checking web servers anymore" response, I ran some tests while SSH'ed (using PuTTY) into a shared Linux/Apache web server in the Alabanza server farm in Baltimore. I tried "telnet spamcop.net 80" and also did the same for google.com and other large sites and *none* of them responded with a web page (I got the same "Request Timeout" rendered in raw HTML mentioned elsewhere). When I attempted a Lynx connection directly to the IP reported in the failed telnet session (such as lynx http://146.82.218.134), I get a 400-level "Bad Request" response and the "The requested URL "/", is invalid." error message (in HTML, which Lynx renders). I think that a factor here is the Akamai "EdgeSuite" distribution technology that SpamCop is using. You'll find info here:

http://www.akamai.com/en/html/services/edgesuite.html

In order to test web servers, I use Lynx on the box I mentioned above, in that it more closely emulates actual incoming browser requests. So, even from the box which can't do the "telnet spamcop.net 80," I'm always able to do "lynx http://spamcop.net" successfully.

DT

Link to comment
Share on other sites

The above discussion and tutorial would, IMHO, be more at home on the other thread (about Akamai issues).

The only explanation I can see for the differences between IE and FF to be attributable to Akamai would be if Akamai used some "non-Mozilla-compatible" HTML on its edge servers -- a distinct possibility considering Bill Gates's aggressive marketing practices, but which should definitely be regarded as a severe bug.

Does anyone know how to enlist Akamai's help in resolving the present compatibility problem between IE and (let's call it) Mozilla-based browsers in respect to Akamaized sites?

Link to comment
Share on other sites

As you state .. I wrestled with moving some posts around last night but as you see ... These last posts really helped to confuse the Topics once again .. so I'll just say that I had just posted over on the "Akamai" Topic that I'm making the complaint that Akamai doesn't answer e-mail. My experience with that goes back to when I first started seeing Akamai links showing up in my browser ... I had e-mail out to all kinds of folks asking about the apparent hijacking going on, in addition oto asking Akamai to identify themselves ... back then, there was no Akamai web-site.

Link to comment
Share on other sites

As you state .. I wrestled with moving some posts around last night but as you see ...  These last posts really helped to confuse the Topics once again .. so I'll just say that I had just posted over on the "Akamai" Topic that I'm making the complaint that Akamai doesn't answer e-mail.  My experience with that goes back to when I first started seeing Akamai links showing up in my browser ... I had e-mail out to all kinds of folks asking about the apparent hijacking going on, in addition oto asking Akamai to identify themselves ... back then, there was no Akamai web-site.

22986[/snapback]

Considering the facts that there is a (very discreet) advertisement for Firefox at the bottom of SpamCop's front page, and that (unlike us) SpamCop/IronPort is a cash-paying customer of Akamai, couldn't the problem be attacked from the other end? If Julian were to complain to Akamai that "all his subscribers with Mozilla browsers" can't get to the SpamCop site, I believe we should expect some action...

Link to comment
Share on other sites

If Julian were to complain to Akamai that "all his subscribers with Mozilla browsers" can't get to the SpamCop site...

But that's simply not true. I'm using FireFox 1.0 and am having no problems whatsoever with the SpamCop.net site. How many people are actually reporting this specific problem? (the browser issue, that is)

DT

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...