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@47: 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@47: Further more, this chapter outlines the mmh project itself, meillo@47: describing the motivation for it and its goals. meillo@8: meillo@0: meillo@28: .H1 "MH \(en the Mail Handler meillo@0: .P meillo@47: MH is a conceptual email system design and its concrete implementation. meillo@47: Notably, MH had started as a design proposal at RAND Corporation, meillo@47: where the first implementation followed later. meillo@47: In spirit, MH 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@47: The 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@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@47: believed to be practically unusable. meillo@47: But the prototype had proven successful and replaced MS thereafter. meillo@47: In replacing MS, MH grew to an all-in-one mail system. meillo@2: .P meillo@47: In the early Eighties, meillo@47: the University of California at Irvine (UCI) had started to use MH. meillo@2: They also took over its development and pushed MH forward. meillo@47: Marshall T. Rose and John L. Romine became the driving force then. meillo@47: This was the time when the Internet appeared, when UCB implemented meillo@47: the TCP/IP stack, and when Allman wrote Sendmail. meillo@47: MH was extended as emailing became more featured. 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@47: In the Nineties, MH had been moved into the public domain, making it meillo@32: attractive to Free Software developers. meillo@47: The Internet had became popular and in December 1996, meillo@47: Richard Coleman initiated the ``New Mail Handler'' (nmh) project. meillo@47: The project is a fork of MH 6.8.3 and bases strongly on the meillo@47: \fILBL changes\fP by Van Jacobson, Mike Karels 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@47: The development of MH at UCI stopped after the 6.8.4 release in meillo@47: February 1996, soon after the development of nmh had started. meillo@32: Today, nmh almost completely replaced the original MH. meillo@47: Some systems might still provide old MH, but mainly for historical reasons. meillo@47: .P meillo@47: In the last years, the work on nmh was mostly maintenance work. meillo@47: However, the development revived in December 2011 and stayed busy since then. 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@47: set of tools, each covering a specific task of email handling, like meillo@47: composing a message, replying to a message, refiling a message to a meillo@47: different folder, listing the messages in a folder. meillo@47: All of the programs operate on a common mail storage. 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@47: received (i.e. transfer format). meillo@47: The files are named with ascending numbers in each folder. meillo@47: The specific format of the mail storage characterizes MH in the same way meillo@47: like the format of the file system characterizes Unix. meillo@42: .P meillo@47: MH tools maintain a \fIcontext\fP, which includes the current mail folder. 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@47: Messages are named by their numeric filename, but they can have symbolic names, meillo@47: too. These are either 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@47: Sequences can be bound to the containing folder or to the context. meillo@2: .P meillo@47: The user's \fIprofile\fP is a file that contains his MH configuration. meillo@47: Default switches for the individual tools can be specified to meillo@47: adjust them to the user's personal preferences. meillo@47: Multiple versions of the same command with different meillo@47: default values can also be created very easily. meillo@47: Form templates for new messages or for replies are easily changable, meillo@47: and output is adjustable with format files. meillo@47: Almost every part of the system can be adjusted to personal preference. meillo@42: .P meillo@32: The system is well scriptable and extendable. meillo@47: New MH tools are built out of or on top of existing ones quickly. meillo@47: Further more, MH encourages the user to taylor, extend and automate the system. 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@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@47: For backward-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@47: explicitely enabled. meillo@47: In consequence, the user needs to activate modern features explicitely meillo@47: to be able to use them. meillo@47: 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@47: But of course, this depends 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@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@47: 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@45: meillo@45: .H1 "This Thesis meillo@45: meillo@27: .U2 "Motivation 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@45: The mmh project is motivated by deficites of nmh and meillo@45: my wish for general changes, combined meillo@45: with the nmh community's reluctancy to change. meillo@45: .P meillo@45: nmh hadn't adjusted to modern emailing needs well enough. meillo@45: The default setup was completely unusable for modern emailing. meillo@45: Too much setup work was required. meillo@45: Several modern features were already available but the community meillo@45: didn't wanted to have them as default. meillo@45: mmh is a way to change this. meillo@45: .P meillo@45: In my eyes, MH's concepts could be exploited even better and meillo@45: the style of the tools could be improved. Both would simplify meillo@45: and generalize the system, providing cleaner interfaces and more meillo@45: software leverage, at the same time. meillo@45: mmh is a way to demonstrate this. meillo@45: .P meillo@45: In providing several parts of an email system, nmh can hardly meillo@45: compete with the large specialized projects that focus meillo@45: on only one of the components. meillo@45: The situation can be improved by concentrating the development power meillo@45: on the most unique part of MH and letting the user pick his prefered meillo@45: set of other mail components. meillo@45: Today's pre-packaged software components encourage this model. meillo@45: mmh is a way to go for this approach. meillo@45: .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@45: These reasons support the decision to start mmh as a fork of nmh. meillo@43: .P meillo@45: The mmh project provides the basis to implemented and demonstrated meillo@45: the listed ideas without the need to change nmh or its community. 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@45: Any effort needs to be targeted towards a specific goal meillo@45: in order to be successful. meillo@45: Following is a description of the imagined typical mmh user. meillo@45: mmh should satisfy his needs. meillo@45: .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@8: .P meillo@45: General assumptions of the project are: meillo@8: .BU meillo@45: Elegance \(en being simplicity, clarity and generality \(en is most important. meillo@8: .BU meillo@45: Concepts are more important than concrete implementations. meillo@8: .BU meillo@45: Time and space optimizations are only useful if absolutely needed to make meillo@45: the software usable. meillo@8: .BU meillo@45: Having a lot of choice is bad. meillo@8: meillo@27: .U2 "Work to do meillo@45: .P meillo@45: The general goals for the mmh project are the following: meillo@45: .BU meillo@45: mmh should be perfectly suited for modern emailing, out-of-the-box. meillo@45: This is a necessity to spread among new users. meillo@45: .BU meillo@45: The system shall be of-one-style. It should feel like cast as one. meillo@45: .P meillo@45: To do list: 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: .U2 "Methods meillo@27: .P meillo@27: foo