NNTP: OVER/XOVER open-ended range "n-" returns no articles (valid RFC 3977 range rejected as malformed)

[johnanleitner1-Coder]

Summary

parseRange in internal/news/nntpd/server.go rejects the open-ended range form low- (e.g. OVER 5-) as malformed and returns an empty (0, 0) range. As a result, OVER/XOVER with a trailing-dash range return no articles instead of every article numbered >= low.

RFC background

RFC 3977 defines a range as one of three forms:

• number — a single article
• number- — that article through the highest article in the group (open-ended)
• number-number — a closed range

The open-ended number- form is very common in real NNTP clients (e.g. "give me everything from where I left off"). INN, Cyrus, and other servers all support it.

Where the bug is

parts := strings.Split(spec, "-")
...
h, err := strconv.ParseInt(parts[1], 10, 64) // parts[1] == "" for "5-"
if err != nil {
    return 0, 0 // malformed — empty range
}

For spec = "5-", strings.Split yields ["5", ""]. ParseInt("") errors, so the function returns (0, 0) and handleOver then asks the backend for an empty range — returning zero overview lines.

This looks like an over-correction of the earlier "reject malformed OVER ranges" fix (#45/#46): malformed ranges are now correctly rejected, but the valid open-ended form got swept up with them.

Reproduction

1. Select a group that has articles (e.g. numbers 1..20).
2. Send XOVER 5-.
3. Observe: server returns the 224 line then an empty body.
4. Expected: overview lines for articles 5 through 20.

Fix

Treat an empty upper bound as unbounded (math.MaxInt64), and reject specs with more than one dash (e.g. 1-2-3). I've opened a PR with the fix and tests.