--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/intro.roff	Sat Jun 23 22:12:14 2012 +0200
@@ -0,0 +1,394 @@
+.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 had become 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, 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 implements and demonstrates 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.
+.\" XXX  Remove the next sentence?
+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 cryptography.
+He is able to setup email system components besides mmh,
+and actually likes the choice to pick the ones he prefers.
+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 front-ends. 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 user agent (MUA).
+The feature set should be distilled to the ones really needed,
+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 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 "Homogeneity
+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.