500 Command Not Recognized

Reading a session log for the first time makes this code look worrying, because it appears early, sometimes several times, and contains the word not recognized. In practice it is how the protocol negotiates. A client offers something better, the server declines, and the client uses the ordinary command instead. The transfer that follows is completely unaffected.

Ordinary during session setup

Clients probe. A newsreader that supports compressed overview retrieval will try it, because on a large group it saves a great deal of bandwidth and time. A server that does not implement it answers 500, and a well-written client falls back to plain XOVER without complaint. The same happens with streaming and with various non-standard extensions. One or two 500 lines at the start of a session followed by normal downloading is negotiation working exactly as intended, and there is nothing to fix.

Commands most often refused

• Compressed header commands such as XZVER and the various vendor spellings of the same idea, which are widely deployed but were never standardized.
• MODE STREAM, which belongs to server to server transfer and is refused on reader-facing ports.
• IHAVE and other transit commands, likewise irrelevant to a reader session.
• Occasionally CAPABILITIES itself on older software predating the current specification, which is a fair signal that other modern commands will also be missing.

When it does indicate a real problem

Two situations turn it into a genuine fault. The first is a client that does not fall back, and instead retries the refused command or treats the refusal as fatal; that shows as a session that never gets past setup, with the same 500 repeating. The second is a malformed command reaching the server, which happens when something between client and server is corrupting the stream, and tends to come with other odd behavior rather than appearing alone. A 500 in reply to a plain ARTICLE or GROUP is not normal and points at a damaged connection or an intercepting device rather than at a missing feature.

Checking what the server advertises

Issuing CAPABILITIES at the start of a session lists what that server implements, which turns guesswork into a lookup. Clients that expose a connection test or a raw session view make this visible without extra tooling. If the extension a client keeps trying is absent from that list, the client is asking for something that will never be granted, and the corresponding option in its server settings can simply be switched off to keep the log clean.

Where the fault sits

Nowhere, in the common case. The server is entitled not to implement optional extensions and the client is entitled to ask. Where a fault does exist it is the client's, either for failing to fall back or for having an extension forced on in its settings that the server has already declined. It is not an account problem, not a retention problem, and not something a provider can enable on request for a single subscriber.