ietf-nntp BCP for RFC977 server/RFC1036 interaction

[Chris Lewis]

I'm resending this with some minor modifications from the last time (December
I think).  Once we have one more pass of comments, I'll try to do the
formal "convert it to IETF BCP" thing.

Changes marked with a "|".

I've been musing on the subject, and I think the best approach for
discussing how NNTP servers interact with certain news headers
is to attempt to write a Best Current Practises document on
the subject - as was discussed in the December WG meeting.  The
introduction would say something like "It is intended that this document
would be superseded by a new RFC superseding RFC1036".

The title would be something along the lines of "Best Current
Practises regarding Usenet traceability in an NNTP environment
as it pertains to Usenet news article headers".  Which is quite
a mouthful ;-)

Note that I'm specifically not trying to stop anonymous posting from
anonymizing servers.  Just ensure that everything can be traced back
to the originating site and the originating site's notion of user.

I post this here to garner comments, but as it's been ruled off-topic
for RFC977bis itself, it's probably best to keep the discussions short
and sweet.  Or, email me only, and I'll summarize.

The rationale/FYI stuff is contained in [].

Section 1 (the stuff we talked about at the BOF) is essentially one of
the following three alternatives:

1) NNTP-Posting-Host: NNTP servers should place the FQDN or IP address of
   the originating client host in a "NNTP-Posting-Host: <FQDN or IP>"
   header.

|   a) During POST, the news server should ensure that any pre-existing
|      NNTP-Posting-Host is correct, and if not, replace it with a correct
|      one.

   [Existing practise with current NNTP Ref and INN implementations.]

2) NNTP-Posting-User: During POST: NNTP servers using identd for user
   authentication should place the userid in a "NNTP-Posting-User", in
   addition to (1).

   During POST, the NNTP server should discard any pre-existing
   NNTP-Posting-User.

   [Existing practise in some identd installations I've seen.]

|3) Sender: During POST: if the NNTP server performs authentication (eg: one
|   of the AUTHINFO variants), it should set the Sender: to a RFC-1036
|   "From address format" compliant address that uniquely identifies the
|   originator.  It is anticipated that most implementations would
|   insert the email address of the originator, or some
|   <unique identifier>@<originating site> token which can be utilized
|   by the system administrator to identify the originator.
|
|   During POST, the NNTP server should ensure, if there is a pre-existing
|   incorrect Sender, that it is replaced with a "correct" one.

   [AUTHINFO GENERIC implementations in INN and NNTP REF both do this -
   the authenticator modules return a generated email address from the
   authentication sequence.  It is minimally acceptable to use the
   AUTHINFO USER/SIMPLE <user> value and the NNTP server's configured
   domain name.
   
   Some existing configurations of NNTP (particularly NNTP reference
   implementations under some circumstances), will unconditionally
   generate a Sender of "<userid>@<server>", where "userid" is the
   userid under which the NNTP software itself is running.  I believe
   this to be wrong (as did Stan when we discussed this some time ago),
   and should be deprecated in favour of setting it to the authenticated
   address.
   
   Netcom, amongst others, are also doing this via mechanisms I presume
   to be non-AUTHINFO based.]

Some addition[s] worth thinking about:

1) NNTP servers should provide a mechanism by which IHAVE
   connections which are desired to be "wild-carded" (where you
   allow access from non-prearranged sources) provide additional
   tracing information.  Rather like Sendmail inserting IP addresses
|   in Received lines, so forged HELOs can be identified.  Systems
|   should usually configure their feed access to only trusted peer
|   servers, but in some cases, opening up the server wider is desirable.
|   This additional tracing information can be a configurable option in
|   the server.

   Suggested behaviours during IHAVE:

   a) Do a reverse domain lookup, and if the name doesn't match the
      first element in the path, prepend the reverse domain on it
      before adding ones own name to the path.

   b) Unconditionally prepend the IP address of the connecting server
      before adding ones own name to the path.

   [UUNET is presently doing (b) - UUNET's open NNTP IHAVE port had become
   a spammer/forger magnet, but since (b) was implemented, the occurance
   of such injections has fallen off dramatically.
   
   (a) is preferred, but is quite difficult to do in some cases, and
   forces the reverse lookup which is undesirable in some high loading
   situations.]

[DELETED] 2) During POST: discard any pre-existing Path:.

Informational:

1) One intermediate release of NNTP ref generated "X-NNTP-Posting-Host".
   This should be deprecated in favour of NNTP-Posting-Host.
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis at nortel.ca; Dept 4C16, Ottawa, Canada.  (613) 763-2935.