ietf-nntp BCP for RFC977 server/RFC1036 interaction

Rich Salz rsalz at osf.org
Fri Apr 4 13:22:54 PST 1997


>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 ;-)

You spelled practices wrong. :)

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

I gather consensus is to put both.  I'd like to see you define the
syntax for this.

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

Is nntp-p-u limited only to identd?  suppose I put the X.500 DN if
coming in over SSL?

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

Only if incorrect, right?  Use same wording as for Sender, below.

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

I would say that implementations MUST either put some valid email address
or REMOVE the header.

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

Minimally acceptable provided the NNTP server can in fact deliver that
mail or MX configs get it to the right place.

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

agree, but only if the alternative is to remove all unverified sender
headers.

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

I think it is worth saying (a) is preferred only because it cuts down on
some Path fluff.  Unless there is anotehr reason, avoiding expansion of
the Path header by 20 bytes doesn't seem a compelling reason to me.  I
agree it has some merit, but I want that merit qualified. :)

	/r$



More information about the ietf-nntp mailing list