.H0 "Introduction
.P
This chapter describes the background of the topics in this thesis.
General knowledge of electronic mail is assumed.
It explains the situation at the start of the project.
It tries to describe from what state the project lifted of and where
it headed to. This shall give an overview.


.H1 "What is MH?
.P
MH is an electronic mail system, originating in the RAND Corporation.
Historically, it had been a all-in-one mail system, with Mail Transfer
Agent (MTA) and Mail User Agent (MUA).
Later, when electronic mail systems changed, Mail Submission Agent (MSA)
and Mail Retrieval Agent (MRA) facilities were added.
The MTA became less important, whereas the MUA became even more the
central part.
.P
First of all, MH is a style of a mail handling system.
It had started as a design proposal, not as an implementation, and 
had in spirit remained so. This is similar to Unix, which much less
is a specific software product, as it is a style of system design.

.U2 "History
.P
MH is an electronic mail system, originating in the RAND Corporation.
In 1977, Norman Shapiro and Stockton Gaines had proposed the design
of a new mail handling system, called ``Mail Handler'' (MH) for RAND,
to superseed their ``Mail System'' (MS).
Two years later, in 1979, XXX took the proposal and implemented a
prototype of MH. It proved successful and replaced MS thereafter.
.P
A decade later, the University of California had started to use MH.
They also took over its development and pushed MH forward.
This had been the time when the Internet appeared, Berkeley implemented
the TCP stack, and Sendmail was born. MH had often contained the first
implementation of new RFCs.
.P
In the nineties, MH had been moved into the public domain, making it
attractive to Free Software developers. The Internet had started to become
mainstream and in 1997, Richard Coleman initiated the ``New Mail Handler''
(nmh), a fork of MH. He intended to modernize MH, improve its MIME
capabilities, and this should be done openly within the Internet
community. Today, nmh almost completely replaced the original MH.
.P
Three versions of MH are available:
.BU
.B "Old MH" .
In most cases it has been replaced by nmh, but some systems still
provide old MH. As nmh is old MH-compatible, there exist few reasons
not to upgrade to new.
The development of old MH stopped almost completely.
.BU
.B Nmh .
The most widespread version of MH. Backward-compatible to old MH.
Provides new featues, which need to be activated explicitely.
Its development went slowly in the previous years, but had revived
in Fall 2011.
.BU
.B Mmh
A descendent of nmh. Had started as a non-compatible experimental
version, but became de facto a fork. Tries to expand the same
principle concepts in a more modern way. This version of MH is the
subject of this thesis.

.U2 "Concepts
.P
MH is a toolchest, modelled after the Unix toolchest. It consists of a
bunch of tools, each covering one task of email handling. These programs
operate on a common mail storage. The specific format of the mail storage
also defines MH, like the file system structure defines Unix. It
consists of directories (mail folders) and files (mail messages).
Each file contains exactly one message in the format it had been
received (i.e. transfer format). MH tools carry a state (context),
consisting of current mail folder and current message. Messages can
have symbolic names, like the next or last message or for some
arbitrary group of messages. These names are called sequences.
.P
New MH tools can be build out of existing ones easily. Default values to
commands are stored on a command name-basis, making it trivial to have
different versions of the same command with different defaults. Most
of the configuration is stored in the user's profile. Form templates,
e.g. for new messages or replies, are exchangeable and output is generally
adjustable with format files.
.P
MH allows the user to automate almost everything and to modify amost
any behavior. The system is scriptable and extendable.


.H1 "Understanding of the Code and Community
.P
In order to understand the state, goals and dynamics of a project,
one needs to know its history. MH comes from a time before the
Internet, a time before networking became universal, a time when
emailing was small, short and simple. Then it grew, spread and
adopted to the changes. The core-concepts, however, remained the
same. During the XXX a small group of students at the University of
California, actively worked on MH. They added features and optimized,
like it is common for scientific work. This is still in pre-ANSI C
times. The source code contains many ancient parts. Code constructs
specific to BSD or hardware of that time are usual.
.P
Nmh started eight years after the ANSI C standard had been
established. A more modern coding style entered the code base. Still
a part of the developers come from ``the old days''. The developer
base became more diverse and thus the code. Programming practices
from different decades merged into the project. Different coding
styles came together. It appears as if multiple peers added code
parts, resulting in a conclomeration rather than an homogenic
of-one-cast mail system. Still, the basic concepts hold it together.
They were mostly untouched throughout the years.
.P
Although, at the surface, nmh is a toolchest, meaning a collection
of completely modularized small programs, on the source code level,
it is much more interweaved. Parts of the basic functions are
collected in a MH standard library, which is good, but often
separate functions are compiled into programs, for effiency reasons.
This lead to intricate innards.
The advent of MIME rose the complexity of email by a magnitude. This
is visible in nmh. The MIME-related parts are the most complex ones.
It's also visible that MIME support had been added on top of the
original MH later. The MH style made this easily possible, but it
also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
and had not been thoroughly included into the concepts (e.g. the
user-visible access to whole messages and MIME parts are inherently
different).
.P
For compatibility's sake, it is a common understanding to have the
default settings to be compatible, requiring any new feature to be
explicitely enabled. This puts a burden on new users, because nmh
out-of-the-box keeps staying in the same ancient style, where users
usually want to have it practical for modern emailing.
But of course, this depends on if nmh is seen to be a front-end or a
back-end.


.H1 "My Vision
.P
The general goals of the mmh project are the following:
.BU
I believe that mmh should be perfectly suited for modern emailing,
out-of-the-box.
.BU
I care less about compatibility and more about conceptionally elegant
approaches.
.BU
I care for general, clear, and simple concepts.
.BU
I like to create an of-one-style email system. It should feel like
cast as one.
.BU
I plan to remove any optimizations that rises obscurity, unless it
appears to be neccessary to make mmh usable at all.
.P
.B "The target user in mind
likes Unix and its philosophy.
He likes to use programs that are conceptionally appealing.
He's familiar with the command line and enjoys its power.
He is at least capable of shell scripting and wants to improve his
productivity by scripting the mail system.
His computer and operating system are from post-ANSI C times.
He likes to attach files, exchanges text containing non-ASCII
characters, signs or encrypts his messages.
He does not use bulletin boards anymore, nor non-mbox style mail
drops, nor does he rely on compatibility to nmh.
He already has and MTA/MSA and MRA running or is able to set them
up.
He does not want to have to read a book in order to make his MUA
usable.


.H1 "Things to do
.BU
Remove any MTA and MRA facilities. Mmh shall concentrate on the MUA
task. Mail shall enter mmh's mail storage via the system mail drop
and it shall leave mmh via the local \fLsendmail\fP command.
.BU
Remove any further functions that are not related to mmh's main task.
Bulletin board support is on example. Also remove support for ancient 
technologies, like hardcopy terminals.
.BU
Refactor the source code to meet modern style criteria. Use
standardized library functions when possible.
.BU
Replace performance optimizations by clear and readable code.
.BU
Reduce the feature set to the commonly used one, removing
corner-cases. Set sane default values.
.BU
Add better attachment support. Add support for digital signatures and
encryption.
.BU
Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
Integrate MIME support deeper and more natural into MH.
.BU
Provide a ready-to-use setup out-of-the-box.