From: Tom von Alten (tom_vonalten@boi.hp.com)
Date: Thu May 13 1999 - 18:40:34 CDT
Greetings:
I'm testing v2a20 (unpatched, downloaded 7 May) on my hp-ux 10.20 system.
I have an email alias set to pipe into hypermail via stdin, with all but
the
-i option set in a -c option file.
I'm seeing three problems:
1. hm_showhtml produces an unreadably misformatted message
2. date/thread indexes are not properly ordered. Messages arriving
close together with hypermail in single message update mode result in
misordering which sometimes gets fixed by new messages coming in, and
sometimes gets worse with new messages coming in.
3. I'd prefer a consistent, local format for the date string in the
index pages. Parseing the date out of messages coming from multiple
locations and multiple MUAs creates a confusing mess.
More detail on each of these follows.
1. The [hm_showhtml = 0] setting, with at least one email header being
printed (To: in my case, but I don't suppose it matters), is NOT wrapping
<pre> around the body: the header has it, but then it's turned off, and the
body is turned into one big <P>. Not a pretty sight!
On line 451 of print.c, we've reached the end of the headers we're going to
show, and the following code seems to get executed:
if(pre /*set_showhtml && set_showheaders && pre*/) {
fprintf(fp, "</PRE>\n");
pre=FALSE;
}
fprintf(fp, "<P>\n");
It appears that the test should be
if(set_showhtml && pre) {
rather than just (pre). Or maybe just (set_showhtml).
I tried it out with just (set_showhtml) and the message looks right, but it
ends up with a <P> in the <pre> block that doesn't belong there:
<!-- body="start" -->
<PRE>
To: <A HREF="mailto:(stuff)">arctest@xyz.hp.com</A>
<P>
This message has three paragraphs.
This is the second ppg.
This is the third.
</PRE>
<P><!-- body="end" -->
I'm guessing someone more familiar with the current print.c can find that
and fix it more quickly than I.
2. The date and thread indexes seem to be prone to disturbance by having
multiple messages arrive in close proximity. I'm sending several messages
from another system, using mailx commands on a command line, like
echo "body"|mailx -s "#1" addr; echo "body"|mailx -s "#2" addr
In one test with six such messages, the most recent one was sent to the
wrong end of the list:
18:18:29 Msg #5
18:18:28 Msg #4
18:18:27 Msg #3
18:18:25 Msg #2
18:18:24 Msg #1
18:18:30 Msg #6
I sent a new message, and the order righted itself! Msg 7,6,...1.
Two more messages made the order go to 8,7,9,6..1
And another made it 9,8,7,10,6..1
So 7-9 have been straightened out, but 10 is out of order.
Another message, and the order is 9,8,7,10,11,6..1
Very strange, and a hard to explain pattern from my end.
3. The date that shows in the indexes is what's parsed out of the sender's
email. Perhaps this got debated and settled earlier? While it's nice to
see the order things were sent in, having timezones from around the world
showing up can make it pretty confusing (especially with the unreliability
described in item 2).
I think it makes more sense to use the archiving system's date, formatted
in as terse a format as possible; for example, date -u +"%e %b %Y %H:%M:%S"
This allows easy comparison, should be reliably parseable out of the
message header, and minimizes the index page space required because TZ
and/or GMT offsets are not needed.
The "show_header" option including "Date" should provide the means to
preserve the sender's "Date:" field, if that's specifically desired. But
not in the index, where it can do more harm than good!
Cheers,
_____________ Hewlett-Packard Computer Peripherals Bristol
Tom von Alten mailto:Tom_vonAlten@boi.hp.com
This posting is for informational purposes only.
It is not a statement of the Hewlett-Packard Co.