.RN 1

.H0 "Introduction
.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 from which mmh 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
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.
But the prototype had proven 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) had started to use MH.
They also took over its development and pushed MH forward.
Marshall T. Rose and John L. Romine became the driving force then.
This was 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, MH had been moved into the public domain, making it
attractive to Free Software developers.
The Internet had became popular and in December 1996,
Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
The project 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 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 revived in December 2011 and stayed busy since then.

.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, 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 had been
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
like 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 other users.
.P
Messages are named by their numeric filename, but they can have symbolic names,
too. These are either 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 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 changable,
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 extendable.
New MH tools are built out of or on top of existing ones quickly.
Further more, MH encourages the user to taylor, extend and automate the system.
As the MH toolchest was modelled after the Unix toolchest, the
properties of the latter apply to the former as well.


.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 backward-compatibility's sake, it is a common understanding to have the
default settings to be compatible, requiring any new feature to be
explicitely enabled.
In consequence, the user needs to activate modern features explicitely
to be able to use them.
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 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.
.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.


.H1 "This Thesis

.U2 "Motivation
.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
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.
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 prefered
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'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.
These reasons support the decision to start mmh as a fork of nmh.
.P
The mmh project provides the basis to implemented and demonstrated
the listed ideas without the need to change nmh or its community.
Of course, the results of the mmh project shall improve nmh, in the end.

.U2 "Target Field
.P
Any effort needs to be targeted towards a specific goal
in order to be successful.
Following is a description of the imagined typical mmh user.
mmh should satisfy his needs.
Actually, as mmh is my personal version of MH, this is a description
of myself.
.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
The typical user invokes mmh commands directly in an interactive
shell session, but as well, he uses them to automate mail handling tasks.
Likely, he runs his mail setup on a server machine, to which he connects
via ssh. He might also have local mmh installations on his workstations,
but does rather not rely on graphical frontends. He definitely wants
to be flexible and thus be able to change his setup to suite his needs.
.P
The typical mmh user is a programmer himself.
He likes to, occasionally, take the opportunity of Free Software to put
hands on and get involved in the software he uses.
Hence, he likes small and clean code bases and he cares for code quality.
In general, he believes 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 MUA part of emailing.
The feature set should be distilled to the ones really needed,
effectively removing corner-cases.
Functions that are not related to the main task should be removed.
This includes, the MTA and MRA 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 needs to be added.
MIME support needs to be integrated deeper and more naturally.
The modern email features need to be readily available, out-of-the-box.
And on the other hand,
bulletin board support and similar obsolete facilities need to be dropped
out.
Likewise, ancient technologies, like hardcopy terminals, should not
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 possible.
Time and space optimizations should to be replaced by
clear and readable code.
A uniform programming style should prevail.
.IP "Homogenity
The available concepts need to be expanded as far as possible.
A small set of concepts should prevail thoroughly throughout the system.
The whole system should appear to be of-one-style.
It should feel like being cast as one.