We use cookies to understand how the site is used and to improve it. You can accept them, or carry on with them switched off.
Also known as: 423 error, no such article number
Returned to an ARTICLE, HEAD, or BODY command naming an article number outside the range currently held for that group. The number either expired out of the spool or never existed, since numbering is per server and gaps are ordinary. Clients working from a cached header index cause most of these, and refreshing headers for the group realigns local numbering with what the server actually holds.
The distinction that makes this code make sense is that an article has two identities. Its Message-ID is global and means the same thing on every server in the world. Its article number is a local counter, assigned by one server, for one group, in the order that server happened to receive things. A 423 is always about the second kind of identity, which is why it says so little about whether the article exists.
Two servers carrying identical content will number it differently, because they received it in different orders from different peers, and because each has been running for a different length of time. Numbers are never reused and are never renegotiated. An article number written down against one provider is therefore meaningless against another, and a client that carries numbers across a server change will ask for things that cannot exist. Requests by Message-ID are immune to all of this, which is why NZB-driven downloading rarely produces 423 at all.
Selecting a group returns the estimated article count along with the lowest and highest numbers currently held. Everything below the low-water mark has expired out of the spool, and that boundary advances continuously as retention rolls forward. A number that was valid last week can fall below it without anything having gone wrong. Gaps above the low-water mark are equally ordinary: numbers are allocated for articles that were later canceled, rejected by a filter, or never completed, so the range is not dense and a miss inside it proves nothing.
Most 423s come from a header index the client built earlier and is still trusting. Header downloading clients cache the overview data for a group and work from it; when that cache is old, or was built against a different server, the numbers in it no longer line up. Refreshing headers for the affected group rebuilds the index against what the server holds now. In clients that maintain a local header database the relevant action is a group rescan or a purge of the cached overview rather than anything to do with connections or credentials.
The two are easy to confuse because both mean the article did not arrive. A 430 answers a request made by Message-ID and means that specific article is not in the spool, which is a statement about content. A 423 answers a request made by number and means the number is outside the range this group currently holds, which is a statement about bookkeeping. Fault for 423 sits with the local client and its cached index far more often than with the server, and a reader seeing both codes together is usually looking at one stale index and one genuinely aged post.
Browse all terms in Errors & Troubleshooting, or see the full Usenet glossary.