Re: Ideas

From: Craig A Summerhill <>
Date: Thu, 23 Apr 1998 01:46:19 -0400 (EDT)
Message-Id: <>

Kent Landfield <> 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...


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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

      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:(  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:   AT&Tnet (202) 296-5098
Received on Thu 23 Apr 1998 07:49:03 AM GMT

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