ietf-nntp BCP for RFC977 server/RFC1036 interaction

[Nat Ballou]

> From: USENET news manager <newsmaster at ucs.cam.ac.uk>
> To: ietf-nntp at academ.com
> Subject: Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction
> Date: Wednesday, December 18, 1996 11:43 AM
>
> [...]
>
> >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.
> 
> Having an authenticated username does not necessarily imply you can
derive 
> a valid email address from it, as distinct from constructing something
that
> looks like an email address.
> 
> Combining the username with the client system's hostname is definitely
out
> as a univerally sensible action, since in many situations it will simply
not
> make sense - e.g. posting from a Windows PC that will never listen for
> incoming SMTP mail, or posting from a system of whatever type using a
> per-session dynamically allocated IP address. Substituting an appropriate
> mail domain instead of the client hostname is not necessarily an option,
> either - with decentralised system management, news server usernames and
> mail addresses on client systems would very likely be totally unrelated
and
> with no simple way (or no viable way) to derive one from the other. [In
an
> ideal world, it would be easy. This is not an ideal world...]

Just to be clear ...

I believe all we are talking about here is describing how the
sender: line works today for a current practices doc.  Granted,
there are cases where even today, it is not of much use.

However, I believe everyone agrees that the Sender: line (as defined 
above) does NOT belong in any RFC since not every authentication 
provider is able to derive an email name for an authenticated user.

Nat Ballou
Microsoft