.RN 1
.H0 "Introduction
.Id introduction

.P
MH is a set of mail handling tools with a common concept.
It is similar to the Unix tool chest, which is a set of file
handling tools with a common concept.
\fInmh\fP is the currently most popular implementation of an
MH-like mail handling system.
This thesis describes an experimental version of nmh, named \fImmh\fP.
.P
This chapter introduces MH, its history, concepts and how it is used.
It describes nmh's code base and community to give the reader
a better understanding of the project's condition at the time when
mmh started off.
Furthermore, this chapter outlines the mmh project itself,
describing the motivation for it and its goals.


.H1 "MH \(en the Mail Handler
.Id mh
.P
MH is a conceptual email system design and its concrete implementation.
MH had started as a design proposal at RAND Corporation,
where the first implementation followed later.
In spirit, MH is similar to Unix, which
influenced the world more in being a set of system design concepts
than in being a specific software product.
The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
.[
gancarz unix philosophy
.]
MH follows this philosophy.

.U2 "History
.P
In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
proposed the design of a new mail handling system,
.[
shapiro gaines mh proposal
.]
to superseed RAND's old monolithic \fIMail System\fP (MS).
One year later, in 1978, Bruce Borden picked up on the
proposal and implemented a prototype, which he called
\fIMail Handler\fP (MH).
Before the prototype's existence, the concept was
believed to be practically unusable.
But the prototype \(en written in only three weeks \(en
proved successful and replaced MS thereafter.\&
.[ [
rand note design of mh
.], p. 4]
.P
In the early eighties,
the University of California at Irvine (UCI) started to use MH.
Marshall T. Rose and John L. Romine then became the driving force.
They took over the development and pushed MH forward.
.[ [
rand note design of mh
.], p. 4]
RAND had put the code into the public domain by then.
MH was developed at UCI at the same time when the Internet appeared,
BSD started to support TCP/IP networking,
and Eric Allman wrote Sendmail.
MH was extended as emailing became more featured.
The development of MH was closely related to the development of email RFCs.
In the advent of the \fIMultipurpose Internet Mail Extensions\fP (MIME),
MH was one of the first implementations of the new email standard.
.P
In the nineties, the Internet became popular and in December 1996,
Richard Coleman initiated the \fINew Mail Handler\fP (nmh) project.
Nmh is a fork of MH 6.8.3 and bases heavily on the
\fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
.[
lbl changes
.]
Colman intended to modernize MH and improve its portability and
MIME handling capabilities.
The development of MH at UCI stopped after the 6.8.4 release in
February 1996, soon after the development of nmh had started.
Today, nmh is developed openly in the Internet community.
It has almost completely replaced the original MH.
Some systems might still provide the old MH, but hardly for good reasons.
.P
In the last years, the majority of changes in nmh was maintenance work.
Nevertheless, the development was revived in December 2011
and stayed busy since then.


.U2 "Concepts
.P
MH consists of a set of tools, each covering a specific task of
email handling, such as composing a message, replying to a message,
refiling a message to a different folder, listing the messages in a folder.
The tools are invoked directly from the Unix shell.
.[
a rand note design of mh
.]
.P
The tools operate on a common mail storage, which consists of
\fImail folders\fP (directories) and \fPmessages\fP (regular files).
Each message is stored in a separate file.
.[
a rand note design of mh
.]
The files are named with ascending numbers in each folder.
The specific format of the mail storage characterizes MH in the same way
as the format of the file system characterizes Unix.
.P
MH tools maintain a \fIcontext\fP, which includes for instance the
current mail folder.
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 others.
.P
Messages are named by their numeric filename,
but they can have symbolic names, as well.
These are either one of six system-controlled position names
and a shorthand for the range of all messages,
or user-settable group names for arbitrary sets of messages.
These names are called sequences.
Automatically updated position names exist for the
first, last, previous, next, current message, and for the number
one beyond the last message.
(In mmh, the names of these sequences are abbreviated to the
first character.)
User-defined sequences can be bound to the folder containing the
messages (\fIpublic sequences\fP) or to the user's context
(\fIprivate sequences\fP).
.P
The user's \fIprofile\fP is the file that contains his MH configuration.
Default switches for the individual tools can be specified to
adjust them to the user's personal preferences.
These switches will be automatically supplied whenever the specific
tool is invoked.
Additionally, a single command can be linked under different names
with different default values.
Form templates for new messages and replies, as well as format files
to adjust the output of tools are easily exchanged in the profile.
Almost every part of the system can be adjusted to personal preference.
.P
The whole system is well scriptable and extensible.
New MH tools are built out of or on top of existing ones quickly.
MH encourages the user to tailor, extend, and automate the system.
As the MH tool chest was modeled after the Unix tool chest, the
properties of the latter apply to the former as well.



.U2 "Using MH
.P
Many tutorials to using MH
.[
rose sweet mh tutorial
.]
.[
moss jackson user's guide for mh
.]
.[
hegardt mh for beginners
.]
are old, but still they teach the concepts and basics,
which remained unchanged.
Rose and Romine have written an excellent introduction on a more
technical level, with pointers to advanced usage.
.[
rose romine real work
.]
For a more recent document, it is strongly recommended to have
a look at the \fIMH Book\fP,
.[ [
peek mh book
.], Part II]
especially at its online version.
.P
Following here is a sample mail handling session with mmh.
Details might vary to MH and nmh but the look and feel is the same.

.so input/mh-session


.H1 "nmh
.P
In order to understand the condition, goals and dynamics of a project,
one needs to know the reasons behind them.
This section gives background information.
.P
MH predates the Internet;
it comes from times before networking was universal;
it comes from times when emailing was small, short and simple.
Then, MH grew, spread and adapted to the changes email went through.
Its core concepts, however, remained the same.
During the eighties, students at UCI actively worked on MH.
They added new features and optimized the code for the systems
popular at that time.
This was in times before POSIX and ANSI C.
As large parts of the code stem from this time, today's nmh source code
still contains many ancient parts.
BSD-specific code and constructs tailored for hardware of that time
are frequent.
.P
Nmh started about one decade after the POSIX and ANSI C standards were
released.
A more modern coding style entered the code base but still
a part of the developers were ``of the old type''.
The developer base became more diverse,
thus broadening the range of different coding styles.
Programming practices from different decades merged in the project.
As several peers added code, the system became more a conglomeration
of single tools rather than a homogeneous of-one-cast mail system.
For that, leadership would have been necessary.
Nevertheless, MH's basic concepts held the project together.
They were mostly untouched throughout the years.
.P
Though clearly separated on the surface
\(en as a collection of small, separate programs \(en
the source code turns out to be fairly interwoven.
Multiple separate components are compiled into a program
for efficiency reasons.
This leads to intricate innards.
.P
It is visible in nmh that
the advent of MIME raised the complexity of email by a magnitude.
The MIME-related parts are the most complex ones.
It is also visible that MIME support was added on top of the old MH core.
MH's tool chest style made this easily possible and encourages
such approaches, but unfortunately, it led to duplicated functions
and half-hearted implementation of concepts.
.P
To provide backward-compatibility, it is a common understanding
in the nmh community to not change the default settings.
In consequence, users need to activate modern features explicitly
to be able to use them.
The ancient style in which fresh nmh setups remain to appear
causes difficulties for new users, as modern email features require
additional configuration.
The small but mature community around nmh, however, needs little change
as they have had their convenient setups for decades.


.H1 "mmh
.P
I started to work on my experimental version in October 2011,
basing my work on nmh version \fInmh-1.3-dev\fP.
At that time no more than three commits were made to nmh
since the beginning of 2011, the latest one being
.Ci a01a41d031c796b526329a4170eb23f0ac93b949 ,
committed on 2011-04-13.
In December, when I announced my work in progress on the
nmh-workers mailing list,
.[
nmh-workers mmh announce December
.]
nmh's community became active, all of a sudden.
This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
.[
nmh-workers vixie edginess
.]
After long years of stagnation, nmh became actively developed again.
Hence, while I was working on mmh, the community was working on nmh,
in parallel but unrelated.
.P
The name \fImmh\fP may stand for \fImodern mail handler\fP,
because the project tries to modernize nmh.
Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
emphasizing that the project is my version of nmh,
following my visions and preferences.
(My login name is \fImeillo\fP.)
This project model was inspired by \fIdwm\fP,
which is Anselm Garbe's personal window manager \(en
targeted to satisfy Garbe's personal needs whenever conflicts appear.
Dwm has retained its lean elegance and its focused character,
.[
dwm ohloh
.]
whereas its community-driven predecessor \fIwmii\fP had grown
fat over time.
.[
wmii ohloh
.]
The development of mmh should remain focused.


.U2 "Motivation
.P
MH is the most important of very few email systems in a tool chest style.
Tool chests are powerful because they can be perfectly automated and
extended.
They allow the implementation of arbitrary kinds of front-ends
on top of the tool chest quickly and without internal knowledge.
Additionally, tool chests are easier to maintain than monolithic
programs.
.[ [
gancarz unix phil
.], p. 14]
MH-like email tool chests should be kept alive as they fill a market
niche by providing conceptional elegance and unique scripting qualities.
Mmh tries to create a modern and convenient entry point to MH-like
systems for new and interested users.
.P
The mmh project is motivated by deficits of nmh and
by my wish for general changes.
At the time the mmh project started, nmh had not yet 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 did not want to have them active by default.
Mmh is my way to change this.
.P
.ZZ
In my eyes, MH's concepts could be exploited better and
the style of the tools could be improved.
Both would simplify and generalize the system, providing cleaner
interfaces and greater software leverage at the same time.
Mmh is my way to demonstrate this.
.P
In providing multiple parts of the email system, nmh can hardly
compete with the large specialized projects that focus
on one of the components only.
The situation could be improved by concentrating the development power
on the most unique part of MH and letting the user pick his preferred
set of other mail components.
Today's pre-packaged software components encourage this model.
Mmh is my way to provide this.
.P
It is 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 regarding change conflicts
with my strong desire for it.
.[
nmh-workers schnalke understanding nmh
.]
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.
.P
The mmh project provides the basis on which the aforementioned
ideas can be implemented and demonstrated,
without the need to change the nmh project or its community.
Of course, the results of the mmh project shall improve nmh, in the end.
By no means it is my intent to work against the nmh project.


.U2 "Target Field
.P
Any effort needs to be targeted towards a specific goal
in order to be successful.
Therefore, a description of an imagined typical mmh user follows.
Actually, as mmh is my personal version of MH,
this is sort of a description of myself.
Developing software for one's own is a reliable way to produce software
that matches the user's desires.
.P
The target user of mmh likes Unix and its philosophy.
He appreciates to use programs that are conceptionally appealing.
He is familiar with the command line and enjoys its power.
He is capable of shell scripting and wants to improve his
productivity by scripting the mail system.
He uses modern email features, such as attachments,
non-ASCII text, digital signatures and message encryption in a natural way.
He is able to set up mail system components
and likes to pick the ones he prefers.
He has a reasonably modern operating system that complies to the
POSIX and ANSI C standards.
.P
The typical user invokes mmh commands directly in an interactive
shell session, even on workstations where graphical front-ends could
be added.
Likely, he runs his mail setup on a server machine,
to which he connects via ssh.
He might automate mail processing with mmh tools
but definitely he uses the tools to build better tools.
In any case, he wants to have the flexibility to change
his setup to suit his needs.
.P
The typical mmh user is a programmer.
He likes to, occasionally, make use of the opportunity of free software
by putting hands on and getting involved in software he uses.
In consequence, he likes small and clean code bases and cares for
code quality.
In general, he believes that:
.BU
The elegance of source code is most important.
.BU
Concepts are more important than concrete implementations.
.BU
Code optimizations for anything but readability should be avoided.
.BU
Removed code is debugged code.
.BU
Having a lot of choice is bad.


.U2 "Goals of the mmh Project
.IP "Streamlining
Mmh should be stripped down to its core, which is the user agent (MUA).
The feature set should be distilled to the indispensable ones,
effectively removing corner cases.
Parts that do not add to the main task of being a conceptionally
appealing user agent should be removed.
This includes the mail transfer and mail retrieval facilities.
Choice should be reduced to the main options.
All tools should be tightly shaped.
.IP "Modernizing
Mmh's feature set needs to become more modern.
Better support for attachments, digital signatures, and message
encryption should be added.
MIME support should be integrated deeper and more naturally.
The modern email features need to be readily available, out-of-the-box.
On the other hand, obsolete facilities can be dropped out and
ancient technologies need not be further supported.
The available concepts should be expanded as far as possible.
A small set of concepts should recur consistently.
.IP "Styling
Mmh's source code should be updated to modern standards.
Standardized library functions should replace non-standard versions
whenever possible.
Code should be separated into distinct modules when feasible.
Time and space optimizations should to be replaced by
clear and readable code.
A uniform programming style should prevail.
The whole system should appear to be of-one-style;
it should feel like being cast as one.