ietf-nntp BCP for RFC977 server/RFC1036 interaction

Ade Lovett ade at demon.net
Mon Apr 7 17:30:34 PDT 1997


USENET news manager writes:
>
>Given that creating the NNTP-Posting-User header may involve inserting
>information from an external and potentially malicious source (I'm thinking
>of the problems with sendmail due to malicious ident responses containing 
>newlines and fake headers, ...), should there be either a recommendation that
>"dubious" characters (which? clearly including newline...) be filtered out,
>or alternatively that they must be encoded in some fashion (e.g. %xx to
>represent the hex code as in URLs, with the knock-on effect in that case
>that % itself must always be encoded...)? 

Perhaps this kind of malicious header use is best addressed on a more
generic level..  after all, what is to stop me adding:

	X-This-Will-Trash-Your-Win97-System: <gunk-here>

Server-generated headers, such as NNTP-Posting-{User,Host} should also
be subject to encoding of potentially 'bad' values into a suitable (us-ascii?)
range, but imho, the problem of malicious headers ranges further than
server-generated versions.

A good first topic for the newly created rfc1036-update mailing list?
Should character and encoding sets for the header part of a Usenet
article be defined in a watertight manner, such that servers MUST
rewrite any 'bad' characters, with a SHOULD option to send such
bad articles into the bit-bucket?

-aDe

-- 
Ade Lovett, Demon Internet Ltd.



More information about the ietf-nntp mailing list