"Charles Lindsey" <chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> writes:
I think, as Russ has explained, that just about every existing Netnews
relaying agent would not be able to do that.
Imagine a news server that is offered 100,000 articles a day, and that
keeps a History file of two million or so articles that it knows about,
and it has to discover, for each of those 100,000 articles, whether its
<msg-id> is already recorded in its History file.
No implementor can afford to examine each incoming <msg-id> for special
cases such as quoted-pairs that in practice are virtually never seen. The
most he can afford to do is to read the incoming stream until he finds a
'>', and that is then the msg-id he is going to use.
Well, it's not quite as impossible as that. It's conceivable that one
could write a normalizer for message IDs and use it on all incoming
message IDs before hashing and before doing the uniqueness check. But
that's what it would take: a normalizer, not just a parser, and the
additional overhead and (more to the point) code complexity on the
handling path of every incoming article offer.
I'm fairly certain no netnews implementor has ever bothered, given that
the only failure case is that two message IDs using syntactical elements
rarely seen in practice will appear to be different if they use those
elements differently.
Yes, the USEFOR WG discussed these cases (but not extensively, since the
bulk of its members had a good understanding of how Netnews worked and
were well aware of what would not work). So the necessity for that SP
was reaffirmed (several times, because newcomers regularly raised it).
Yes, I guarantee that substantial amounts of netnews software will fail
completely to parse headers that do not have a SP after the colon. I
can't speak to e-mail software.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>