ietf-nntp BCP for RFC977 server/RFC1036 interaction

[Ade Lovett]

Rich Salz writes:
>
>>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.

Umm.. what's wrong with:

	NNTP-Posting-Host: <hostname> [ " " <ipaddress> ]

this works fine for the two cases:

	NNTP-Posting-Host: extreme.paranoia.org
and	NNTP-Posting-Host: extreme.paranoia.org 193.195.45.2

the only remaining issue is if the particular server is unable, or
unwilling, to produce a DNS name from an IP address.

One method of solving this is to use a simple token that can't be
mistaken for an actual hostname.  Examples could be:

	dns..unavailable
	dns..missing
	dns..look_it_up_yourself_i_cant_be_bothered_to_waste_cpu_cycles

since double-periods are not valid in DNS names.

However, it all depends on what we want this header to do, and what
kind of uses we're going to put it to.  If it's purely for human
examination, any reasonable textual string that is unlikely (not
necessarily *completely* guaranteed) to be a legal DNS name.


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

Trivial to change, if required:

	NNTP-Posting-User: [<authtype> " "] <authinfo>
	with <authtype> implicitly meaning RFC1413-identd if missing

so,

	NNTP-Posting-User: ade
	NNTP-Posting-User: rfc1413 ade
	NNTP-Posting-User: ssl @c=gb@ .....

would all be valid.

> [snip other stuff related to POST]
>

On a related note.. with the ever-increasing power of home computers,
and especially in the UK, where metered local-phone calls mean that
most individuals use offline readers, and bulk upload posting agents
for their outgoing news articles, I'm seeing more and more articles
being offered to us by our customers using IHAVE..  [since all of
our dialup customers have static IP addresses, and as such are
non-permanently connected internet hosts in their own right]

977 doesn't really have a lot to say on the subject of header-massaging
for articles received via IHAVE [we (Demon) already do a certain amount
with Path, X-NNTP-Posting-Host and other headers to ensure traceability
of articles].

It would be nice to see clarification of such header-massaging
for IHAVE'd articles.. even if it's simply something along the lines of:

	"articles received via methods other than POST (e.g IHAVE
	 and TAKETHIS; a common 'streaming' NNTP extension)
	 MAY have headers added and/or replaced as mentioned
	 in <previous-section>"

The use of MAY is sufficiently lax that those machines transferring
n-million articles a day can safely carry on as they are, whilst those
of us trying to provide maximum functionality can 'hide' behind the MAY
instead of getting in to endless "you messed with my IHAVE'd spam.article"
"no we didn't, we just made sure we can trace it" wars..

-aDe

-- 
Ade Lovett, Demon Internet Ltd.