.RN 1

.H0 "Introduction
.P
This chapter introduces MH, its history, concepts and how it is used.
Then, it describes nmh's code base and community to give the reader
a better understanding of the state from which mmh started off.
Further more, this chapter lists the motivation and goals of the mmh project.
This chapter introduces MH, nmh and mmh to the reader and outlines
the mmh project itself.


.H1 "MH \(en the Mail Handler
.P
MH is an electronic mail system, originating in the RAND Corporation.
Most important for this thesis is that MH defines a mail handling concept.
In fact, MH had started as a design proposal, not as an implementation,
and in spirit it had remained this way. This is similar to Unix, which
influenced the world more in being a set of system design concepts
than in being a specific software product.
These ideas behind Unix are summarized in the \fIUnix philosophy\fP.
MH follows this philosophy.

.U2 "History
.P
MH is an electronic mail system, originating in the RAND Corporation.
In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
had proposed the design
of a new mail handling system, called ``Mail Handler'' (MH),
to superseed RAND's old monolithic ``Mail System'' (MS).
Two years later, in 1979, Bruce Borden took the proposal and implemented a
prototype of MH.
Before the prototype had been available, the concept was
believed to be practically unusable because of being too slow.
But the prototype proved successful and replaced MS thereafter.
In replacing MS, MH became an all-in-one mail system.
.P
A decade later, the University of California at Irvine had started to use MH.
They also took over its development and pushed MH forward.
This was the time when the Internet appeared, UCB implemented
the TCP/IP stack, and Allman wrote Sendmail.
MH was extended as emailing got more features.
The development of MH was closely related to the development of email
RFCs. In the advent of MIME, MH was the first implementation of this new
email standard.
.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 popular and in 1997,
Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
and Craig Leres.
Colman intended to modernize MH and improve its portability and
MIME handling capabilities.
This should be done openly within the Internet community.
The development of MH stopped soon after the development of nmh had started.
Today, nmh almost completely replaced the original MH.

