Tiffin said:
I need help with the news server please, this is the error message i am
getting:-
Account: news.bigpond.com
Server: news.bigpond.com
Protocol: NNTP
Port: 119
Secure(SSL): 0
Code: 800ccc0f
TIA Tiffin
You're using WLM 15 (Windows Live Mail).
According to the thread here, you can get that error when using NNTP protocol.
When I started doing searches, the error seemed related to doing mail,
but NNTP can apparently also give the error. The error is:
"The TCP/IP connection was unexpectedly terminated by the server."
News servers can support more than one port and more than one protocol.
For example, AIOE supports 80 (HTTP port), 119 (NNTP port), 443, 563 (SSL ports).
If WLM supports setting the port number, and using a different port, you
could try that. (If WLM doesn't, then download and install another news reader,
like Thunderbird.)
http://www.aioe.org/
I can't find any details for the Bigpond server, similar to that page for
AIOE. So I can't recommend an alternative port.
If you lived in England, the ISPs there, seem to throttle 119 during the
"busy" part of the day. So perhaps 12 hours a day, you'll have problems posting
in England.
You'd need to know, whether the Australian ISPs currently throttle or have a
plan to throttle USENET. USENET binary servers, are known to be a source of
movie downloads, and Hollywood would like nothing better than to shut all of
them down. If they can convince ISPs to discontinue the service, they would.
In terms of throttling mechanisms, my ISP instituted something called a "God Box"
a couple years ago. Initially, they were quite inept at setting it up. Instead
of aiming their "big gun" at just Torrent traffic, they also manage to hit ordinary
HTTP. I started seeing "RST" packets, and I could tell from the timing of
the packets (their prompt arrival), they had nothing to do with the destination
server. Here is how an ISP does a "man in the middle attack" on your traffic.
Home User ------------------- ISP -------------------------- Some server
------+ +------
| |
<--- "RST"---+ +----"RST" --->
By sending a "RST" or Reset packet in both directions, they can tell the
devices on either end of a connection, to take the connection down.
So, how can you detect that ?
You could use a copy of Wireshark.
http://en.wikipedia.org/wiki/Wireshark
The thing is, "RST" is a valid part of protocols. Normally, it would be
used like this. Here, a server which cannot handle the connection, can
send a "RST" to the user, effectively taking down the connection. But you'd
expect such a response to take some time. If the server was overloaded,
it might take a few seconds to respond. It's when the RST shows up *instantly*,
you begin to smell a skunk - namely, that the ISP is doing a man in the
middle attack. Even with a copy of Wireshark, there is no sure way to know
where the "RST" is coming from. The ISP can fake any part of the protocol
they need to, and the God Box is only too willing to please. The quaint term
the ISP uses for this, is "traffic management", where an arbitrary policy
is applied using Deep Packet Inspection in real time.
Home User ------------------- ISP -------------------------- Some server
<--- "RST"------------------------------------
If the ISP has a God Box, they can detect virtually any kind of protocol
which is running. At their option, for example, they could even drop
an encrypted VPN or stop any encrypted traffic. So even if a user attempts
to get around their throttling schemes, an ISP can decide on their own,
to stop all encrypted traffic if they want, and if they can get away with
it. And some governments, make this easy.
http://www.dslreports.com/forum/r21038903-Bell-Now-Throttling-FTP-As-Well.~start=140
*******
Of course, this could be a temporary problem, such as the Bigpond server has
crashed, like the front end still works, and the back end is crashed. If Bigpond
has a "status page" for their news server, you'd want to check that to see if
they've already acknowledged a problem.
If this pattern of behavior has been there for days and days, there could be
more to the story.
Paul
