inn-2.2 / storageapi + wireformat == corruption

greg andruk meowing at banet.net
Mon Sep 27 02:14:19 UTC 1999


In nnmh:inn-workers, Russ Allbery <rra at stanford.edu> wrote:

> I see what you're saying, and I don't disagree, but if the article is
> stored in wire format then \n isn't a line ending.  If bare \n should
> *become* a line ending, then whatever is accepting the data originally
> should be converting \n to \r\n as appropriate.

Those bare linefeeds are real line endings, with the most notorious
offender being some versions of Gnus that got it right in most cases
but mess up in places like the blank between header and body.

Late model servers that don't correct for this by virtue of the
traditional storage conversion are now propagating b0rkenness that was
once silently corrected.

And then there's the remarQ CR breakage which is/isn't there depending
on where it gets passed through.  Yuck.

>>  4.4.  Characters and Character Sets
>>     Transmission paths for news articles MUST treat news articles as
>>     uninterpreted sequences of octets, excluding the values 0 (ASCII
>>     NUL) and 13 and 10 (ASCII CR and LF, which MUST only appear in the
>>     combination CRLF which denotes a line separator).

> What this basically seems to translate as to me is that articles
> containing bare newlines are invalid articles.  So we're probably entirely
> within our rights to simply reject them, the same as we do with articles
> with embedded nuls at present.  If we accept them, though, I think we
> should pass them along completely unmodified.

Remember that IHAVE implicitly passes to rnews, POST to inews->rnews.
We no longer have the external program calls but NNTP is still
dependent on their behavior, which treat all line terminators as
equal.  That stuff is supposed to get cleaned up when it enters a
server.  True, some of the newer servers are ignoring that, but
they're not supposed to.  The article format dictates the outgoing
wire format, even though some recent implementations have been
treating the reverse as true.

This is really just the same massaging SMTP has always had to deal
with.


More information about the inn-workers mailing list