.RN 1

.H0 "Introduction
.P
MH is a set of mail handling tools with a common concept, 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 state of mmh when it started off.
Further more, this chapter outlines the mmh project itself,
describing the motivation for it and its goals.


.H1 "MH \(en the Mail Handler
.P
MH is a conceptual email system design and its concrete implementation.
Notably, 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.
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, 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's existence, the concept was
believed to be practically unusable.
But the prototype proved successful and replaced MS thereafter.
In replacing MS, MH grew to an all-in-one mail system.
.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 had put the code into the public domain by then.
MH was developed at UCI at the time when the Internet appeared,
when UCB implemented the TCP/IP stack, and when 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 MIME, MH was the first implementation of this new
email standard.
.P
In the nineties, the Internet became popular and in December 1996,
Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
Nmh is a fork of MH 6.8.3 and bases strongly 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 at UCI stopped after the 6.8.4 release in
February 1996, soon after the development of nmh had started.
Today, nmh has almost completely replaced the original MH.
Some systems might still provide old MH, but mainly for historical reasons.
.P
In the last years, the work on nmh was mostly maintenance work.
However, 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, like composing a message, replying to a message,
refiling a message to a different folder, listing the messages in a folder.
All of the programs operate on a common mail storage.
.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 was
received (i.e. transfer format).
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 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,
too. These are either automatically updated
position names such as 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 containing folder or to the context.
.P
The user's \fIprofile\fP is a file that contains his MH configuration.
Default switches for the individual tools can be specified to
adjust them to the user's personal preferences.
Multiple versions of the same command with different
default values can also be created very easily.
Form templates for new messages or for replies are easily changeable,
and output is adjustable with format files.
Almost every part of the system can be adjusted to personal preference.
.P
The system is well scriptable and extensible.
New MH tools are built out of or on top of existing ones quickly.
Further more, 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.


.ig \"XXX

.P
To ease typing, the switches can be abbreviated as much as the remaining
prefix remains unambiguous.
If in our example no other switch would start with the letter `t', then
.Cl "-truncate" ,
.Cl "-trunc" ,
.Cl "-tr" ,
and
.Cl "-t
would all be the same.
As a result, switches can neither be grouped (as in
.Cl "ls -ltr" )
nor can switch arguments be appended directly to the switch (as in
.Cl "sendmail -q30m" ).
.P
Many switches have negating counter-parts, which start with `no'.
For example
.Cl "-notruncate
inverts the
.Cl "-truncate
switch.
They exist to undo the effect of default switches in the profile.
If the user has chosen to change the default behavior of some tool
by adding a default switch to the profile,
he can still undo this change in behavior by specifying the inverse
switch on the command line.

..


.U2 "Using MH
.P
It is strongly recommended to have a look at the MH Book,
which offers a thorough introduction to using MH.
.[ [
peek mh book
.], Part II]
Rose and Romine provide a deeper and more technical
though slightly outdated introduction in only about two dozens pages.
.[
rose romine real work
.]
.P
Following is an example mail handling session.
It uses mmh but is mostly compatible with nmh and old MH.
Details might vary but the look and feel is the same.

.VF input/mh-session


