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@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@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