.U2 "Concepts
.P
MH is a toolchest, modelled after the Unix toolchest. It consists of a
set of tools, each covering a specific task of email handling.
The programs
operate on a common mail storage. The specific format of the mail storage
characterizes MH in the same way like the format of the file system
characterizes Unix.
.P
The mail storage consists of \fImail folders\fP (directories) and
\fPmessages\fP (regular files).
Each message is stored in a separate file in the format it had been
received (i.e. transfer format). The files are named with ascending numbers
in each folder.
.P
MH tools maintain a \fIcontext\fP, which includes
the current mail folder and current message.
Processes in Unix have a similar context, containing the current working
directory, for instance. In contrast, the process context is maintained
by the Unix kernel automatically, whereas MH tools need to maintain the MH
context themselves.
The user can have one MH context or multiple ones, he can even share it
with other users.
.P
Messages can have symbolic names. These can be automatically updated
position names like being the next or the last message,
or user-settable group names for arbitrary sets of messages.
These names are called sequences.
Sequences can be bound to the folder or to the context.
.P
New MH tools are built out of or on top of existing ones easily \(en
a property common to toolchests.
Multiple versions of the same command with different default values
are created very easily. This provides shortcuts and tayloring.
Form templates for new messages or for replies are easily exchangable.
Generally, output is adjustable with format files.
.P
The configuration is stored in a file that is called the user's \fIprofile\fP.
MH encourages the user to taylor and automate the mail handling.
Almost every part of the system can be adjusted to personal preference.
The system is well scriptable and extendable.
As the MH toolchest was modelled after the Unix toolchest, the
properties of the latter apply to the former as well.

.U2 "Versions
.P
Three versions of MH are available today:
.IP "Old MH"
.br
In most cases this version had been replaced by nmh,
but some systems might still provide old MH.
The main reasons to still use old MH are historical reasons.
MH provides hardly any benefits over nmh.
The development of old MH has stopped after the 6.8.4 release in
February 1996.
.IP nmh
.br
The most widespread version of MH was forked off version 6.8.3 in December
1996. It is based on the \fILBL changes\fP.
Backward-compatibility to old MH is provided by having new featues deactivated
by default. In consequence, the user needs to activate them explicitely to
be able to use them.
Throughout the previous years, the work on nmh was mostly maintenance work.
Development revived in December 2011 and stayed busy since then.
.IP mmh
.br
This descendent of nmh is the subject of this thesis.
It had started as an experimental version, but became de facto a fork.

.U2 "Example Session
.P
Following is an example mail handling session with mmh.
It should be mostly compatible with nmh and old MH.
Details might vary but the look'n'feel is the same.
.DS
$ \f(CBinc\fP
Incorporating new mail into inbox...
	
   1+ 2012-05-16 11:16  meillo@dream.home  Hello
   2  2012-05-16 11:17  meillo@dream.home  book
	
$ \f(CBshow\fP
Date:    Wed, 16 May 2012 11:16:00 +0200
To:      meillo
From:    <meillo@dream.home.schnalke.org>
Subject: Hello
	
part       text/plain                  13
mmh is great
	
$ \f(CBnext\fP
Date:    Wed, 16 May 2012 11:17:24 +0200
To:      meillo
From:    <meillo@dream.home.schnalke.org>
Subject: book
	
part       text/plain                  79
Hello meillo,
	
have a look at the ``Daemon book''. You need to read that!
	
foo
	
$ \f(CBrmm 1\fP
	
$ \f(CBscan\fP
   2+ 2012-05-16 11:17  meillo@dream.home  book
	
$
.DE


.H1 "nmh: Code and Community
.P
In order to understand the state, goals and dynamics of a project,
one needs to know its history. MH predates the Internet,
it comes from times before networking was universal,
times when emailing was small, short and simple.
Then it grew, spread and adopted to the changes email went through.
The core-concepts, however, remained the same.
During the 80s 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 had different style.
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 a 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
old 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 "mmh
.P
I started to work on my experimental version in Fall 2011.
In December, when I announced my work on the nmh-workers mailing list,
.[
nmh-workers mmh announce december
.]
the activity in nmh rose heavily.
Suddently the community started to move.
This movement was pushed much by Paul Vixie's ``edginess'' message.
.[
nmh-workers vixie edginess
.]
After long years of much stagnation, nmh became actively developed again.
Hence, while I was working on mmh, the community was working on nmh,
in parallel.

.U2 Naming
.P
The name \fImmh\fP stands for \fImeillo's mail handler\fP,
because mmh is my own version of MH.
(My login name is \fImeillo\fP.)
The project follows my personal considerations and preferences.
By calling it a personal project, I don't need to justify my decisions,
though, still I do.
This enabled me to follow my vision staightly and thus produce
a result of greater pureness.
This project model was inspired by the window manager \fIdwm\fP,
which is Anselm Garbe's personal window manager \(en
targeted to satisfy Garbe's personal needs whenever conflicts appear.
dwm had remained much more focused on its original goals,
whereas its community-driven predecessor \fIwmii\fP had
grown large and lost it's leanness.
This should not happen to mmh.
.P
mmh can also stand for \fImodern mail handler\fP, and this is
the variant chosen as titel for this document. One main focus of the
project was to modernize nmh. Another main goal is resembled in the
name \fIminimized mail handler\fP: Drop any parts that don't add
to the main task of mmh, being a MUA.
.P
It should also be noted that \fLstrcmp("mmh","nmh")<0\fP is true.
Although mmh bases on nmh, it is likely seen as a step backward.
I agree.
However, this step backward actually is a step forward,
although in another direction.

.U2 "Motivation
.P
The mmh project is motivated by deficites of nmh and
my wish for general changes, combined
with the nmh community's reluctancy to change.
.P
nmh hadn't adjusted to modern emailing needs well enough.
The default setup was completely unusable for modern emailing.
Too much setup work was required.
Several modern features were already available but the community
didn't wanted to have them as default.
.P
In my eyes, the concepts could be exploited even better and
the style of the tools could be improved. Both would would simplify
and generalize the system, providing cleaner interfaces and more
software leverage, at the same time.
.P
In providing several parts of an email system, nmh would hardly
be able to compete with the large specialized projects that focus
on only one of the components. Concentrating all development power
on the most unique part of nmh and giving the user the choice to
pick his prefered set of the other mail components would be the better
approach in my eyes.
Today's pre-packaged software components encourage this approach.

.U2 "Why it is worth it
.P
MH is the most important of very few command line toolchest email systems.
(There's also \fIim\fP by Tatsuya Kinoshita,
which operates on an MH mail storage.)
Toolchests are powerful because they can be perfectly automated and
extended. Toolchests are good back-ends for various sorts of front-ends.
They allow multiple front-ends for different special needs
to be implemented quickly and withough internal knowledge on emailing.
Further more, toolchests are much better to maintain than large monolithic
programs.
As there are few toolchests for emailing and MH-like ones are the most
popular amoung them, they should be developed further to keep their
conceptional elegance and unique scripting qualities available to users.
mmh will create a modern and convenient entry point for new, interested
users to MH-like systems.
.P
It's worthwhile to fork nmh for the development of mmh, because
the two projects focus on different goals and differ in fundamental questions.
The nmh community's reluctance to change conflicts
with my strong will to change.
In developing a separate experimental version new approaches can
easily be tried out without the need to discuss changes beforehand.
In fact, revolutionary changes are hardly possible otherwise.
By forking nmh, mmh will likelier bring fresh air into the field of
MH-like mail systems than without forking.
Fresh air is good to reactivate a matured project.
.P
These reasons support the decision to start mmh as a fork of nmh.
Of course, the results of the mmh project shall improve nmh, in the end.

.U2 "Target Field
.P
The target user of mmh 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.
He naturally uses modern email features, like attachments,
non-ASCII text, and digital cryptrography.
He is able to setup email system components besides mmh,
and actually likes the choice to pick the ones he preferes.
He has a reasonably modern system that complies to standards,
like POSIX and ANSI C.
.P
XXX common scenarios?

.U2 "The 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.

.U2 "Work to do
.BU
Remove the 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.


.H1 "Goals of this Thesis

.U2 "Methods
.P
foo
mmh wants to provide a ready-to-use setup for modern emailing,
which is a necessity to spread among new users.