meillo@0: .H0 "Introduction
meillo@0: .P
meillo@2: This chapter describes the background of the topics in this thesis.
meillo@2: General knowledge of electronic mail is assumed.
meillo@8: It explains the situation at the start of the project.
meillo@8: It tries to describe from what state the project lifted of and where
meillo@8: it headed to. This shall give an overview.
meillo@8: 
meillo@0: 
meillo@27: .H1 "Email Prerequisites
meillo@27: .P
meillo@27: XXX Do we really need that?
meillo@27: 
meillo@27: 
meillo@0: .H1 "What is MH?
meillo@0: .P
meillo@2: MH is an electronic mail system, originating in the RAND Corporation.
meillo@27: Historically, it had been a all-in-one mail system, with both Mail Transfer
meillo@2: Agent (MTA) and Mail User Agent (MUA).
meillo@27: Later, when email setups changed, Mail Submission Agent (MSA)
meillo@2: and Mail Retrieval Agent (MRA) facilities were added.
meillo@2: The MTA became less important, whereas the MUA became even more the
meillo@2: central part.
meillo@2: .P
meillo@27: MH defines a mail handling concept.
meillo@2: It had started as a design proposal, not as an implementation, and 
meillo@27: in spirit had remained this way. This is similar to Unix, which
meillo@27: rather is a style of system design than specific software product.
meillo@27: .P
meillo@27: XXX Link to the Unix phil.
meillo@27: .P
meillo@27: XXX comparision to monolithic mail systems.
meillo@27: .P
meillo@27: XXX Differenciation of MUA and mail system.
meillo@2: 
meillo@11: .U2 "History
meillo@2: .P
meillo@2: MH is an electronic mail system, originating in the RAND Corporation.
meillo@2: In 1977, Norman Shapiro and Stockton Gaines had proposed the design
meillo@2: of a new mail handling system, called ``Mail Handler'' (MH) for RAND,
meillo@2: to superseed their ``Mail System'' (MS).
meillo@27: Two years later, in 1979, Bruce Borden took the proposal and implemented a
meillo@2: prototype of MH. It proved successful and replaced MS thereafter.
meillo@2: .P
meillo@2: A decade later, the University of California had started to use MH.
meillo@2: They also took over its development and pushed MH forward.
meillo@2: This had been the time when the Internet appeared, Berkeley implemented
meillo@2: the TCP stack, and Sendmail was born. MH had often contained the first
meillo@2: implementation of new RFCs.
meillo@2: .P
meillo@2: In the nineties, MH had been moved into the public domain, making it
meillo@2: attractive to Free Software developers. The Internet had started to become
meillo@2: mainstream and in 1997, Richard Coleman initiated the ``New Mail Handler''
meillo@2: (nmh), a fork of MH. He intended to modernize MH, improve its MIME
meillo@2: capabilities, and this should be done openly within the Internet
meillo@2: community. Today, nmh almost completely replaced the original MH.
meillo@0: 
meillo@11: .U2 "Concepts
meillo@0: .P
meillo@8: MH is a toolchest, modelled after the Unix toolchest. It consists of a
meillo@8: bunch of tools, each covering one task of email handling. These programs
meillo@8: operate on a common mail storage. The specific format of the mail storage
meillo@8: also defines MH, like the file system structure defines Unix. It
meillo@8: consists of directories (mail folders) and files (mail messages).
meillo@8: Each file contains exactly one message in the format it had been
meillo@8: received (i.e. transfer format). MH tools carry a state (context),
meillo@8: consisting of current mail folder and current message. Messages can
meillo@8: have symbolic names, like the next or last message or for some
meillo@8: arbitrary group of messages. These names are called sequences.
meillo@2: .P
meillo@8: New MH tools can be build out of existing ones easily. Default values to
meillo@8: commands are stored on a command name-basis, making it trivial to have
meillo@8: different versions of the same command with different defaults. Most
meillo@8: of the configuration is stored in the user's profile. Form templates,
meillo@8: e.g. for new messages or replies, are exchangeable and output is generally
meillo@8: adjustable with format files.
meillo@2: .P
meillo@8: MH allows the user to automate almost everything and to modify amost
meillo@8: any behavior. The system is scriptable and extendable.
meillo@8: 
meillo@27: .U2 "Available Versions
meillo@27: .P
meillo@27: Three versions of MH are available today:
meillo@27: .BU
meillo@27: .I "Original MH" .
meillo@27: In most cases it has been replaced by nmh, but some systems still
meillo@27: provide old MH. As nmh is old MH-compatible, there exist few reasons
meillo@27: not to upgrade to new.
meillo@27: The development of old MH has stopped after the 6.8.4 release in
meillo@27: February 1996.
meillo@27: .BU
meillo@27: .I nmh .
meillo@27: The most widespread version of MH was forked off version 6.8.3 in December
meillo@27: 1996. It incorporated the \fILBL changes\fP.
meillo@27: It provides backward-compatible to old MH by having new featues deactivated
meillo@27: by default. To use them, the user needs to activate them explicitely.
meillo@27: Its development went slowly in the previous years, but had revived
meillo@27: in December 2011.
meillo@27: .BU
meillo@27: .I mmh .
meillo@27: This version is the subject of this thesis.
meillo@27: It is a descendent of nmh. It had started as a non-compatible experimental
meillo@27: version, but became de facto a fork. It tries to expand the same
meillo@27: principle concepts in a more modern way.
meillo@8: 
meillo@27: .U2 "Example Session
meillo@27: .P
meillo@27: Example mail handling session with mmh, but mostly compatible with nmh
meillo@27: and old MH. The look'n'feel is common among them.
meillo@27: 
meillo@27: 
meillo@27: .H1 "Understanding the Code and Community
meillo@2: .P
meillo@8: In order to understand the state, goals and dynamics of a project,
meillo@8: one needs to know its history. MH comes from a time before the
meillo@8: Internet, a time before networking became universal, a time when
meillo@8: emailing was small, short and simple. Then it grew, spread and
meillo@8: adopted to the changes. The core-concepts, however, remained the
meillo@8: same. During the XXX a small group of students at the University of
meillo@8: California, actively worked on MH. They added features and optimized,
meillo@8: like it is common for scientific work. This is still in pre-ANSI C
meillo@8: times. The source code contains many ancient parts. Code constructs
meillo@8: specific to BSD or hardware of that time are usual.
meillo@2: .P
meillo@8: Nmh started eight years after the ANSI C standard had been
meillo@8: established. A more modern coding style entered the code base. Still
meillo@8: a part of the developers come from ``the old days''. The developer
meillo@8: base became more diverse and thus the code. Programming practices
meillo@8: from different decades merged into the project. Different coding
meillo@8: styles came together. It appears as if multiple peers added code
meillo@8: parts, resulting in a conclomeration rather than an homogenic
meillo@8: of-one-cast mail system. Still, the basic concepts hold it together.
meillo@8: They were mostly untouched throughout the years.
meillo@8: .P
meillo@8: Although, at the surface, nmh is a toolchest, meaning a collection
meillo@8: of completely modularized small programs, on the source code level,
meillo@8: it is much more interweaved. Parts of the basic functions are
meillo@8: collected in a MH standard library, which is good, but often
meillo@8: separate functions are compiled into programs, for effiency reasons.
meillo@8: This lead to intricate innards.
meillo@8: The advent of MIME rose the complexity of email by a magnitude. This
meillo@8: is visible in nmh. The MIME-related parts are the most complex ones.
meillo@8: It's also visible that MIME support had been added on top of the
meillo@8: original MH later. The MH style made this easily possible, but it
meillo@8: also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
meillo@8: and had not been thoroughly included into the concepts (e.g. the
meillo@8: user-visible access to whole messages and MIME parts are inherently
meillo@8: different).
meillo@8: .P
meillo@8: For compatibility's sake, it is a common understanding to have the
meillo@8: default settings to be compatible, requiring any new feature to be
meillo@8: explicitely enabled. This puts a burden on new users, because nmh
meillo@8: out-of-the-box keeps staying in the same ancient style, where users
meillo@8: usually want to have it practical for modern emailing.
meillo@8: But of course, this depends on if nmh is seen to be a front-end or a
meillo@8: back-end.
meillo@8: 
meillo@8: 
meillo@27: .H1 "mmh
meillo@27: 
meillo@27: .U2 "Motivation
meillo@27: .P
meillo@27: XXX
meillo@27: 
meillo@27: .U2 "Why it is worth it
meillo@27: .P
meillo@27: XXX
meillo@27: 
meillo@27: .U2 "Target Field
meillo@27: .P
meillo@27: XXX Target field and scenarios
meillo@27: .P
meillo@27: The target user in mind likes Unix and its philosophy.
meillo@27: He likes to use programs that are conceptionally appealing.
meillo@27: He's familiar with the command line and enjoys its power.
meillo@27: He is at least capable of shell scripting and wants to improve his
meillo@27: productivity by scripting the mail system.
meillo@27: His computer and operating system are from post-ANSI C times.
meillo@27: He likes to attach files, exchanges text containing non-ASCII
meillo@27: characters, signs or encrypts his messages.
meillo@27: He does not use bulletin boards anymore, nor non-mbox style mail
meillo@27: drops, nor does he rely on compatibility to nmh.
meillo@27: He already has and MTA/MSA and MRA running or is able to set them
meillo@27: up.
meillo@27: He does not want to have to read a book in order to make his MUA
meillo@27: usable.
meillo@27: .P
meillo@27: XXX Limitations
meillo@27: 
meillo@27: .U2 "The Vision
meillo@8: .P
meillo@8: The general goals of the mmh project are the following:
meillo@8: .BU
meillo@8: I believe that mmh should be perfectly suited for modern emailing,
meillo@8: out-of-the-box.
meillo@8: .BU
meillo@8: I care less about compatibility and more about conceptionally elegant
meillo@8: approaches.
meillo@8: .BU
meillo@8: I care for general, clear, and simple concepts.
meillo@8: .BU
meillo@8: I like to create an of-one-style email system. It should feel like
meillo@8: cast as one.
meillo@8: .BU
meillo@8: I plan to remove any optimizations that rises obscurity, unless it
meillo@8: appears to be neccessary to make mmh usable at all.
meillo@8: 
meillo@27: .U2 "Work to do
meillo@8: .BU
meillo@27: Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
meillo@8: task. Mail shall enter mmh's mail storage via the system mail drop
meillo@8: and it shall leave mmh via the local \fLsendmail\fP command.
meillo@8: .BU
meillo@8: Remove any further functions that are not related to mmh's main task.
meillo@8: Bulletin board support is on example. Also remove support for ancient 
meillo@8: technologies, like hardcopy terminals.
meillo@8: .BU
meillo@8: Refactor the source code to meet modern style criteria. Use
meillo@8: standardized library functions when possible.
meillo@8: .BU
meillo@8: Replace performance optimizations by clear and readable code.
meillo@8: .BU
meillo@8: Reduce the feature set to the commonly used one, removing
meillo@8: corner-cases. Set sane default values.
meillo@8: .BU
meillo@8: Add better attachment support. Add support for digital signatures and
meillo@8: encryption.
meillo@8: .BU
meillo@8: Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
meillo@8: Integrate MIME support deeper and more natural into MH.
meillo@8: .BU
meillo@8: Provide a ready-to-use setup out-of-the-box.
meillo@27: 
meillo@27: 
meillo@27: .H1 "Goals of this Thesis
meillo@27: 
meillo@27: .U2 "Methods
meillo@27: .P
meillo@27: foo