Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction

[USENET news manager <[e-mail]>]

Chris Lewis wrote:
>[about a proposed Best Current Practises" document]
>...
>Section 1 (the stuff we talked about at the BOF) is essentially one of
>the following three alternatives:

They don't look like alternatives to me (in the sense that you'd choose one 
or other of them)! [Also, for those of us who weren't there, passing 
refrences to face-to-face discussion serve to frustrate rather than inform!]

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

That's not what INN does - it rejects POST attempts with the message

Can't set system "NNTP-Posting-Host" header

Accepting postings but inserting the correct information seems like a reasonable
alternative approach.

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

                                John Line
-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
[e-mail]    (alias {newsmaster,news,usenet}@news.cam.ac.uk)