ietf-nntp BCP for RFC977 server/RFC1036 interaction

[Chris Lewis]

I think a reply to this, with a few other notes thrown in, encapsulates most
of the discussion so far.

In message "Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction", 
'rsalz at osf.org' writes:

Re: pre-existing NNTP-Posting-Host/NNTP-Posting-User/Sender on POST:

The real thing we want to arrive at is to ensure that a BCP-compliant
server produces articles with only one each of these headers, and that
it should be as correct as the server can make it.  Thus, for example,
we could say:

	- The resulting article should have only one of each of these
	  headers [it was possible to trick one of the NNTP ref
	  implementations to have two NNTP-Posting-Host, and another
	  could be tricked into not correcting a pre-existing one].
	- The result of supplying one could be one of:
		1 reject the posting outright, regardless of whether
		  the header is wrong.
		2 reject the post it only if it's wrong, and don't insert
		  a new one.
		3 remove the incorrect one, and supply a correct one.
		4 remove it unconditionally, and supply a correct one.

3&4 are effectively the same thing.  We could insist that a single
"correct" one appears in the resulting article, and the result of
presupplying one is left undefined by the BCP.  Howzat?

Re: the three behaviours (NNTP-Posting-Host/NNTP-Posting-User+Host/Sender)
    I don't consider them mutually exclusive.  And the second is a superset
    of the first.  Perhaps a sentence saying "A BCP-compliant implementation
    will do one or more of the following" is better than "alternates".
    
    Howzat?
 
>>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).

>*May* put it as a header, not *should.*  A "Note" could be added saying
>that system administrators may optionally wish to record the ifnormation
>in off-line logs.  Trusting identd is not a binary decision.

I figure that if it's worth using identd, it's worth supplying the information
as generated as people already are.  I think the limitations of identd are
as sufficiently well known as the limitations of absolutely trusting
purported authentication on a message - it may have been forged on an
intermediate site, or the originating site may not be following the
BCP.  As in, even with PGP-like signatures, none of this is absolutely
trustable by a third party anyways, and relies on the original server to
confirm.  I'm primarily providing enough assists to get third parties to
figure out where most of it comes from.

Remember this is a BCP, not a standard, so a site can choose to deprecate
the "should" to a "may" if they wish.  Does making this a suggestion for
a server-configurable parameter solve the issue?  Alternately, I believe
that a server implementor could use the "unique identification" stuff
under Sender below, and externally anonymize the identd cookie.

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

>It *SHOULD* set sender if it is different from the From header.

I *SHOULD* have (and meant to have) said that ;-)  The current
implementations do this I think.

Re: whether authentication always produces a useable email address...
Well, we fall into the current situation vis-a-vis RFC1036 and some
sites that can't always produce useful email addresses.  RFC1036 From:
I think requires usable return addresses, but practise and implementations
don't.

Eg: up until recently, most of our users couldn't receive email (policy),
but had perfectly syntactically valid and audit-useful "user at bnr.ca" 
addresses.

If I put some verbiage in that said something like the following,
would this be satisfactorily encompassing the issue?

	As per RFC1036, the Sender is syntactically an email address,
	but the intent here is specifying a method by which the originating
	server can uniquely identify the originating entity.

	In the real world even the best possible value isn't always a
	usable email address.  The intent here is that the Sender:
	should be a valid email address for the originator if available.
	In most cases, a full authentication mechanism (such as via
	AUTHINFO GENERIC querying a user database) will often be able to
	construct a usable email address.  If, however, a usable email
	address cannot be derived this way, it is acceptable for BCP
	purposes to produce a syntactically valid email address that
	contains both a unique identification traceable to the originating
	entity, and the relevant domain name.

	For example, in the absence of a usable email address, a BCP-compliant
	server could generate:

		<authentication id>@<serverdomain>

	Where authentication id either uniquely identifies the originator,
	or uniquely identifies a authentication log entry showing the
	authenticated originator.  Etc.

	Normal RFC1036 rules for constructing Sender addresses apply, hence
	a BCP-compliant site may need to construct transforms on the
	authentication id to produce syntactically valid Senders.

	[Note that it has always been intended that the AUTHINFO GENERIC
	mechanism consults a database that not only has authentication
	information, but has ties into "assigned email address" and groups
	that the user is allowed to access.]

>>2) During POST: discard any pre-existing Path:.

[I'm going to let the discussion continue separately.  Other than to
ask if suggesting a default-off "leave Path alone" feature would
satisfy the issue.  I'd prefer to leave this a site-dependent issue,
perhaps done by allowing users to do this via IHAVE, or, permitting the
admin to deny or allow this on POST on a per-user basis.]