ietf-nntp new Draft available

[Andrew Gierth]

>>>>> "Stan" == Stan Barber <sob at academ.com> writes:

 Stan> The next draft is available in the usual place:
 Stan> ftp://ftp.academ.com/pub/nntp/ietf/nntpext.txt.

 Stan> Enjoy. See you Monday.

Unfortunately not in my case :-(

Here are my comments on the draft (in addition to my previous
comments on the PAT command):

11.3 NEWGROUPS and 11.4 NEWNEWS

The syntax for NEWGROUPS allows (as an addition to current practice)
the use of "UTC" as an alternative to "GMT"; the syntax for NEWNEWS
does not. This should be made consistent, preferably by removing UTC
unless there are real (rather than purely aesthetic) reasons to allow
it.

9.3.2 IHAVE

The final example and use of the 435 response is not consistent with
current practice.

Looking at code in use, I see the following cases:

1. refusal

  [C] IHAVE <message at id>
  [S] 435 no thanks

2. deferment

  [C] IHAVE <message at id>
  [S] 436 try again later please

3. accept

  [C] IHAVE <message at id>
  [S] 335 yes please
  [C] ...sends message headers and body...
  [C] .
  [S] 235 ok

4. reject

  [C] IHAVE <message at id>
  [S] 335 yes please
  [C] ...sends message headers and body...
  [C] .
  [S] 437 rejected

I'd expect to have to handle the case of getting 436 after the body
is sent, but I don't recall seeing it happen in practice. 436 in
response to the initial IHAVE occurs with, for example, INN without
the "noresendid" option.

At least one widely-deployed feeding client (innfeed) has a nasty
tendency to do this:

  [C] IHAVE <message at id>
  [S] 335 go ahead
  [C] .
  [S] 437 empty article

if the article it was going to send turns out not to be available.

14. Security considerations

Firstly, I suggest that the order should be reversed, with the
paragraphs on access control etc. coming before the ones on logging
and proprietary info.

The section on DNS spoofing, while it touches on the issue of
mismatched forward/reverse lookups, should, IMO, spell out explicitly
the requirement that reverse DNS lookups should be confirmed by
performing the forward lookup before the returned name is used for
either access control or logging or trace information (including trace
headers added to posted articles).

Earlier versions of both Typhoon and (I believe) DNews have been
vulnerable to trivial DNS spoofing, despite the fact that this issue
is hardly new and was fixed in INN many years ago.

An additional section to the security considerations should be added
pointing out the effect that a single insecure site can have on the
larger NNTP network(s) of which it is part (whether the global Usenet
or some other network).

-- 
Andrew.