Xref: utzoo comp.protocols.tcp-ip:5884 news.misc:2517
Path: utzoo!attcan!uunet!husc6!rutgers!njin!princeton!phoenix!pucc!IRWIN
From: IRWIN@pucc.Princeton.EDU (Irwin Tillman)
Newsgroups: comp.protocols.tcp-ip,news.misc
Subject: Re: VERY strange behavior at USENET/BITNET gateway
Message-ID: <6818@pucc.Princeton.EDU>
Date: 7 Jan 89 22:21:03 GMT
References: <17978@glacier.STANFORD.EDU> <10836@s.ms.uky.edu>
Reply-To: IRWIN@pucc.Princeton.EDU
Organization: Princeton University, NJ
Lines: 26
Disclaimer: Author bears full responsibility for contents of this article

In article <10836@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes:

>I've seen things like this happen if the blank line(s) between the
>header and the body weren't truly blank but had spaces in it.
>
>Something which happens (at least with UREP) is that files coming
>in from BITNET-land have lines which are supposed to be truly
>empty instead contain some number of blanks.  You would think this
>would be non-destructive, but the header parser in the news software
>gets confused and thinks that the first part of the body is actually
>part of the header.

Yup.  I've found that the following situation will exhibit the
problem.  (I've tried it with inews, version B 2.11, patchlevel 14.)

Feed inews an article in which the separator line contains whitespace
AND make sure that the body of the article begins with a line containing
only whitespace.  You'll find that the second line of the body will be
concatenated with the last header.

There are several ways that sites moving news from VM to UNIX can deal
with the problem.  I'm using a news batcher on the VM side written by
Thomas Habernoll;  it does the EBCDIC->ASCII conversion, and produces
truly blank lines.  Then I send the batch as a binary file.  Another way
is to change the whitespace lines to truly blank lines once they arrive
on the UNIX side.