ietf-nntp BCP for RFC977 server/RFC1036 interaction

[Chris Lewis <[e-mail]>]

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.  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 discard any pre-existing
      NNTP-Posting-Host, and insert one of its own.

   [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 (one
   of the AUTHINFO variants), it should set the Sender: to an emailable
   RFC822 address as returned by the authentication mechanisms.

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

   [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.

   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.]

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.
[e-mail]; Dept 4C16, Ottawa, Canada.  [phone].