There are many possible projects that could be focused around mailing list capability for Whistle-Ware that might fit within the time and staff limitations proposed for our mini-projects. Before choosing one, let's consider some of the possibilities.

• We could enable outside mailing lists as an eyeball attracting tool for Whistle-Ware user sites.

• We could work at better reconciling the inevitable conflict between keeping the UI as simple as possible, for the sake of marketing and the users, so we can market software that sells and is easy to use, and keeping the UI as complex as necessary, for the sake of engineering and the users, so we can build software that works and is fruitful to use.

  • We could analyze more carefully what administrative user interface exposure is needed to assure that mailing list administrators can tailor Whistle-Ware sufficiently to assure inter-operability with other Internet mail and mailing list software, at all.

  • We could analyze more carefully just what constitute "chunks" of mailing list tailoring capabilities that the user interface must expose or not expose as a set to allow the mailing list administrator to make compatible sets of changes to support mail and mailing lists that inter-operate with the net.

  • Where there are order dependencies on the exposure of sets, we could analyze and identify those order dependencies.

• We could preen the existing bestserv software for obvious, but so far unnoticed problems, such as

  • its definition of what a correct email address is, that allows multiple "at" signs in a domain email address,

  • its failure to support old style "bang format" email addresses at all,

  and so forth.

• We could move mailing list support at Whistle up the SRI Software Development Maturity Model ladder, by implementing bidirectional traceability between mailing list requirements and their implementations.

  Here are at least some of the needed steps.

  • Identify all the [RFC] standards and parts of more general RFCs that govern mailing list software as a subset of email software.

  • Identify all the Whistle-Ware software that implements those standards.

  • Trace the mailing list software implementation back to the existing standards, chapter and verse, by annotating the software with pointers to the place in the standards that the code implements.

  • Trace the standards requirements forward to the software that implements those requirements by annotating copies of the standards with pointers to the mailing list code that supports each feature.

  • Cross check that nothing is missing or added without appropriate written supporting justification, and that those additions or omissions do not damage interoperability with standard Net software.

• We could work on mailing list internationalization issues. In particular, one of the big wins Whistle-Ware can only grab if grabbed early, is entry into markets (China, for example) where there is essentially no entrenched competition to the Whistle-Ware product, building product strength and profitability, and establishing a defensible foothold for further IBM/GSB offerings in those markets before trying to take on our entrenched competition where they are stronger. This is leveraging off of one of the recognized IBM strengths, worldwide presence and reputation.

• RFC 1859 Support

  Standard messages passed between mail agents running in different human langauges show up at the originator's machine in the human language of the machine reporting the problem, which may leave the problem report unreadable at the problem origination point. The information encoded in the problem reports is also encoded in machine readable RFC 1859 format in the returned email. A localization interpreter of the machine readable form back to human form would give the originator a better understanding of the problem the mail experienced, and thus a less frustrating email experience.

• Whistle-Ware currently rewrites email headers when processing mailing lists. This will be forbidden in an upcoming RFC standard. The need to rewrite headers in the present implementation can be removed by adding a "-T" command line flag to sendmail that tells sendmail to ignore addresses in the "To:" and "Cc:" address fields, and only process addresses in the "Bcc:" field; and then by running "sendmail -T" on the mailing lists queues.

• Whistle-Ware currently uses the email alias list capability to implement parts of the mailing list capabilities (like assignment of the mailing list administrator). This has had the unfortunate effect of breaking parts of normal use of the alias capability. These two functionalities should be untangled.

• Whistle-Ware doesn't separately expose the email aliases capability at the administrative interface. This removes significant functionality from administrative control. This is part of the frequently requested "advanced options" interface for the InterJet admin. This set of capabilities could (and arguably should, to reduce risk) be implemented and tested in advance of a UI change to expose them.

• Mail processing currently has some problems with algorithmic complexity that make processing time grow, in the worst case, with the cube of the number of mailing list entries. Sorting the mailing list entries when they are inserted would allow these other processes to be rewritten to run in linear time complexity, improving the scalability of Whistle-Ware.

• The mailing list administrative UI saves data into the mailing list database (for icon display purposes) that "denormalizes" the mailing list database. Either a way to renormalize the database should be developed, or a separate storage for this information should be developed.

• Separate the user list from the metadata stored mixed in with it, to simplify maintenance of both.

• The current, freeware, gdbm database used in Whistle-Ware email support is not SQL compliant, and lacks features needed to improve Whistle-Ware performance and maintainability. This database could be replaced with another to be found, and its ussage in Whistle-Ware fixed, to overcome these problems.

• We could work on some of the missing infrastructure that is preventing progress on these other issues, and causing or contributing to existing defects, in particular full blown MIME support.

  • From Terry Lambert:

    Encapsulate the response message, not as quoted text, but as a proper MIME attachment. To achieve this, the main message itself will have to be a "multipart/mixed" Content-Type, per RFC 2046, Section 5.1, and the message being returned will have to be of type "message/rfc822" or of type "message/partial", per RFC 2045, sections 2.3 and 4.

    Note: This is the canonically correct way to deal with quoting messages back to the sender in order to achieve maximum interoperability.

    There is currently no RFC2046 handling code in the mailing list software. Adding such code will require a separate reorganization of the mailing list software, in order to teach it about "parts" of MIME messages, and to have it use them to encapsulate both its response, and the original sender information.

  • MIME support is needed for identifying languages and language code pages in internationalization efforts.

  • MIME support is needed for decorations to mailing list documents not in the same language as the document main body text.

  • MIME support is needed for intelligently providing mailing lists that work in all their parts across international and language boundaries, the usual example being "us_panasonic_users@panasonic.com.jp" for a mailing list running in a Japanese language environment to support English-only participants.

  • Several existing mailing list software defects relate to missing or defective MIME support in the mailing list software: dropped characters in Japanese text, quoted-printable support for forwarded headers in forwarded documents, inability to provide "unsubscribe directions" footers in Japanese Whistle-Ware use, probably many more.

  • Support for external mailing lists is MIME dependent.

  • Many of the user interface exposure issues, and the interlocked issues of interoperability with Net mail software, are intimately involved with full support of MIME.

  • Many of the existing unnoticed/unreported defects in bestserv are probably related to MIME support or its lack, so that there would be fewer things to find (and more found anyway along the way) if the MIME implementation failures were fixed first.

Obviously, from the effort put into making it seem to subsume or block doing many of the other possibilities, it is this latter, MIME support item, that I think will have the most near term results, the most long term benefits, and is most right sized for a mini-project. Most of the other items, except bi-directional traceability, have this one as a prerequisite, and even traceability would merely point out how crucial MIME support is to meeting the inter-operability requirements the standards, and more importantly the Net sites almost universally using those standards, impose upon Whistle-Ware from outside.

Additional familiarity with the code is needed to provide estimates of the resources needed for this mini-project.