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