ietf-nntp BCP for RFC977 server/RFC1036 interaction
Chris Lewis
clewis at nortel.ca
Wed Dec 18 07:43:00 PST 1996
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.
clewis at nortel.ca; Dept 4C16, Ottawa, Canada. (613) 763-2935.
More information about the ietf-nntp
mailing list