Posting Failed

Posting is a distinct privilege from reading, and on most commercial accounts it is a distinct product decision as well. An account whose downloads run perfectly can be entirely unable to post, and this surprises people who reasonably assume one implies the other. The refusal arrives as a response code followed by explanatory text, and that text is the diagnosis; the code by itself rarely separates the causes below.

Accounts that cannot post at all

Many read-focused accounts have posting disabled by default, some resellers do not offer it at any tier, and others gate it behind a separate setting, a support request, or a daily volume cap. No client-side change works around any of that. The distinguishing symptom is uniformity: this cause fails every attempt identically, to every group, at any size, while every other cause below is specific to a particular article or target. Establishing whether the provider includes posting is therefore the first step, not the last.

Header problems

An article submitted with POST must carry the required headers in a form the server accepts. A missing or empty Newsgroups header and a malformed From address are the usual offenders. Servers commonly generate Message-ID and Date when the client omits them, and will reject a supplied Message-ID that is syntactically invalid or already present in the history file.

Duplicate message-ids are usually a retry

A rejection for a Message-ID the server already holds most often means the article was accepted a moment earlier and the client, having lost the response to a timeout or a dropped connection, submitted it again. In that situation the post succeeded and the error is describing the second attempt. The direct test is a STAT command for that Message-ID against the same server, which confirms the article is present without downloading it. Checking a different provider instead is unreliable, because propagation to peers happens on their schedule rather than immediately.

Size limits and the target group

Servers cap the size of an individual article, and a posting client configured to build parts larger than the server permits is refused on the first oversized one. The remedy is the article or line size setting in the posting client rather than anything at the account level. Separately, the target group matters: posting to a group the server does not carry fails much as a read attempt on that group does, and posting to a moderated group does not fail at all but hands the submission to the moderation address, which some clients report as an unexpected response.

Where the fault sits

These refusals are almost always the account or the article, not the network. A session that authenticated and read a group list has demonstrably reached the server. The two local causes worth ruling out are a client pointed at a server or port that offers reading only, and a transfer interrupted mid-article, which the server discards rather than storing partially.