.H1 "nmh: Code and Community
.P
In order to understand the condition, goals and dynamics of a project,
one needs to know the reasons behind them.
This section explains the background.
.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 it 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 then popular systems.
All this still 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 a decade after the POSIX and ANSI C standards were
established. A more modern coding style entered the code base, but still
a part of the developers came from ``the old days''. 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.
Still, the existing basic concepts held it together.
They were mostly untouched throughout the years.
.P
Despite the separation of the tool chest approach at the surface
\(en a collection of small, separate programs \(en
on the source code level, it is much more interweaved.
Several separate components were compiled into one program
for efficiency reasons.
This led to intricate innards.
While clearly separated on the outside,
the programs turned out to be fairly interweaved inside.
.\" XXX FIXME rewrite...
.\" Unfortunately, the clear separation on the outside turned out to be
.\" fairly interweaved inside.
.P
The advent of MIME raised the complexity of email by a magnitude.
This is visible in nmh. 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 the concepts.
.P
To provide backward-compatibility, it is a common understanding to not
change the default settings.
In consequence, the user needs to activate modern features explicitly
to be able to use them.
This puts a burden on new users, because out-of-the-box nmh remains
in the same ancient style.
If nmh is seen to be a back-end, then this compatibility surely is important.
However, in the same go, new users have difficulties using nmh for modern
emailing.
The small but mature community around nmh needs few change
as they have had their convenient setups for decades.


.H1 "mmh
.P
I started to work on my experimental version in October 2011,
at a time when there had been no more than three commits to nmh
since the beginning of the year.
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, too.
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 once more working
on nmh, in parallel.
.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 follows 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 had retained its lean elegance and its focused character, whereas
its community-driven predecessor \fIwmii\fP had grown fat over time.
The development of mmh should remain focused.


.U2 "Motivation
.P
MH is the most important of very few command line tool chest email systems.
Tool chests are powerful because they can be perfectly automated and
extended. They allow arbitrary kinds of front-ends to be
implemented on top of them quickly and without internal knowledge.
Additionally, tool chests are easier to maintain than monolithic
programs.
As there are few tool chests for emailing and as MH-like ones are the most
popular among them, they should be developed further.
This keeps their
conceptional elegance and unique scripting qualities available to users.
Mmh creates 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
my wish for general changes, combined
with the nmh community's reluctancy to change.
.P
At that time, nmh had not 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 as default.
Mmh is a way to change this.
.P
In my eyes, MH's concepts could be exploited even better and
the style of the tools could be improved. Both would simplify
and generalize the system, providing cleaner interfaces and more
software leverage at the same time.
Mmh is a way to demonstrate this.
.P
In providing several parts of an email system, nmh can hardly
compete with the large specialized projects that focus
on only one of the components.
The situation can 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 a way to go for this approach.
.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.
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 nmh or its community.
Of course, the results of the mmh project shall improve nmh, in the end.
By no means is my intend 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.
Following is a description of imagined typical mmh users.
Mmh should satisfy their needs.
.\" XXX  Remove the next sentence?
Actually, as mmh is my personal version of MH, this is a description
of myself.
.P
The target users of mmh like Unix and its philosophy.
They appreciate to use programs that are conceptionally appealing.
They are familiar with the command line and enjoy its power.
They are at least capable of shell scripting and want to improve their
productivity by scripting the mail system.
.\" XXX Naturally, he uses ...
They naturally use modern email features, such as attachments,
non-ASCII text, and digital cryptography.
They are able to setup email system components besides mmh,
and actually like to have the choice to pick the ones they prefer.
They have a reasonably modern operating system that complies to standards,
like POSIX and ANSI C.
.P
The typical users invoke mmh commands directly in an interactive
shell session, but they use them to automate mail handling tasks as well.
Likely, they runs their mail setup on a server machine,
to which they connect via ssh.
They might also have local mmh installations on their workstations,
where they tend to work with mmh directly in the shell instead
of using graphical front-ends.
They definitely want to be flexible and thus be able to change
their setup to suit their needs.
.P
.\" XXX themself vs. themselves
Typical mmh users are programmers themselves.
They like to, occasionally, take the opportunity of Free Software to put
hands on and get involved in the software they use.
Hence, they like small and clean code bases and care for code quality.
In general, they believe that:
.BU
Elegance \(en i.e. simplicity, clarity and generality \(en
is most important.
.BU
Concepts are more important than the concrete implementation.
.BU
Code optimizations for anything but readability should be avoided
if possible.
.BU
Having a lot of choice is bad.
.BU
Removed code is debugged code.

.U2 "Goals
.P
The general goals for the mmh project are the following:
.IP "Stream-lining
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 don't add to the main task of being a conceptionally
appealing MUA should be removed.
This includes the mail submission and mail retrieval facilities.
Choice should be reduced to the main options.
.IP "Modernizing
Mmh's feature set needs to become more modern.
Better support for attachment and digital cryptography should be added.
MIME support should to be integrated deeper and more naturally.
The modern email features need to be readily available, out-of-the-box.
On the other hand,
bulletin board support and similar obsolete facilities can be dropped out.
Likewise, ancient technologies such as hardcopy terminals
need not to be supported any further.
.IP "Code style
Mmh's source code needs to 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.
.IP "Homogeneity
The available concepts need to be expanded as far as possible.
A small set of concepts should recur consistently.
The whole system should appear to be of-one-style;
it should feel like being cast as one.