Custom Query (44 matches)


Show under each result:

Results (34 - 36 of 44)

2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ticket Resolution Summary Owner Reporter
#109 wontfix nnrpd doesn't return 420 errors for XOVER eagle Julien ÉLIE

According to RFC 2980, section 2.8:

If no articles are in the range specified, a 420 error response is returned by the server.

nnrpd (from the beginning of the XOVER command) has always returned a 224 response with an empty multiline response instead.

Note that the OVER command properly returns 423 (no articles in that range) when that case occurs. 420 is sent when the current article number is invalid.

Impact: Less information is communicated to the client about why there are no overview records returned. An error response indicating there are no valid articles in that range is possibly more informative.

There is probably no way to fix this now. Changing the reply codes would break a few existing implementations: it may confuse some clients that don't expect to get 420 errors back from overview queries. Clients may be relying on the existing behavior (confirmed with Outlook Express/Windows? Mail for instance).

#110 wontfix innd and nnrpd do not advertise IHAVE for the entire session eagle Julien ÉLIE

According to RFC 3977, section 3.4.1:

Except as an effect of the MODE READER command (Section 5.3) on a mode-switching server, once a server advertises either or both of the IHAVE or READER capabilities, it MUST continue to advertise them for the entire session.

If IHAVE has been advertised, it will not necessarily be advertised for the entire session. innd and nnrpd only advertise the IHAVE capability when it is really available.

Impact: Probably none. It is sort of a weird edge case, since having such basic commands disappear after authentication is a little odd and would require an unusual configuration. It is probably not worth fixing. Besides, such a fix seems to partly defeat the point of the capability system.

#111 fixed Advertise extensions to the LIST command eagle Julien ÉLIE

INN recognizes LIST keywords not mentioned in CAPABILITIES. They should be documented in an Internet-Draft.

  • LIST SUBSCRIPTIONS (with a wildmat)
  • Define the meaning of some other status fields of LIST ACTIVE:
    • j No posting allowed, incoming articles filed into junk
    • x No posting allowed, remote postings rejected
    • =* Group aliasing

The meaning of a junk newsgroup will have to be described.

How could we advertise these new status fields? (EXTENDED-STATUS, with a version number, as a new capability?)

Available references:

2 3 4 5 6 7 8 9 10 11 12 13 14 15
Note: See TracQuery for help on using queries.