Kent Landfield <kent_at_landfield.com> wrote:
>
> Kevin sent a list of items that have been requested most often. Some of
> this we have a start on, much we do not...
Kent,
I just glanced across this message very quickly. About a year or fifteen
months ago, I sent Kevin two or three fairly long messages outlining some
enhancements I would like to see to Hypermail. I can't find copies of
the messages just now in my own personal mail knowledgebase, but I'm sure
they are here somewhere. (Worst case scenario, I have to search for them
on tape.) When I find them, I will review your list to see what is
present and what is missing.
It occurs to me that one of the first things you need to do is to get
some sense of prioritization on that list of proposed enhancements.
In that manner, you can perhaps break it into manageable chunks.
Off the top of my head, I will offer my top priorities for Hypermail:
- Full MIME compliance -- a year ago, this was way down on my
list. But today, with the explosion of Microsloth mail systems
like Upchuck Distress, this is becoming a major problem for me.
(Microsoft seems to have made a decision to encode *everything* as
MIME by default -- even if it is simply ASCII text with multipart
MIME boundaries.) Our mailing list agent can handle MIME
messages fine, but it sucks when people can't render the MIME in
the archives. Increasingly, I am finding people are opting to
use the Web archives in order to *read* large mailing lists in
lieu of subscribing to the list. This way, they don't have to
manage a mailing list subscription and they don't have to worry
about transient mail errors, disk quotas, or SPAM. But until
there is MIME compatibility in the HTML markup, these people
are at a disadvantage.
- Correct RFC821/822 Header Parsing -- this is the single biggest
reason that Hypermail dumps core on me. I have compensated for
the most offending instances of this by using Perl and shell
pre-processing to "re-write" headers before they are handed
off Hypermail. But this is really inefficient, and I keep finding
new instances of such problems cropping up all the time.
- Configurable Setting (.hmrc file) to a Pointer/URL for Custom
Header and Footer Files -- currently, Hypermail does not include
anything except the HTML message body (payload, I guess) when
it does it's output. Again, I have written Perl and shell
scripts to concatenate custom headers and footer together with
the output from Hypermail. The problem is that on very large
lists this can result in a fairly significant overhead. If this
process could be done within the Hypermail binary it would be
much less demanding on the machine in terms of process ids and
memory usage. Since you really have to have an <HTML>, <HEAD>,
and <BODY> wrapper to get legit HTML output, I figure everybody
needs this.
- Configurable Setting (.hmrc file) or Compile Time Variable to
Domain-ize Addresses -- addresses appearing in the RFC822 field
which lack hostname can't be made into proper HREFs when Hypermail
does it's thing. For a good example of the problem I am talking
about, look at message numbers 0001.html and 0002.html on
ftp://ftp.landfield.com/hypermail/mail-archive/1998/.
They are coded with: mailto:(no%20email)
Because the MTA resides on the same host as the list, it is
often not require to domain-ize these addresses for delivery.
In such cases, I think it would nice if Hypermail could be
programmed to output: mailto:(kent_at_landfield.com) instead.
This would probably work well as a *required* definition
during compilation; however, it should not simply rely on
the output from `hostname` in case you want to override with
an MX entry or alternate domain (if you run virtual domains).
--
Craig A. Summerhill, Systems Coordinator and Program Officer
Coalition for Networked Information
21 Dupont Circle, N.W., Washington, D.C. 20036
Internet: craig_at_cni.org AT&Tnet (202) 296-5098
Received on Thu 23 Apr 1998 07:49:03 AM GMT