[NNTP] Article Numbers Becoming Invalid (RFC 3977)

[Russ Allbery]

Sabahattin Gucukoglu <mail at sabahattin-gucukoglu.com> writes:

> OK, I see the problem here: RFC 977 defined both codes for use with the
> article <number> syntax, while RFC 3977 didn't.  So we ignore RFC 977,
> and all is right with the world again. :-)

> The problem was that maybe the RFC 977 use of code 430 meant something,
> say, "That article number is in range but its data can't be found on
> disk" or some such.  But I see now that codes 423 and 430 mean the same
> thing, for number and Message-ID respectively.

This didn't really change between RFC 3977 and RFC 977 except that RFC
3977 more clearly breaks out the return codes for their allowed context
and RFC 977 didn't.  But I think the intention of RFC 977 was the same:

   423 no such article number in this group
   430 no such article found

To know for sure, though, one would need to check the reference NNTP
implementation that was developed in conjunction with RFC 977 and see what
it did.

> Probably should be noted somewhere though - I am seeing a Tornado use
> 430 exclusively (I have no access to an inn install).  Suck, a program
> with similar uses but for feeding a local spool, gets around this
> entirely by just using xhdr.

Clients can generally treat 423 and 430 as synonymous.

> I still have a concern though: RFC 2980 clears up the detail of article
> numbering, monotonically increasing.  So how does a news server work
> efficiently if the last article number just added is instantly removed?
> Now, the group's high watermark is lowered again,

It works by not doing that.  :)

The group's high water mark for the purposes of new arriving articles must
not decrease.  In other words, a new arriving article must receive a
higher article number than the article that was removed.

RFC 3977 allows for the high water number reported to the client to
decrease, but that's because it allows for the removed article to be
reinstated.  But that article number cannot be reused for a different
article.

> And even if that isn't the case, the server will have to note a next
> article number that is greater than the high watermark it reports, in
> order that it not reuse the recently removed article's number.

The server is permitted to report a high-water mark that's larger than the
highest number of the retrievable articles in the group.

> How does it do that, if at all?  If it doesn't reset the high watermark,
> it's a liability to clients taking the maximum number as gospel, since
> they will fail to receive the article with the highest article number.

Which is fine.  That can happen for any article if it's been removed.
There's nothing special about the highest-numbered article.

> This seems like the next obvious thing to try, thanks.  Right now it
> just blindly tries every article number from min to max, which works 99%
> of the time, of course.  Perhaps these removals are the results of spam
> filtering?

Usually, yes.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>