ietf-nntp Re: POST, IHAVE, and header-munging

Brian Kantor brian at nothing.ucsd.edu
Sun Apr 6 22:42:22 PDT 1997


Well, hmm.  My first take on this is that the 'greys' aren't so grey
after all; they fall into either of two classes, whether they are
batched/offline or not:

1) news peers, which you trust to put in responsible n-p-h headers, 

2) untrusted clients, that you don't

The firm which downloads a bunch of news, disconnects, then collects
new articles locally from its on-campus clients and later reconnects to
upload those seems to me to fall into one or the other class rather well.

The meaning of the n-p-h header is that the host inserting it is
lending some authority/traceability to the client posting the article.
It's under no obligation to do so, but (as with the 'ident' protocol),
hosts run by presumably 'honorable' sites which do so lend some
credibility to the posting.

In a sense, by accepting an n-p-h header at article injection time,
you're allowing a submitter to vouch for himself.  Implicitly you
MUST do this for peers, since there is no alternative.  In my view,
most simple clients (macs, PCs, other home systems) are not trustworthy.
Clients on managed systems might be - rrn on a timesharing system,
for example.  I suspect that if I trusted what 'ident' returns, I'd
trust their n-p-h headers too.  But that has to be determined by
mechanisms outside the NNTP protocol, so there's not an answer here.

I feel the key is that the n-p-h header was/is a simple 'best effort'
to ensure that there was some check at the door as news articles came
into the system.  It can't be trusted unless the host generating it
can be trusted, and that's a larger question that isn't answerable
by any news standard.

And it will remain that way until cryptographically-strong
authenticators are required for insertion/propagation of all
Usenet news messages.  Fat chance of THAT ever happening.
I'm not even sure that's what we want.
	- Brian



More information about the ietf-nntp mailing list