Re: Bug in 2.0b2

From: Craig A Summerhill <>
Date: Thu, 10 Sep 1998 16:13:58 -0400 (EDT)
Message-Id: <>

On Thu, 10 Sep 1998, "Zvi Har'El" <> wrote:
> On Fri, 7 Aug 1998, Craig A. Summerhill <> wrote:
> >
> > I found a bug on the 2.0b2 code. While scanning a mailbox, the program
> > is failing to pick up the beginning of a new message unless the sendmail
> > parsing line is preceeded by a null line. In other words, your new
> > version of Hypermail is checking for the string:
> >
> > <any text>end-of-line
> > end-of-line
> > From_
> >
> > to signal a new message is beginning in the mailbox.
> I am sorry Daniel, but you failed to see the point: The null line is not
> necessary! The thing to check is as yoiu said, and not "\n\nFrom" !!! (I
> would express it sa a regexp check for "^From ", but anyway you allow
> now "\n" at all for the first message. As Craig explain, both Pine and
> Elm can handle mailboxes without a null line seperating messgaes. This
> is why every decent mailer replaces a "From " at the beeggining of the
> line by a ">From" !!! I would like to stress the fact that listproc 6.1
> (The free listproc) doesn't put this null line when archiving messages;

To which, Daniel Stenberg <> replied:
> There is no check for "\n\nFrom" today. The check is for "\nFrom ".

I am kinda glad Zvi Har'El brought this issue up again.

I was a little disappointed with Daniel's earlier answer to my posting, and have discovered the beta 3 code does not include a fix for this. But I haven't really had time to write about it again.

Some clarification regarding ListProcessor is probably in order here...

ListProcessor 7.x and 8.x (current version is 8.2) does not insert this null line into the message either. I've been an active member of the ListProcessor development community since version 5.12 or some such version, and the operating principle has always been that writing of mail into unix mbox files was a function of sendmail (or another MTA) not a function of the ListProcessor. For this reason, although there is some minor header re-writing is done for outgoing mail, ListProcessor essentially stores messages in its list archives with the same header and delimiting data incoming messages arrive with at the time the MTA writes it to disk.

On the system I'm now running ListProcessor on, we do not have a new version 8.x sendmail. I suppose it is possible that sendmail version 8.x fixes this problem by putting a null line at the end of every preceeding message or at the beginning of every new message when it writes into an mbox file, but I highly doubt it. I've installed ListProcessor on a dozen or more systems, some of which have sendmail version 8.x (including Linux, Solaris, and BSDI) and can see no real difference in performance in terms of what is written to disk.

CREN, which supports and manages the ListProcessor product, has already made a strategic decisions to roll out their supported Web interface with MonArch. There are several things I don't like about MonArch, and was interested in seeing Hypermail developed as an alternative HTML markup tool for sites interested in using it. To that end, I have been working with the beta code, as time allows, to wrap it into the CREN web interface. Then I have a better chance of convincing CREN to support it.

Hypermail is definately broken as far as I am concerned in regard to its parsing of unix mbox files. In fact, this is broken enough that I have pretty much decided not to use the software unless this code gets cleaned up... I don't have the time to modify C source code everytime a new release comes out -- much less debug additional problems which may arise.

Daniel Stenberg <> wrote:
> You could also just send us the patch that corrects hypermail. Hypermail
> is an open source project you know.

Well, not everybody is a programmer...

As I stated at the outset of this list (and re-birth of hypermail) I'm not much of a C programmer. It has been fifteen or more years since I have done any programming, and I have never programmed in C. Most likely, you wouldn't want to use my code, for efficiency sake, even if I had the time to spend and write it (which I don't).

Having said that, it is entirely up to you, Daniel, and Kent, and the other people participating in this project to decide whether you want to spend the time to code for bugs that other people point out. It is entirely within your discretion to decide not to spend your time to do so if somebody such as myself doesn't submit code. Just as it is entirely within my discretion to decide not to use hypermail if I feel it is an inferior product.

I will say this, however. People don't have to be programmers to contribute significantly to the enhancement of a product. In fact, I've been involved in systems development long enough to know that some of the most useful contributions for product enhancement don't come from programmers at all. They come from the people using and delploying the product.

Enough said...


   Craig A. Summerhill, Systems Coordinator and Program Officer
   Coalition for Networked Information
   21 Dupont Circle, N.W., Washington, D.C.   20036
   Internet:   AT&Tnet (202) 296-5098
Received on Thu 10 Sep 1998 10:21:06 PM GMT

This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT