ISP Port Blocking

Filtering never announces itself. The client reports either a timeout, where packets are silently discarded, or an immediate refusal, where the network answers with a rejection on the server's behalf. Neither message mentions the access provider, which is why a reader can spend an evening re-entering a password that was never wrong. The account, the hostname and the credentials are all intact; the traffic simply never leaves the local network.

The signature is one port working and another not

Add a second server entry for the same provider with the same credentials, set it to port 563 with SSL enabled, and connect. If that entry works while 119 fails, the diagnosis is settled: the provider is up, the account is valid, the hostname resolved, and the only variable that changed was a port number. No other fault produces that pattern. An outage takes down both ports. Wrong credentials fail on both. A certificate problem cannot occur on 119 at all.

Why access networks filter 119

The practice dates from the period when access providers ran news servers themselves and then shut them down, and from later efforts to limit unencrypted binary traffic and the abuse complaints attached to it. Mobile networks, hotel and campus networks, and many corporate links filter far more aggressively than residential lines. The filtering is normally applied to the port rather than to any particular destination, so changing news provider accomplishes nothing while the port stays the same.

Ports that tend to stay open

Providers commonly listen on 563 for encrypted sessions, and often on 80, 443 or 8080 as well. Those alternates carry the same NNTP traffic; they exist because filtering rarely touches the ports ordinary web browsing depends on. Where 563 is blocked too, which happens on tightly managed networks, 443 is the next candidate. Which alternates are available should be taken from the provider's documentation rather than guessed, since a port with nothing listening returns a refusal that looks like an unrelated fault.

Conditions that are not port blocking

Slow throughput on a port that connects is not blocking; that is shaping, or a bottleneck on the local machine. A session that opens, authenticates and then hangs once article data flows is not blocking either, and points at packet size problems along the path. Blocking is all or nothing on a given port: either the session establishes or it never does. A network that permits 563 at full speed while dropping 119 is not throttling Usenet in any meaningful sense, since the encrypted path is unrestricted.

Who can fix it

Neither the news provider nor the reader can unblock the port; that decision belongs to the access network, and support requests about it are rarely productive. The workable response is the one the industry already built for it, which is to use an encrypted port. That also removes any question of the traffic being inspected on the way, so for most readers moving to 563 is a permanent change rather than a temporary workaround.