Subject: Two bugs in inews (1.5.1)
To: [email-masked]

Date sent:        Sun, 11 Jan 1998 14:11:34 -0800
From:             "Ronald F. Guilmette" <[email-masked]>

I've found what I consider to be two bugs in the 1.5.1 version of inews.
I don't know if these are also present in later versions, but I suspect
that they are.

Bug #1 is just the fact that inews will only accept for posting articles
which contain no more than some maximum number of header lines.  This
built-in limit seems nor only artificial and pointless but worse, IT IS
NOT DOCUMENTED ON THE INEWS MANPAGE.  That is the real bug.  If this
limit were documented, that would be one thing, but I haven't seen any
mention of it in the manpage.

Bug #2 relates to the same issue.  Internally within inews, the computation
of the number of header lines that have been seen so far is buggy.  If you
try to post a news article with, say 80 header lines (using inews), inews
will refuse to post the article _and_ it will give you an error message
saying that you have tried to post something which has more than 101
header lines!  Hummm...  That ain't right.

The relevant source code lines in inews.c are as follows:

        /* Too many headers? */
        if (++i > 5 * HEADER_DELTA) {
            (void)fprintf(stderr, "More than %d lines of header.\n", i);
            QuitServer(1);      

(Note that both the multiplier, 5, and the prior definition of the constant
`HEADER_DELTA', i.e. 20, seem to have been pulled at random out of a hat.
Who decided that these numbers were appropriate??)

Anyway, the bug here is that each time you pass this hunk of code, the count
of header seen so far, as maintained in the variable `i', gets incremented
by one.  But note that this code sits inside a big for loop, and for every
iteration of _that_, the variable `i' is _also_ being incremented again as
a result of reaching the bottom of the for loop.

In short, it appears that the _actual_ limit on the maximum number of header
lines accepted by inews is 50, due to the double-counting of each header.

Personally, I don't know why inn should be imposing _any_ limit, let alone
this undocumented one.

-- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc.
-- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/
-- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/