meillo@39: .RN 1 meillo@39: meillo@0: .H0 "Introduction meillo@0: .P meillo@32: This chapter introduces MH, its history, concepts and how it is used. meillo@32: Then, it describes nmh's code base and community to give the reader meillo@32: a better understanding of the state from which mmh started off. meillo@32: Further more, this chapter lists the motivation and goals of the mmh project. meillo@32: This chapter introduces MH, nmh and mmh to the reader and outlines meillo@32: the mmh project itself. meillo@8: meillo@0: meillo@28: .H1 "MH \(en the Mail Handler meillo@0: .P meillo@2: MH is an electronic mail system, originating in the RAND Corporation. meillo@32: Most important for this thesis is that MH defines a mail handling concept. meillo@32: In fact, MH had started as a design proposal, not as an implementation, meillo@32: and in spirit it had remained this way. This is similar to Unix, which meillo@42: influenced the world more in being a set of system design concepts meillo@32: than in being a specific software product. meillo@42: These ideas behind Unix are summarized in the \fIUnix philosophy\fP. meillo@42: MH follows this philosophy. meillo@2: meillo@11: .U2 "History meillo@2: .P meillo@2: MH is an electronic mail system, originating in the RAND Corporation. meillo@32: In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines meillo@32: had proposed the design meillo@32: of a new mail handling system, called ``Mail Handler'' (MH), meillo@32: to superseed RAND's old monolithic ``Mail System'' (MS). meillo@27: Two years later, in 1979, Bruce Borden took the proposal and implemented a meillo@32: prototype of MH. meillo@32: Before the prototype had been available, the concept was meillo@32: believed to be practically unusable because of being too slow. meillo@32: But the prototype proved successful and replaced MS thereafter. meillo@32: In replacing MS, MH became an all-in-one mail system. meillo@2: .P meillo@32: A decade later, the University of California at Irvine had started to use MH. meillo@2: They also took over its development and pushed MH forward. meillo@32: This was the time when the Internet appeared, UCB implemented meillo@32: the TCP/IP stack, and Allman wrote Sendmail. meillo@32: MH was extended as emailing got more features. meillo@32: The development of MH was closely related to the development of email meillo@32: RFCs. In the advent of MIME, MH was the first implementation of this new meillo@32: email standard. meillo@2: .P meillo@2: In the nineties, MH had been moved into the public domain, making it meillo@32: attractive to Free Software developers. meillo@32: The Internet had started to become popular and in 1997, meillo@32: Richard Coleman initiated the ``New Mail Handler'' (nmh) project, meillo@32: a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels meillo@32: and Craig Leres. meillo@32: Colman intended to modernize MH and improve its portability and meillo@32: MIME handling capabilities. meillo@32: This should be done openly within the Internet community. meillo@32: The development of MH stopped soon after the development of nmh had started. meillo@32: 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@42: set of tools, each covering a specific task of email handling. meillo@42: The programs meillo@8: operate on a common mail storage. The specific format of the mail storage meillo@32: characterizes MH in the same way like the format of the file system meillo@32: characterizes Unix. meillo@42: .P meillo@32: The mail storage consists of \fImail folders\fP (directories) and meillo@32: \fPmessages\fP (regular files). meillo@32: Each message is stored in a separate file in the format it had been meillo@32: received (i.e. transfer format). The files are named with ascending numbers meillo@32: in each folder. meillo@42: .P meillo@32: MH tools maintain a \fIcontext\fP, which includes meillo@32: the current mail folder and current message. meillo@32: Processes in Unix have a similar context, containing the current working meillo@32: directory, for instance. In contrast, the process context is maintained meillo@32: by the Unix kernel automatically, whereas MH tools need to maintain the MH meillo@32: context themselves. meillo@32: The user can have one MH context or multiple ones, he can even share it meillo@32: with other users. meillo@42: .P meillo@32: Messages can have symbolic names. These can be automatically updated meillo@32: position names like being the next or the last message, meillo@32: or user-settable group names for arbitrary sets of messages. meillo@32: These names are called sequences. meillo@32: Sequences can be bound to the folder or to the context. meillo@2: .P meillo@32: New MH tools are built out of or on top of existing ones easily \(en meillo@32: a property common to toolchests. meillo@32: Multiple versions of the same command with different default values meillo@32: are created very easily. This provides shortcuts and tayloring. meillo@32: Form templates for new messages or for replies are easily exchangable. meillo@32: Generally, output is adjustable with format files. meillo@42: .P meillo@32: The configuration is stored in a file that is called the user's \fIprofile\fP. meillo@32: MH encourages the user to taylor and automate the mail handling. meillo@42: Almost every part of the system can be adjusted to personal preference. meillo@32: The system is well scriptable and extendable. meillo@32: As the MH toolchest was modelled after the Unix toolchest, the meillo@32: properties of the latter apply to the former as well. meillo@8: meillo@32: .U2 "Versions meillo@27: .P meillo@27: Three versions of MH are available today: meillo@32: .IP "Old MH" meillo@42: .br meillo@32: In most cases this version had been replaced by nmh, meillo@32: but some systems might still provide old MH. meillo@32: The main reasons to still use old MH are historical reasons. meillo@32: MH provides hardly any benefits over nmh. meillo@27: The development of old MH has stopped after the 6.8.4 release in meillo@27: February 1996. meillo@42: .IP nmh meillo@42: .br meillo@27: The most widespread version of MH was forked off version 6.8.3 in December meillo@32: 1996. It is based on the \fILBL changes\fP. meillo@32: Backward-compatibility to old MH is provided by having new featues deactivated meillo@32: by default. In consequence, the user needs to activate them explicitely to meillo@32: be able to use them. meillo@32: Throughout the previous years, the work on nmh was mostly maintenance work. meillo@32: Development revived in December 2011 and stayed busy since then. meillo@32: .IP mmh meillo@42: .br meillo@32: This descendent of nmh is the subject of this thesis. meillo@32: It had started as an experimental version, but became de facto a fork. meillo@8: meillo@27: .U2 "Example Session meillo@27: .P meillo@32: Following is an example mail handling session with mmh. meillo@32: It should be mostly compatible with nmh and old MH. meillo@32: Details might vary but the look'n'feel is the same. meillo@42: .DS meillo@42: $ \f(CBinc\fP meillo@42: Incorporating new mail into inbox... meillo@42: meillo@42: 1+ 2012-05-16 11:16 meillo@dream.home Hello meillo@42: 2 2012-05-16 11:17 meillo@dream.home book meillo@42: meillo@42: $ \f(CBshow\fP meillo@42: Date: Wed, 16 May 2012 11:16:00 +0200 meillo@42: To: meillo meillo@42: From: meillo@42: Subject: Hello meillo@42: meillo@42: part text/plain 13 meillo@42: mmh is great meillo@42: meillo@42: $ \f(CBnext\fP meillo@42: Date: Wed, 16 May 2012 11:17:24 +0200 meillo@42: To: meillo meillo@42: From: meillo@42: Subject: book meillo@42: meillo@42: part text/plain 79 meillo@42: Hello meillo, meillo@42: meillo@42: have a look at the ``Daemon book''. You need to read that! meillo@42: meillo@42: foo meillo@42: meillo@42: $ \f(CBrmm 1\fP meillo@42: meillo@42: $ \f(CBscan\fP meillo@42: 2+ 2012-05-16 11:17 meillo@dream.home book meillo@42: meillo@42: $ meillo@42: .DE meillo@27: meillo@27: meillo@28: .H1 "nmh: Code and Community meillo@2: .P meillo@8: In order to understand the state, goals and dynamics of a project, meillo@42: one needs to know its history. MH predates the Internet, meillo@42: it comes from times before networking was universal, meillo@42: times when emailing was small, short and simple. meillo@42: Then it grew, spread and adopted to the changes email went through. meillo@42: The core-concepts, however, remained the same. meillo@42: During the 80s 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@42: base became more diverse and thus the code had different style. meillo@42: 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@42: parts, resulting in a conclomeration rather than a 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@32: old 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@28: .P meillo@42: I started to work on my experimental version in Fall 2011. meillo@42: In December, when I announced my work on the nmh-workers mailing list, meillo@42: .[ meillo@42: nmh-workers mmh announce december meillo@42: .] meillo@42: the activity in nmh rose heavily. meillo@42: Suddently the community started to move. meillo@42: This movement was pushed much by Paul Vixie's ``edginess'' message. meillo@42: .[ meillo@42: nmh-workers vixie edginess meillo@42: .] meillo@42: After long years of much stagnation, nmh became actively developed again. meillo@42: Hence, while I was working on mmh, the community was working on nmh, meillo@42: in parallel. meillo@42: meillo@43: .U2 Naming meillo@28: .P meillo@42: The name \fImmh\fP stands for \fImeillo's mail handler\fP, meillo@42: because mmh is my own version of MH. meillo@42: (My login name is \fImeillo\fP.) meillo@42: The project follows my personal considerations and preferences. meillo@42: By calling it a personal project, I don't need to justify my decisions, meillo@42: though, still I do. meillo@42: This enabled me to follow my vision staightly and thus produce meillo@42: a result of greater pureness. meillo@42: This project model was inspired by the window manager \fIdwm\fP, meillo@42: which is Anselm Garbe's personal window manager \(en meillo@42: targeted to satisfy Garbe's personal needs whenever conflicts appear. meillo@42: dwm had remained much more focused on its original goals, meillo@42: whereas its community-driven predecessor \fIwmii\fP had meillo@42: grown large and lost it's leanness. meillo@42: This should not happen to mmh. meillo@42: .P meillo@42: mmh can also stand for \fImodern mail handler\fP, and this is meillo@42: the variant chosen as titel for this document. One main focus of the meillo@42: project was to modernize nmh. Another main goal is resembled in the meillo@42: name \fIminimized mail handler\fP: Drop any parts that don't add meillo@42: to the main task of mmh, being a MUA. meillo@42: .P meillo@42: It should also be noted that \fLstrcmp("mmh","nmh")<0\fP is true. meillo@42: Although mmh bases on nmh, it is likely seen as a step backward. meillo@42: I agree. meillo@42: However, this step backward actually is a step forward, meillo@42: although in another direction. meillo@27: meillo@27: .U2 "Motivation meillo@27: .P meillo@43: The mmh project is motivated by deficites of nmh and meillo@43: my wish for general changes, combined meillo@43: with the nmh community's reluctancy to change. meillo@43: .P meillo@43: nmh hadn't adjusted to modern emailing needs well enough. meillo@43: The default setup was completely unusable for modern emailing. meillo@43: Too much setup work was required. meillo@43: Several modern features were already available but the community meillo@43: didn't wanted to have them as default. meillo@43: .P meillo@43: In my eyes, the concepts could be exploited even better and meillo@43: the style of the tools could be improved. Both would would simplify meillo@43: and generalize the system, providing cleaner interfaces and more meillo@43: software leverage, at the same time. meillo@43: .P meillo@43: In providing several parts of an email system, nmh would hardly meillo@43: be able to compete with the large specialized projects that focus meillo@43: on only one of the components. Concentrating all development power meillo@43: on the most unique part of nmh and giving the user the choice to meillo@43: pick his prefered set of the other mail components would be the better meillo@43: approach in my eyes. meillo@43: Today's pre-packaged software components encourage this approach. meillo@27: meillo@27: .U2 "Why it is worth it meillo@27: .P meillo@43: MH is the most important of very few command line toolchest email systems. meillo@43: (There's also \fIim\fP by Tatsuya Kinoshita, meillo@43: which operates on an MH mail storage.) meillo@43: Toolchests are powerful because they can be perfectly automated and meillo@43: extended. Toolchests are good back-ends for various sorts of front-ends. meillo@43: They allow multiple front-ends for different special needs meillo@43: to be implemented quickly and withough internal knowledge on emailing. meillo@43: Further more, toolchests are much better to maintain than large monolithic meillo@43: programs. meillo@43: As there are few toolchests for emailing and MH-like ones are the most meillo@43: popular amoung them, they should be developed further to keep their meillo@43: conceptional elegance and unique scripting qualities available to users. meillo@43: mmh will create a modern and convenient entry point for new, interested meillo@43: users to MH-like systems. meillo@43: .P meillo@43: It's worthwhile to fork nmh for the development of mmh, because meillo@43: the two projects focus on different goals and differ in fundamental questions. meillo@43: The nmh community's reluctance to change conflicts meillo@43: with my strong will to change. meillo@43: In developing a separate experimental version new approaches can meillo@43: easily be tried out without the need to discuss changes beforehand. meillo@43: In fact, revolutionary changes are hardly possible otherwise. meillo@43: By forking nmh, mmh will likelier bring fresh air into the field of meillo@43: MH-like mail systems than without forking. meillo@43: Fresh air is good to reactivate a matured project. meillo@43: .P meillo@43: These reasons support the decision to start mmh as a fork of nmh. meillo@43: Of course, the results of the mmh project shall improve nmh, in the end. meillo@27: meillo@27: .U2 "Target Field meillo@27: .P meillo@43: The target user of mmh 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@43: He naturally uses modern email features, like attachments, meillo@43: non-ASCII text, and digital cryptrography. meillo@43: He is able to setup email system components besides mmh, meillo@43: and actually likes the choice to pick the ones he preferes. meillo@43: He has a reasonably modern system that complies to standards, meillo@43: like POSIX and ANSI C. meillo@27: .P meillo@43: XXX common scenarios? 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 meillo@43: mmh wants to provide a ready-to-use setup for modern emailing, meillo@43: which is a necessity to spread among new users.