Vernon Schryver <vjs@calcite.rhyolite.com>:
<snip>
> text line
> The maximum total length of a text line including the
> <CRLF> is 1000 characters (but not counting the leading
> dot duplicated for transparency).
</snip>

(As a side-note: Doesn't this mean, then, that I should in fact make my
buffer 1001 bytes in size?)

<snip>
> - I would not drop drop NNTP or SMTP lines that are too long, but
> pretend they end correctly, such as by inserting a NUL that would
> be removed when I passed the message along. If I couldn't do that,
> I'd reject the whole message, because it is Wrong, Evil, Nasty,
> and Wrong for a transport system to modify passing messages.
> If I couldn't reject the message (in some protocol other than NNTP
> or SMTP), I'd insert <CR><LF> as the smallest damage to the message.
> If that were impossible, I'd give up, because dropping a 1000
> character line would be over the top.
</snip>

But what if the server, perhaps as a result of a bug, sends an indefinitely
long line? The processing must stop somewhere, surely. (Or maybe I've
misunderstood you. I'm not 100% certain.)

And couldn't arbitrarily pretending that a CRLF was present potentially
cause problems? For example, how about adding a CRLF between an existing
CRLF (after the CR and before the LF)?

<snip>
> - "Warning the user" can make sense for an NNTP or other netnews
> server checking a submission, but is dangerously wrong when applied
> to incoming, flooded messages. It is impossible to reach "the
> user" who wrote a non-conforming flooded message. Trying is
> likely to get your blacklisted or worse. A server can at most
> reject or discard incoming, non-conforming articles.
</snip>

What I meant by "warning the user" was "warning the user of my news client
(perhaps in an error log) that some of the communication with the NNTP
server was problematic".

Sorry for any confusion. I should have been more specific initially by
pointing out that I'm implementing a *newsreader*.