[that, in the case under discussion...]
Well, in the case that was being discussed, it /was/ doing so.
However, I should have cited RFC2047, which replaces 1521-2. Sorry.
But to get back to your point...
I understand what you're saying.
message id < XXXX@XXXXX.COM > , to be
exact. Inzwischen gelesen.
(I think you're referring to section 6.1. Section 2 (in rfc1522 as in
2047) is setting requirements on the sender. What a mail client
should do if it receives defective formats is actually codified in
Is there any difference between mail and news in this regard? Usenet
usage differs in a number of respects, and has never really been
formally codified since MIME formats were introduced. They've been
sort-of adopted into news from mail, but there are still
long-established differences of custom. PINE sometimes sits a bit
awkwardly across this divide...
However, if the current USEFOR draft ever makes it into an RFC, then
this will be clearly prohibited, even in news. Usual caveats apply in
reference to internet drafts, but:
o Compliant software MUST NOT generate (but MAY accept) header
fields of more than 998 octets. This is the only limit on the
length of a header field prescribed by this standard. However,
specific rules to the contrary may apply in particular cases (for
example, according to [RFC2047] lines of a header field containing
encoded-words are limited to 76 octets).
But yes, I guess you're right - in this situation, PINE is being
tolerant, in a way that it wasn't in the other situation.