Mercurial > docs > master
changeset 107:9f672d3a25f9
Renamed the chapters to speaking names.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sat, 23 Jun 2012 22:12:14 +0200 |
| parents | 3c4e5f0a7e7b |
| children | dd5620bf8659 |
| files | ch01.roff ch03.roff ch04.roff discussion.roff intro.roff makefile summary.roff |
| diffstat | 7 files changed, 2938 insertions(+), 2938 deletions(-) [+] |
line wrap: on
line diff
--- a/ch01.roff Sat Jun 23 22:08:17 2012 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,394 +0,0 @@ -.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.
--- a/ch03.roff Sat Jun 23 22:08:17 2012 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,2527 +0,0 @@ -.H0 "Discussion -.P -This main chapter discusses the practical work done in the mmh project. -It is structured along the goals to achieve. -The concrete work done -is described in the examples of how the general goals were achieved. -The discussion compares the current version of mmh with the state of -nmh just before the mmh project started, i.e. Fall 2011. -Current changes of nmh will be mentioned only as side notes. -.\" XXX where do I discuss the parallel development of nmh? - - - -.H1 "Stream-Lining - -.P -MH had been considered an all-in-one system for mail handling. -The community around nmh has a similar understanding. -In fundamental difference, mmh shall be a MUA only. -I believe that the development of all-in-one mail systems is obsolete. -Today, email is too complex to be fully covered by single projects. -Such a project won't be able to excel in all aspects. -Instead, the aspects of email should be covered my multiple projects, -which then can be combined to form a complete system. -Excellent implementations for the various aspects of email exist already. -Just to name three examples: Postfix is a specialized MTA, -Procmail is a specialized MDA, and Fetchmail is a specialized MRA. -I believe that it is best to use such specialized tools instead of -providing the same function again as a side-component in the project. -.P -Doing something well, requires to focus on a small set of specific aspects. -Under the assumption that focused development produces better results -in the particular area, specialized projects will be superior -in their field of focus. -Hence, all-in-one mail system projects \(en no matter if monolithic -or modular \(en will never be the best choice in any of the fields. -Even in providing the best consistent all-in-one system they are likely -to be beaten by projects that focus only on integrating existing mail -components to a homogeneous system. -.P -The limiting resource in Free Software community development -is usually man power. -If the development power is spread over a large development area, -it becomes even more difficult to compete with the specialists in the -various fields. -The concrete situation for MH-based mail systems is even tougher, -given the small and aged community, including both developers and users, -it has. -.P -In consequence, I believe that the available development resources -should focus on the point where MH is most unique. -This is clearly the user interface \(en the MUA. -Peripheral parts should be removed to stream-line mmh for the MUA task. - - -.H2 "Mail Transfer Facilities -.P -In contrast to nmh, which also provides mail submission and mail retrieval -agents, mmh is a MUA only. -This general difference initiated the development of mmh. -Removing the mail transfer facilities had been the first work task -in the mmh project. -.P -Focusing on one mail agent role only is motivated by Eric Allman's -experience with Sendmail. -He identified limiting Sendmail the MTA task had be one reason for -its success: -.[ [ -costales sendmail -.], p. xviii] -.QS -Second, I limited myself to the routing function \(en -I wouldn't write user agents or delivery backends. -This was a departure of the dominant through of the time, -in which routing logic, local delivery, and often the network code -were incorporated directly into the user agents. -.QE -.P -In mmh, the Mail Submission Agent (MSA) is called -\fIMessage Transfer Service\fP (MTS). -This facility, implemented by the -.Pn post -command, established network connections and spoke SMTP to submit -messages for relay to the outside world. -The changes in email demanded changes in this part of nmh too. -Encryption and authentication for network connections -needed to be supported, hence TLS and SASL were introduced into nmh. -This added complexity to nmh without improving it in its core functions. -Also, keeping up with recent developments in the field of -mail transfer requires development power and specialists. -In mmh this whole facility was simply cut off. -.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226 -.Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3 -.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b -Instead, mmh depends on an external MSA. -The only outgoing interface available to mmh is the -.Pn sendmail -command, which almost any MSA provides. -If not, a wrapper program can be written. -It must read the message from the standard input, extract the -recipient addresses from the message header, and hand the message -over to the MSA. -For example, a wrapper script for qmail would be: -.VS -#!/bin/sh -# ignore command line arguments -exec qmail-inject -VE -The requirement to parse the recipient addresses out of the message header -is likely to be removed in the future. -Then mmh would give the recipient addresses as command line arguments. -This appears to be the better interface. -.\" XXX implement it -.P -To retrieve mail, the -.Pn inc -command acted as Mail Retrieval Agent (MRA). -It established network connections -and spoke POP3 to retrieve mail from remote servers. -As with mail submission, the network connections required encryption and -authentication, thus TLS and SASL were added. -Support for message retrieval through IMAP will become necessary -to be added soon, too, and likewise for any other changes in mail transfer. -Not so for mmh because it has dropped the support for retrieving mail -from remote locations. -.Ci ab7b48411962d26439f92f35ed084d3d6275459c -Instead, it depends on an external tool to cover this task. -In mmh exist two paths for messages to enter mmh's mail storage: -(1) Mail can be incorporated with -.Pn inc -from the system maildrop, or (2) with -.Pn rcvstore -by reading them, one at a time, from the standard input. -.P -With the removal of the MSA and MRA, mmh converted from an all-in-one -mail system to being a MUA only. -Now, of course, mmh depends on third-party software. -An external MSA is required to transfer mail to the outside world; -an external MRA is required to retrieve mail from remote machines. -There exist excellent implementations of such software, -which do this specific task likely better than the internal -versions had done it. -Also, the best suiting programs can be freely chosen. -.P -As it had already been possible to use an external MSA or MRA, -why not keep the internal version for convenience? -The question whether there is sense in having a fall-back pager in all -the command line tools, for the cases when -.Pn more -or -.Pn less -aren't available, appears to be ridiculous. -Of course, MSAs and MRAs are more complex than text pagers -and not necessarily available but still the concept of orthogonal -design holds: ``Write programs that do one thing and do it well.'' -.[ -mcilroy unix phil -p. 53 -.] -.[ -mcilroy bstj foreword -.] -Here, this part of the Unix philosophy was applied not only -to the programs but to the project itself. -In other words: -``Develop projects that focus on one thing and do it well.'' -Projects grown complex should be split for the same reasons programs grown -complex should be split. -If it is conceptionally more elegant to have the MSA and MRA as -separate projects then they should be separated. -This is the case here, in my opinion. -The RFCs propose this separation by clearly distinguishing the different -mail handling tasks. -.[ -rfc 821 -.] -The small interfaces between the mail agents support the separation. -.P -In the beginning, email had been small and simple. -At that time, -.Pn /bin/mail -had covered anything there was to email and still had been small -and simple. -Later, the essential complexity of email increased. -(Essential complexity is the complexity defined by the problem itself.\0 -.[[ -brooks no silver bullet -.]]) -Email systems reacted to this change: They grew. -RFCs started to introduce the concept of mail agents to separate the -various tasks because they became more extensive and new tasks appeared. -As the mail systems grew even more, parts were split off. -In nmh, for instance, the POP server, which was included in the original -MH, was removed. -Now is the time to go one step further and split the MSA and MRA off, too. -Not only does this decrease the code size of the project, -but, more important, it unburdens mmh of the whole field of -message transfer with all its implications for the project. -There is no more need to concern with changes in network transfer. -This independence is received by depending on an external program -that covers the field. -Today, this is a reasonable exchange. -.P -Functionality can be added in three different ways: -.BU -Implementing the function originally in the project. -.BU -Depending on a library that provides the function. -.BU -Depending on a program that provides the function. -.P -Whereas adding the function originally to the project increases the -code size most and requires most maintenance and development work, -it makes the project most independent of other software. -Using libraries or external programs require less maintenance work -but introduces dependencies on external software. -Programs have the smallest interfaces and provide the best separation -but possibly limit the information exchange. -External libraries are stronger connected than external programs, -thus information can be exchanged more flexible. -Adding code to a project increases maintenance work. -.\" XXX ref -Implementing complex functions originally in the project adds -a lot of code. -This should be avoided if possible. -Hence, the dependencies only change in kind, not in their existence. -In mmh, library dependencies on -.Pn libsasl2 -and -.Pn libcrypto /\c -.Pn libssl -were treated against program dependencies on an MSA and an MRA. -This also meant treating build-time dependencies against run-time -dependencies. -Besides program dependencies providing the stronger separation -and being more flexible, they also allowed -over 6\|000 lines of code to be removed from mmh. -This made mmh's code base about 12\|% smaller. -Reducing the project's code size by such an amount without actually -losing functionality is a convincing argument. -Actually, as external MSAs and MRAs are likely superior to the -project's internal versions, the common user even gains functionality. -.P -Users of MH should not have problems to set up an external MSA and MRA. -Also, the popular MSAs and MRAs have large communities and a lot -of documentation available. -Choices for MSAs range from full-featured MTAs like -.I Postfix -over mid-size MTAs like -.I masqmail -and -.I dma -to small forwarders like -.I ssmtp -and -.I nullmailer . -Choices for MRAs include -.I fetchmail , -.I getmail , -.I mpop -and -.I fdm . - - -.H2 "Non-MUA Tools -.P -One goal of mmh is to remove the tools that are not part of the MUA's task. -Further more, any tools that don't improve the MUA's job significantly -should be removed. -Loosely related and rarely used tools distract from the lean appearance. -They require maintenance work without adding much to the core task. -By removing these tools, the project shall become more stream-lined -and focused. -In mmh the following tools are not available anymore: -.BU -.Pn conflict -was removed -.Ci 8b235097cbd11d728c07b966cf131aa7133ce5a9 -because it is a mail system maintenance tool that is not MUA-related. -It even checked -.Fn /etc/passwd -and -.Fn /etc/group -for consistency, which is completely unrelated to email. -A tool like -.Pn conflict -is surely useful, but it should not be shipped with mmh. -.\" XXX historic reasons? -.BU -.Pn rcvtty -was removed -.Ci 14767c94b3827be7c867196467ed7aea5f6f49b0 -because its use case of writing to the user's terminal -on receiving of mail is obsolete. -If users like to be informed of new mail, the shell's -.Ev MAILPATH -variable or graphical notifications are technically more appealing. -Writing directly to terminals is hardly ever wanted today. -If though one wants to have it this way, the standard tool -.Pn write -can be used in a way similar to: -.VS -scan -file - | write `id -un` -VE -.BU -.Pn viamail -was removed -.Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932 -when the new attachment system was activated, because -.Pn forw -could then cover the task itself. -The program -.Pn sendfiles -was rewritten as a shell script wrapper around -.Pn forw . -.Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6 -.BU -.Pn msgchk -was removed -.Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe , -because it lost its use case when POP support was removed. -A call to -.Pn msgchk -provided hardly more information than: -.VS -ls -l /var/mail/meillo -VE -It did distinguish between old and new mail, but -this detail information can be retrieved with -.Pn stat (1), -too. -A small shell script could be written to print the information -in a similar way, if truly necessary. -As mmh's -.Pn inc -only incorporates mail from the user's local maildrop, -and thus no data transfers over slow networks are involved, -there's hardly any need to check for new mail before incorporating it. -.BU -.Pn msh -was removed -.Ci 916690191222433a6923a4be54b0d8f6ac01bd02 -because the tool was in conflict with the philosophy of MH. -It provided an interactive shell to access the features of MH, -but it wasn't just a shell, tailored to the needs of mail handling. -Instead it was one large program that had several MH tools built in. -This conflicts with the major feature of MH of being a tool chest. -.Pn msh 's -main use case had been accessing Bulletin Boards, which have seized to -be popular. -.P -Removing -.Pn msh , -together with the truly archaic code relicts -.Pn vmh -and -.Pn wmh , -saved more than 7\|000 lines of C code \(en -about 15\|% of the project's original source code amount. -Having less code \(en with equal readability, of course \(en -for the same functionality is an advantage. -Less code means less bugs and less maintenance work. -As -.Pn rcvtty -and -.Pn msgchk -are assumed to be rarely used and can be implemented in different ways, -why should one keep them? -Removing them stream-lines mmh. -.Pn viamail 's -use case is now partly obsolete and partly covered by -.Pn forw , -hence there's no reason to still maintain it. -.Pn conflict -is not related to the mail client, and -.Pn msh -conflicts with the basic concept of MH. -Theses two tools might still be useful, but they should not be part of mmh. -.P -Finally, there's -.Pn slocal . -.Pn slocal -is an MDA and thus not directly MUA-related. -It should be removed from mmh, because including it conflicts with -the idea that mmh is a MUA only. -.Pn slocal -should rather become a separate project. -However, -.Pn slocal -provides rule-based processing of messages, like filing them into -different folders, which is otherwise not available in mmh. -Although -.Pn slocal -does neither pull in dependencies nor does it include a separate -technical area (cf. Sec. XXX), still, -it accounts for about 1\|000 lines of code that need to be maintained. -As -.Pn slocal -is almost self-standing, it should be split off into a separate project. -This would cut the strong connection between the MUA mmh and the MDA -.Pn slocal . -For anyone not using MH, -.Pn slocal -would become yet another independent MDA, like -.I procmail . -Then -.Pn slocal -could be installed without the complete MH system. -Likewise, mmh users could decide to use -.I procmail -without having a second, unused MDA, -.Pn slocal , -installed. -That appears to be conceptionally the best solution. -Yet, -.Pn slocal -is not split off. -I defer the decision over -.Pn slocal -in need for deeper investigation. -In the meanwhile, it remains part of mmh. -That does not hurt because -.Pn slocal -is unrelated to the rest of the project. - - -.H2 "\fLshow\fP and \fPmhshow\fP -.P -Since the very beginning \(en already in the first concept paper \(en -.Pn show -had been MH's message display program. -.Pn show -mapped message numbers and sequences to files and invoked -.Pn mhl -to have the files formatted. -With MIME, this approach wasn't sufficient anymore. -MIME messages can consist of multiple parts. Some parts are not -directly displayable and text content might be encoded in -foreign charsets. -.Pn show 's -understanding of messages and -.Pn mhl 's -display capabilities couldn't cope with the task any longer. -.P -Instead of extending these tools, additional tools were written from -scratch and added to the MH tool chest. -Doing so is encouraged by the tool chest approach. -Modular design is a great advantage for extending a system, -as new tools can be added without interfering with existing ones. -First, the new MIME features were added in form of the single program -.Pn mhn . -The command -.Cl "mhn -show 42 -would show the MIME message numbered 42. -With the 1.0 release of nmh in February 1999, Richard Coleman finished -the split of -.Pn mhn -into a set of specialized tools, which together covered the -multiple aspects of MIME. -One of them was -.Pn mhshow , -which replaced -.Cl "mhn -show" . -It was capable of displaying MIME messages appropriately. -.P -From then on, two message display tools were part of nmh, -.Pn show -and -.Pn mhshow . -To ease the life of users, -.Pn show -was extended to automatically hand the job over to -.Pn mhshow -if displaying the message would be beyond -.Pn show 's -abilities. -In consequence, the user would simply invoke -.Pn show -(possibly through -.Pn next -or -.Pn prev ) -and get the message printed with either -.Pn show -or -.Pn mhshow , -whatever was more appropriate. -.P -Having two similar tools for essentially the same task is redundant. -Usually, -users wouldn't distinguish between -.Pn show -and -.Pn mhshow -in their daily mail reading. -Having two separate display programs was therefore mainly unnecessary -from a user's point of view. -Besides, the development of both programs needed to be in sync, -to ensure that the programs behaved in a similar way, -because they were used like a single tool. -Different behavior would have surprised the user. -.P -Today, non-MIME messages are rather seen to be a special case of -MIME messages, although it is the other way round. -As -.Pn mhshow -had already be able to display non-MIME messages, it appeared natural -to drop -.Pn show -in favor of using -.Pn mhshow -exclusively. -.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853 -Removing -.Pn show -is no loss in function, because functionally -.Pn mhshow -covers it completely. -The old behavior of -.Pn show -can still be emulated with the simple command line: -.VS -mhl `mhpath c` -VE -.P -For convenience, -.Pn mhshow -was renamed to -.Pn show -after -.Pn show -was gone. -It is clear that such a rename may confuse future developers when -trying to understand the history. -Nevertheless, I consider the convenience on the user's side, -to call -.Pn show -when they want a message to be displayed, to outweigh the inconvenience -on the developer's side when understanding the project history. -.P -To prepare for the transition, -.Pn mhshow -was reworked to behave more like -.Pn show -first. -(cf. Sec. XXX) -Once the tools behaved more alike, the replacing appeared to be -even more natural. -Today, mmh's new -.Pn show -became the one single message display program again, with the difference -that today it handles MIME messages as well as non-MIME messages. -The outcome of the transition is one program less to maintain, -no second display program for users to deal with, -and less system complexity. -.P -Still, removing the old -.Pn show -hurts in one regard: It had been such a simple program. -Its lean elegance is missing to the new -.Pn show . -But there is no chance; -supporting MIME demands for higher essential complexity. - - -.H2 "Configure Options -.P -Customization is a double-edged sword. -It allows better suiting setups, but not for free. -There is the cost of code complexity to be able to customize. -There is the cost of less tested setups, because there are -more possible setups and especially corner-cases. -And, there is the cost of choice itself. -The code complexity directly affects the developers. -Less tested code affects both, users and developers. -The problem of choice affects the users, for once by having to -choose, but also by more complex interfaces that require more documentation. -Whenever options add little advantages, they should be considered for -removal. -I have reduced the number of project-specific configure options from -fifteen to three. - -.U3 "Mail Transfer Facilities -.P -With the removal of the mail transfer facilities five configure -options vanished: -.P -The switches -.Sw --with-tls -and -.Sw --with-cyrus-sasl -had activated the support for transfer encryption and authentication. -This is not needed anymore. -.Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3 -.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b -.P -The configure switch -.Sw --enable-pop -activated the message retrieval facility. -The code area that would be conditionally compiled in for TLS and SASL -support had been small. -The conditionally compiled code area for POP support had been much larger. -Whereas the code base changes would only slightly change on toggling -TLS or SASL support, it changed much on toggling POP support. -The changes in the code base could hardly be overviewed. -By having POP support togglable a second code base had been created, -one that needed to be tested. -This situation is basically similar for the conditional TLS and SASL -code, but there the changes are minor and can yet be overviewed. -Still, conditional compilation of a code base creates variations -of the original program. -More variations require more testing and maintenance work. -.P -Two other options only specified default configuration values: -.Sw --with-mts -defined the default transport service, either -.Ar smtp -or -.Ar sendmail . -In mmh this fixed to -.Ar sendmail . -.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226 -With -.Sw --with-smtpservers -default SMTP servers for the -.Ar smtp -transport service could be specified. -.Ci 128545e06224233b7e91fc4c83f8830252fe16c9 -Both of them became irrelevant. - -.U3 "Backup Prefix -.P -The backup prefix is the string that was prepended to message -filenames to tag them as deleted. -By default it had been the comma character `\f(CW,\fP'. -In July 2000, Kimmo Suominen introduced -the configure option -.Sw --with-hash-backup -to change the default to the hash symbol `\f(CW#\fP'. -The choice was probably personal preference, because first, the -option was named -.Sw --with-backup-prefix. -and had the prefix symbol as argument. -But giving the hash symbol as argument caused too many problems -for Autoconf, -thus the option was limited to use the hash symbol as the default prefix. -This supports the assumption, that the choice for the hash was -personal preference only. -Being related or not, words that start with the hash symbol -introduce a comment in the Unix shell. -Thus, the command line -.Cl "rm #13 #15 -calls -.Pn rm -without arguments because the first hash symbol starts the comment -that reaches until the end of the line. -To delete the backup files, -.Cl "rm ./#13 ./#15" -needs to be used. -Using the hash as backup prefix can be seen as a precaution against -data loss. -.P -I removed the configure option but added the profile entry -.Pe backup-prefix , -which allows to specify an arbitrary string as backup prefix. -.Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086 -Profile entries are the common method to change mmh's behavior. -This change did not remove the choice but moved it to a location where -it suited better. -.P -Eventually, however, the new trash folder concept -.Cf "Sec. XXX -obsoleted the concept of the backup prefix completely. -.Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173 -.\" (Well, there still are corner-cases to remove until the backup -.\" prefix can be laid to rest, eventually.) -.\" FIXME: Do this work in the code! - -.U3 "Editor and Pager -.P -The two configure options -.CW --with-editor=EDITOR -.CW --with-pager=PAGER -were used to specify the default editor and pager at configure time. -Doing so at configure time made sense in the Eighties, -when the set of available editors and pagers varied much across -different systems. -Today, the situation is more homogeneous. -The programs -.Pn vi -and -.Pn more -can be expected to be available on every Unix system, -as they are specified by POSIX since two decades. -(The specifications for -.Pn vi -and -.Pn more -appeared in -.[ -posix 1987 -.] -and, -.[ -posix 1992 -.] -respectively.) -As a first step, these two tools were hard-coded as defaults. -.Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f -Not changed were the -.Pe editor -and -.Pe moreproc -profile entries, which allowed the user to override the system defaults. -Later, the concept was reworked to respect the standard environment -variables -.Ev VISUAL -and -.Ev PAGER -if they are set. -Today, mmh determines the editor to use in the following order, -taking the first available and non-empty item: -.IP (1) -Environment variable -.Ev MMHEDITOR -.IP (2) -Profile entry -.Pe Editor -.IP (3) -Environment variable -.Ev VISUAL -.IP (4) -Environment variable -.Ev EDITOR -.IP (5) -Command -.Pn vi . -.P -.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b -.P -The pager to use is determined in a similar order, -also taking the first available and non-empty item: -.IP (1) -Environment variable -.Ev MMHPAGER -.IP (2) -Profile entry -.Pe Pager -(replaces -.Pe moreproc ) -.IP (3) -Environment variable -.Ev PAGER -.IP (4) -Command -.Pn more . -.P -.Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e -.P -By respecting the -.Ev VISUAL /\c -.Ev EDITOR -and -.Ev PAGER -environment variables, -the new behavior confirms better to the common style on Unix systems. -Additionally, the new approach is more uniform and clearer to users. - - -.U3 "ndbm -.P -.Pn slocal -used to depend on -.I ndbm , -a database library. -The database is used to store the `\fLMessage-ID\fP's of all -messages delivered. -This enables -.Pn slocal -to suppress delivering the same message to the same user twice. -(This features was enabled by the -.Sw -suppressdup -switch.) -.P -A variety of versions of the database library exist. -.[ -wolter unix incompat notes dbm -.] -Complicated autoconf code was needed to detect them correctly. -Further more, the configure switches -.Sw --with-ndbm=ARG -and -.Sw --with-ndbmheader=ARG -were added to help with difficult setups that would -not be detected automatically or correctly. -.P -By removing the suppress duplicates feature of -.Pn slocal , -the dependency on -.I ndbm -vanished and 120 lines of complex autoconf code could be saved. -.Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf -The change removed functionality too, but that is minor to the -improvement by dropping the dependency and the complex autoconf code. - -.U3 "mh-e Support -.P -The configure option -.Sw --disable-mhe -was removed when the mh-e support was reworked. -Mh-e is the Emacs front-end to MH. -It requires MH to provide minor additional functions. -The -.Sw --disable-mhe -configure option could switch these extensions off. -After removing the support for old versions of mh-e, -only the -.Sw -build -switches of -.Pn forw -and -.Pn repl -are left to be mh-e extensions. -They are now always built in because they add little code and complexity. -In consequence, the -.Sw --disable-mhe -configure option was removed -.Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643 -Removing the option removed a second code setup that would have -needed to be tested. -This change was first done in nmh and thereafter merged into mmh. -.P -The interface changes in mmh require mh-e to be adjusted in order -to be able to use mmh as back-end. -This will require minor changes to mh-e, but removing the -.Sw -build -switches would require more rework. - -.U3 "Masquerading -.P -The configure option -.Sw --enable-masquerade -could take up to three arguments: -`draft_from', `mmailid', and `username_extension'. -They activated different types of address masquerading. -All of them were implemented in the SMTP-speaking -.Pn post -command, which provided an MSA. -Address masquerading is an MTA's task and mmh does not cover -this field anymore. -Hence, true masquerading needs to be implemented in the external MTA. -.P -The -.I mmailid -masquerading type is the oldest one of the three and the only one -available in the original MH. -It provided a -.I username -to -.I fakeusername -mapping, based on the password file's GECOS field. -The man page -.Mp mh-tailor(5) -described the use case as being the following: -.QS -This is useful if you want the messages you send to always -appear to come from the name of an MTA alias rather than your -actual account name. For instance, many organizations set up -`First.Last' sendmail aliases for all users. If this is -the case, the GECOS field for each user should look like: -``First [Middle] Last <First.Last>'' -.QE -.P -As mmh sends outgoing mail via the local MTA only, -the best location to do such global rewrites is there. -Besides, the MTA is conceptionally the right location because it -does the reverse mapping for incoming mail (aliasing), too. -Further more, masquerading set up there is readily available for all -mail software on the system. -Hence, mmailid masquerading was removed. -.Ci 0836c8000ccb34b59410ef1c15b1b7feac70ce5f -.P -The -.I username_extension -masquerading type did not replace the username but would append a suffix, -specified by the -.Ev USERNAME_EXTENSION -environment variable, to it. -This provided support for the -.I user-extension -feature of qmail and the similar -.I "plussed user -processing of sendmail. -The decision to remove this username_extension masquerading was -motivated by the fact that -.Pn spost -hadn't supported it already. -.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9 -Username extensions are possible in mmh, but less convenient to use. -.\" XXX format file %(getenv USERNAME_EXTENSION) -.P -The -.I draft_from -masquerading type instructed -.Pn post -to use the value of the -.Hd From -header field as SMTP envelope sender. -Sender addresses could be replaced completely. -.Ci b14ea6073f77b4359aaf3fddd0e105989db9 -Mmh offers a kind of masquerading similar in effect, but -with technical differences. -As mmh does not transfer messages itself, the local MTA has final control -over the sender's address. Any masquerading mmh introduces may be reverted -by the MTA. -In times of pedantic spam checking, an MTA will take care to use -sensible envelope sender addresses to keep its own reputation up. -Nonetheless, the MUA can set the -.Hd From -header field and thereby propose -a sender address to the MTA. -The MTA may then decide to take that one or generate the canonical sender -address for use as envelope sender address. -.P -In mmh, the MTA will always extract the recipient and sender from the -message header (\c -.Pn sendmail 's -.Sw -t -switch). -The -.Hd From -header field of the draft may be set arbitrary by the user. -If it is missing, the canonical sender address will be generated by the MTA. - -.U3 "Remaining Options -.P -Two configure options remain in mmh. -One is the locking method to use: -.Sw --with-locking=[dot|fcntl|flock|lockf] . -The idea of removing all methods except the portable dot locking -and having that one as the default is appealing, but this change -requires deeper technical investigation into the topic. -The other option, -.Sw --enable-debug , -compiles the programs with debugging symbols and does not strip them. -This option is likely to stay. - - - - -.H2 "Command Line Switches -.P -The command line switches of MH tools follow the X Window style. -They are words, introduced by a single dash. -For example: -.Cl "-truncate" . -Every program in mmh has two generic switches: -.Sw -help , -to print a short message on how to use the program, and -.Sw -Version , -to tell what version of mmh the program belongs to. -.P -Switches change the behavior of programs. -Programs that do one thing in one way require no switches. -In most cases, doing something in exactly one way is too limiting. -If there is basically one task to accomplish, but it should be done -in various ways, switches are a good approach to alter the behavior -of a program. -Changing the behavior of programs provides flexibility and customization -to users, but at the same time it complicates the code, documentation and -usage of the program. -.\" XXX: Ref -Therefore, the number of switches should be kept small. -A small set of well-chosen switches does no harm. -But usually, the number of switches increases over time. -Already in 1985, Rose and Romine have identified this as a major -problem of MH: -.[ [ -rose romine real work -.], p. 12] -.QS -A complaint often heard about systems which undergo substantial development -by many people over a number of years, is that more and more options are -introduced which add little to the functionality but greatly increase the -amount of information a user needs to know in order to get useful work done. -This is usually referred to as creeping featurism. -.QP -Unfortunately MH, having undergone six years of off-and-on development by -ten or so well-meaning programmers (the present authors included), -suffers mightily from this. -.QE -.P -Being reluctant to adding new switches \(en or `options', -as Rose and Romine call them \(en is one part of a counter-action, -the other part is removing hardly used switches. -Nmh's tools had lots of switches already implemented, -hence, cleaning up by removing some of them was the more important part -of the counter-action. -Removing existing functionality is always difficult because it -breaks programs that use these functions. -Also, for every obsolete feature, there'll always be someone who still -uses it and thus opposes its removal. -This puts the developer into the position, -where sensible improvements to style are regarded as destructive acts. -Yet, living with the featurism is far worse, in my eyes, because -future needs will demand adding further features, -worsening the situation more and more. -Rose and Romine added in a footnote, -``[...] -.Pn send -will no doubt acquire an endless number of switches in the years to come.'' -Although clearly humorous, the comment points to the nature of the problem. -Refusing to add any new switches would encounter the problem at its root, -but this is not practical. -New needs will require new switches and it would be unwise to block -them strictly. -Nevertheless, removing obsolete switches still is an effective approach -to deal with the problem. -Working on an experimental branch without an established user base, -eased my work because I did not offend users when I removed existing -funtions. -.P -Rose and Romine counted 24 visible and 9 more hidden switches for -.Pn send . -In nmh, they increased up to 32 visible and 12 hidden ones. -At the time of writing, no more than 7 visible switches and 1 hidden switch -have remained in mmh's -.Pn send . -(These numbers include two generic switches, help and version.) -.P -Fig. XXX -.\" XXX Ref -displays the number of switches for each of the tools that is available -in both, nmh and mmh. -The tools are sorted by the number of switches they had in nmh. -Visible and hidden switches were counted, -but not the generic help and version switches. -Whereas in the beginning of the project, the average tool had 11 switches, -now it has no more than 5 \(en only half as many. -If the `no' switches and similar inverse variant are folded onto -their counter-parts, the average tool had 8 switches in pre-mmh times and -has 4 now. -The total number of functional switches in mmh dropped from 465 -to 234. - -.KS -.in 1c -.so input/switches.grap -.KE - -.P -A part of the switches vanished after functions were removed. -This was the case for network mail transfer, for instance. -Sometimes, however, the work flow was the other way: -I looked through the -.Mp mh-chart (7) -man page to identify the tools with apparently too many switches. -Then considering the value of each of the switches by examining -the tool's man page and source code, aided by recherche and testing. -This way, the removal of functions was suggested by the aim to reduce -the number of switches per command. - - -.U3 "Draft Folder Facility -.P -A change early in the project was the complete transition from -the single draft message to the draft folder facility. -.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 -The draft folder facility was introduced in the mid-Eighties, when -Rose and Romine called it a ``relatively new feature''. -.[ -rose romine real work -.] -Since then, the facility had existed but was deactivated by default. -The default activation and the related rework of the tools made it -possible to remove the -.Sw -[no]draftfolder , -and -.Sw -draftmessage -switches from -.Pn comp , -.Pn repl , -.Pn forw , -.Pn dist , -.Pn whatnow , -and -.Pn send . -.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 -The only flexibility removed with this change is having multiple -draft folders within one profile. -I consider this a theoretical problem only. -In the same go, the -.Sw -draft -switch of -.Pn anno , -.Pn refile , -and -.Pn send -was removed. -The special-casing of `the' draft message became irrelevant after -the rework of the draft system. -(See Sec. XXX.) -Equally, -.Pn comp -lost its -.Sw -file -switch. -The draft folder facility, together with the -.Sw -form -switch, are sufficient. - - -.U3 "In Place Editing -.P -.Pn anno -had the switches -.Sw -[no]inplace -to either annotate the message in place and thus preserve hard links, -or annotate a copy to replace the original message, breaking hard links. -Following the assumption that linked messages should truly be the -same message, and annotating it should not break the link, the -.Sw -[no]inplace -switches were removed and the previous default -.Sw -inplace -was made the only behavior. -.Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0 -The -.Sw -[no]inplace -switches of -.Pn repl , -.Pn forw , -and -.Pn dist -could be removed, too, as they were simply passed through to -.Pn anno . -.P -.Pn burst -also had -.Sw -[no]inplace -switches, but with different meaning. -With -.Sw -inplace , -the digest had been replaced by the table of contents (i.e. the -introduction text) and the bursted messages were placed right -after this message, renumbering all following messages. -Also, any trailing text of the digest was lost, though, -in practice, it usually consists of an end-of-digest marker only. -Nontheless, this behavior appeared less elegant than the -.Sw -noinplace -behavior, which already had been the default. -Nmh's -.Mp burst (1) -man page reads: -.sp \n(PDu -.QS -If -noinplace is given, each digest is preserved, no table -of contents is produced, and the messages contained within -the digest are placed at the end of the folder. Other messages -are not tampered with in any way. -.QE -.LP -The decision to drop the -.Sw -inplace -behavior was supported by the code complexity and the possible data loss -it caused. -.Sw -noinplace -was chosen to be the definitive behavior. -.Ci 68a686adeb39223a5e1ad35e4a24890ec053679d - - -.U3 "Forms and Format Strings -.P -Historically, the tools that had -.Sw -form -switches to supply a form file had -.Sw -format -switches as well to supply the contents of a form file as a string -on the command line directly. -In consequence, the following two lines equaled: -.VS -scan -form scan.mailx -scan -format "`cat .../scan.mailx`" -VE -The -.Sw -format -switches were dropped in favor for extending the -.Sw -form -switches. -.Ci f51956be123db66b00138f80464d06f030dbb88d -If their argument starts with an equal sign (`='), -then the rest of the argument is taken as a format string, -otherwise the arguments is treated as the name of a format file. -Thus, now the following two lines equal: -.VS -scan -form scan.mailx -scan -form "=`cat .../scan.mailx`" -VE -This rework removed the prefix collision between -.Sw -form -and -.Sw -format . -Now, typing -.Sw -fo -suffices to specify form or format string. -.P -The different meaning of -.Sw -format -for -.Pn repl -and -.Pn forw -was removed in mmh. -.Pn forw -was completely switched to MIME-type forwarding, thus removing the -.Sw -[no]format . -.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1 -For -.Pn repl , -the -.Sw -[no]format -switches were reworked to -.Sw -[no]filter -switches. -.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6 -The -.Sw -format -switches of -.Pn send -and -.Pn post , -which had a third meaning, -were removed likewise. -.Ci f3cb7cde0e6f10451b6848678d95860d512224b9 -Eventually, the ambiguity of the -.Sw -format -switches was resolved by not anymore having any such switch in mmh. - - -.U3 "MIME Tools -.P -The MIME tools, which were once part of -.Pn mhn -[sic!], -had several switches that added little practical value to the programs. -The -.Sw -[no]realsize -switches of -.Pn mhbuild -and -.Pn mhlist -were removed, doing real size calculations always now -.Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c , -as -``This provides an accurate count at the expense of a small delay.'' -This small delay is not noticable on modern systems. -.P -The -.Sw -[no]check -switches were removed together with the support for -.Hd Content-MD5 -header fields. -.[ -rfc 1864 -.] -.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda -(See Sec. XXX) -.P -The -.Sw -[no]ebcdicsafe -and -.Sw -[no]rfc934mode -switches of -.Pn mhbuild -were removed because they are considered obsolete. -.Ci 01a3480928da485b4d6109d36d751dfa71799d58 -.Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88 -.P -Content caching of external MIME parts, activated with the -.Sw -rcache -and -.Sw -wcache -switches was completely removed. -.Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269 -External MIME parts are rare today, having a caching facility -for them is appears to be unnecessary. -.P -In pre-MIME times, -.Pn mhl -had covered many tasks that are part of MIME handling today. -Therefore, -.Pn mhl -could be simplified to a large extend, reducing the number of its -switches from 21 to 6. -.Ci 350ad6d3542a07639213cf2a4fe524e829c1e7b6 -.Ci 0e46503be3c855bddaeae3843e1b659279c35d70 - - -.U3 "Mail Transfer Switches -.P -With the removal of the mail transfer facilities, a lot of switches -vanished automatically. -.Pn inc -lost 9 switches, namely -.Sw -host , -.Sw -port , -.Sw -user , -.Sw -proxy , -.Sw -snoop , -.Sw -[no]pack , -as well as -.Sw -sasl -and -.Sw -saslmech . -.Pn send -and -.Pn post -lost 11 switches each, namely -.Sw -server , -.Sw -port , -.Sw -client , -.Sw -user , -.Sw -mail , -.Sw -saml , -.Sw -send , -.Sw -soml , -.Sw -snoop , -as well as -.Sw -sasl , -.Sw -saslmech , -and -.Sw -tls . -.Pn send -had the switches only to pass them further to -.Pn post , -because the user would invoke -.Pn post -not directly, but through -.Pn send . -All these switches, except -.Sw -snoop -were usually defined as default switches in the user's profile, -but hardly given in interactive usage. -.P -Of course, those switches did not really ``vanish'', but the configuration -they did was handed over to external MSAs and MRAs. -Instead of setting up the mail transfer in mmh, it is set up in -external tools. -Yet, this simplifies mmh. -Specialized external tools will likely have simple configuration files. -Hence, instead of having one complicated central configuration file, -the configuration of each domain is separate. -Although the user needs to learn to configure each of the tools, -each configuration is likely much simpler. - - -.U3 "Maildrop Formats -.P -With the removal of MMDF maildrop format support, -.Pn packf -and -.Pn rcvpack -no longer needed their -.Sw -mbox -and -.Sw -mmdf -switches. -.Sw -mbox -is the sole behavior now. -.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0 -In the same go, -.Pn packf -and -.Pn rcvpack -were reworked (see Sec. XXX) and their -.Sw -file -switch became unnecessary. -.Ci ca1023716d4c2ab890696f3e41fa0d94267a940e - - -.U3 "Terminal Magic -.P -Mmh's tools will no longer clear the screen (\c -.Pn scan 's -and -.Pn mhl 's -.Sw -[no]clear -switches -.Ci e57b17343dcb3ff373ef4dd089fbe778f0c7c270 -.Ci 943765e7ac5693ae177fd8d2b5a2440e53ce816e ). -Neither will -.Pn mhl -ring the bell (\c -.Sw -[no]bell -.Ci e11983f44e59d8de236affa5b0d0d3067c192e24 ) -nor page the output itself (\c -.Sw -length -.Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ). -.P -Generally, the pager to use is no longer specified with the -.Sw -[no]moreproc -command line switches for -.Pn mhl -and -.Pn show /\c -.Pn mhshow . -.Ci 39e87a75b5c2d3572ec72e717720b44af291e88a -.P -.Pn prompter -lost its -.Sw -erase -and -.Sw -kill -switches because today the terminal cares for the line editing keys. - - -.U3 "Header Printing -.P -.Pn folder 's -data output is self-explaining enough that -displaying the header line makes few sense. -Hence, the -.Sw -[no]header -switch was removed and headers are never printed. -.Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7 -.P -In -.Pn mhlist , -the -.Sw -[no]header -switches were removed, too. -.Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f -But in this case headers are always printed, -because the output is not self-explaining. -.P -.Pn scan -also had -.Sw -[no]header -switches. -Printing the header had been sensible until the introduction of -format strings made it impossible to display the column headings. -Only the folder name and the current date remained to be printed. -As this information can be perfectly retrieved by -.Pn folder -and -.Pn date , -consequently, the switches were removed. -.Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e -.P -By removing all -.Sw -header -switches, the collision with -.Sw -help -on the first two letters was resolved. -Currently, -.Sw -h -evaluates to -.Sw -help -for all tools of mmh. - - -.U3 "Suppressing Edits or the WhatNow Shell -.P -The -.Sw -noedit -switch of -.Pn comp , -.Pn repl , -.Pn forw , -.Pn dist , -and -.Pn whatnow -was removed, but it can now be replaced by specifying -.Sw -editor -with an empty argument. -.Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9 -(Specifying -.Cl "-editor true -is nearly the same, only differing by the previous editor being set.) -.P -The more important change is the removal of the -.Sw -nowhatnowproc -switch. -.Ci ee4f43cf2ef0084ec698e4e87159a94c01940622 -This switch had introduced an awkward behavior, as explained in nmh's -man page for -.Mp comp (1): -.QS -The \-editor editor switch indicates the editor to use for -the initial edit. Upon exiting from the editor, comp will -invoke the whatnow program. See whatnow(1) for a discussion -of available options. The invocation of this program can be -inhibited by using the \-nowhatnowproc switch. (In truth of -fact, it is the whatnow program which starts the initial -edit. Hence, \-nowhatnowproc will prevent any edit from -occurring.) -.QE -.P -Effectively, the -.Sw -nowhatnowproc -switch creates only a draft message. -As -.Cl "-whatnowproc true -causes the same behavior, the -.Sw -nowhatnowproc -switch was removed for being redundant. -Likely, the -.Sw -nowhatnowproc -switch was intended to be used by front-ends. - - -.U3 "Compatibility Switches -.BU -The hidden -.Sw -[no]total -switches of -.Pn flist . -They were simply the inverse of the visible -.Sw -[no]fast -switches: -.Sw -total -was -.Sw -nofast -and -.Sw -nototal -was -.Sw -fast . -I removed the -.Sw -[no]total -legacy. -.Ci ea21fe2c4bd23c639bef251398fae809875732ec -.BU -The -.Sw -subject -switch of -.Pn sortm -existed for compatibility only. -It can be fully replaced by -.Cl "-textfield subject -thus it was removed. -.Ci 00140a3c86e9def69d98ba2ffd4d6e50ef6326ea - - -.U3 "Various -.BU -In order to avoid prefix collisions among switch names, the -.Sw -version -switch was renamed to -.Sw -Version -(with capital `V'). -.Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a -Every program has the -.Sw -version -switch but its first three letters collided with the -.Sw -verbose -switch, present in many programs. -The rename solved this problem once for all. -Although this rename breaks a basic interface, having the -.Sw -V -abbreviation to display the version information, isn't all too bad. -.BU -.Sw -[no]preserve -of -.Pn refile -was removed because what use was it anyway? -.QS -Normally when a message is refiled, for each destination -folder it is assigned the number which is one above the current -highest message number in that folder. Use of the -\-preserv [sic!] switch will override this message renaming, and try -to preserve the number of the message. If a conflict for a -particular folder occurs when using the \-preserve switch, -then refile will use the next available message number which -is above the message number you wish to preserve. -.QE -.BU -The removal of the -.Sw -[no]reverse -switches of -.Pn scan -.Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173 -is a bug fix, supported by the comments -``\-[no]reverse under #ifdef BERK (I really HATE this)'' -by Rose and -``Lists messages in reverse order with the `\-reverse' switch. -This should be considered a bug.'' by Romine in the documentation. -The question remains why neither Rose and Romine had fixed this -bug in the Eighties when they wrote these comments nor has anyone -thereafter. - - -.ig - -forw: [no]dashstuffing(mhl) - -mhshow: [no]pause [no]serialonly - -mhmail: resent queued -inc: snoop, (pop) - -mhl: [no]faceproc folder sleep - [no]dashstuffing(forw) digest list volume number issue number - -prompter: [no]doteof - -refile: [no]preserve [no]unlink [no]rmmproc - -send: [no]forward [no]mime [no]msgid - [no]push split [no]unique (sasl) width snoop [no]dashstuffing - attach attachformat -whatnow: (noedit) attach - -slocal: [no]suppressdups - -spost: [no]filter [no]backup width [no]push idanno - [no]check(whom) whom(whom) - -whom: ??? - -.. - - -.ig - -.P -In the best case, all switches are unambiguous on the first character, -or on the three-letter prefix for the `no' variants. -Reducing switch prefix collisions, shortens the necessary prefix length -the user must type. -Having less switches helps best. - -.. - - -.\" XXX: whatnow prompt commands - - - - -.H1 "Modernizing -.P -The code base of mmh originates from the late Seventies. -Through the Eighties, extensive work had been done on it. -In the Nineties, it had been partly reorganized and extended. -Relicts from each decade have gathered in the code base. -My goal was to modernize the code base. - -.P -FIXME functional aspect only here -.P -FIXME ref to `code style' for non-functional aspects. - - -.H2 "Code Relicts -.P -My position to drop obsolete functionality of mmh to remove old code -is much more revolutional than the nmh community likes to have it. -Working on an experimental version, I was able to quickly drop -functionality I considered ancient. -The need for consensus with peers would have slowed this process down. -Without the need to justify my decisions, I was able to rush forward. -In Dezember 2011, Paul Vixie motivated the nmh developers to just -do the work: -.[ -paul vixie edginess nmh-workers -.] -.QS -let's stop walking on egg shells with this code base. there's no need to -discuss whether to keep using vfork, just note in [sic!] passing, [...] -we don't need a separate branch for removing vmh -or ridding ourselves of #ifdef's or removing posix replacement functions -or depending on pure ansi/posix "libc". -.QP -these things should each be a day or two of work and the "main branch" -should just be modern. [...] -let's push forward, aggressively. -.QE -.LP -I did so already in the months before. -I pushed forward. -I simply dropped the cruft. -.P -The decision to drop a feature was based on literature research and -careful thinking, but whether having had contact to this particular -feature within my own computer life served as a rule of thumb. -My reasons are always made clean in the commit message for the -version control system. -Hence, others can comprehend my view and argue for undoing the change -if I have missed an important aspect. - - -.U3 "Forking -.P -In being a tool chest, MH creates many processes. -In earlier times -.Fu fork() -had been an expensive system call, because the process's image needed -to be duplicated completely at once. -This was especially painfull in the common case when the image gets -replaced by a call to -.Fu exec() -right after having forked the child process. -The -.Fu vfork() -system call was invented to speed up this particular case. -It completely omits the duplication of the image. -On old systems this resulted in significant speed ups. -Therefore MH used -.Fu vfork() -whenever possible. -.P -Modern memory management units support copy-on-write semantics, which make -.Fu fork() -almost as fast as -.Fu vfork() . -The man page of -.Mp vfork (2) -in FreeBSD 8.0 states: -.QS -This system call will be eliminated when proper system sharing mechanisms -are implemented. Users should not depend on the memory sharing semantics -of vfork() as it will, in that case, be made synonymous to fork(2). -.QE -.LP -Vixie supports the removal with the note that ``the last -system on which fork was so slow that an mh user would notice it, was -Eunice. that was 1987''. -.[ -nmh-workers vixie edginess -.] -I replaced all calls to -.Fu vfork() -with calls to -.Fu fork() . -.P -Related to the costs of -.Fu fork() -is the probability of its success. -In the Eighties on heavy loaded systems, calls to -.Fu fork() -were prone to failure. -Hence, many of the -.Fu fork() -calls in the code were wrapped into loops to retry the -.Fu fork() -several times, for higher changes to succeed, eventually. -On modern systems, failing calls to -.Fu fork() -are unusual. -Hence, in the rare case when -.Fu fork() -fails, mmh programs simply abort. - - -.U3 "Obsolete Header Fields -.BU -The -.Hd Encrypted -header field was introduced by RFC\|822, -but already marked legacy in RFC\|2822. -OpenPGP provides the basis for standardized exchange of encrypted -messages [RFC\|4880, RFC\|3156]. -The support for -.Hd Encrypted -header fields is removed in mmh. -.BU -Native support for -.Hd Face -header fields has been removed, as well. -This feature is similar to the -.Hd X-Face -header field in its intent, -but takes a different approach to store the image. -Instead of encoding the image data directly into the header field, -the it contains the hostname and UDP port where the image -date could be retrieved. -There is even a third system, invented in 2005. -Although it re-uses the -.Hd Face -header field, it is the successor of -.Hd X-Face -with support for colored PNG images. -None of the Face systems described here is popular today. -Hence, mmh has no direct support for them. -.BU -The -.Hd Content-MD5 -header field was introduced by RFC\|1864. -It provides detection of data corruption during the transfer. -But it can not ensure verbatim end-to-end delivery of the contents -[RFC\|1864]. -The proper approach to verify content integrity in an -end-to-end relationship is the use of digital cryptography. -.\" XXX (RFCs FIXME). -On the other hand, transfer protocols should detect corruption during -each transmission. The TCP includes a checksum field therefore. -These two approaches in combinations render the -.Hd Content-MD5 -header field superfluous. -The nmh-workers mailing list archive contains about 4\|200 messages, -ranging from 1992 until today. -Not a single one had a -.Hd Content-MD5 -header field. -Neither did any of the 60\|000 messages in my personal mail storage. -Removing the support for this header field, -removed the last place where MD5 computation was needed. -Hence, the MD5 code could be removed as well. -Over 500 lines of code vanished by this one change. - - -.U3 "MMDF maildrop support -.P -This type of format is conceptionally similar to the mbox format, -but uses a different message delimiter (`\fL^A^A^A^A\fP' instead of -`\fLFrom\0\fP'). -Mbox is the de-facto standard maildrop format on Unix, -whereas the MMDF maildrop format is hardly still known today. -I did drop MMDF maildrop format support. -.P -The simplifications within the code were only moderate. -Switches could be removed from -.L packf -and -.L rcvpack , -which generate packed mailboxes. -Only one packed mailbox format remained: mbox. -The more important changes affected the equally named mail parsing -routine in -.Fn sbr/m_getfld.c . -The MMDF code had been removed there, but as now only one packed mailbox -format is left, further code structure simplifications may be possible. -I have not worked on them yet because -.Fu m_getfld() -is heavily optimized and thus dangerous to touch. -The risk of damaging the intricate workings of the optimized code is -too high. -.\" XXX: move somewhere else -This problem is know to the developers of nmh, too. -They also avoid touching this minefield if possible. - - -.U3 "Prompter's Control Keys -.P -The program -.Pn prompter -queries the user to fill in a message form. -When used by -.Pn comp -as -.Cl "comp -editor prompter" , -the resulting behavior is similar to -.Pn mailx . -Apparently, -.Pn prompter -hadn't been touched lately. -Otherwise it's hardly explainable why it -still offered the switches -.Sw -erase -.Ar chr -and -.Sw -kill -.Ar chr -to name the characters for command line editing. -The times when this had been necessary are long time gone. -Today these things work out-of-the-box, and if not, are configured -with the standard tool -.Pn stty . -The switches are removed now -.Ci 0bd9750710cdbab80cfb4036dd87af20afe1552f . - - -.U3 "Hardcopy terminal support -.P -More of a funny anecdote is a check for printing to a -hardcopy terminal that remained in the code until Spring 2012, -when I finally removed it -.Ci b7764c4a6b71d37918a97594d866258f154017ca . -I surely would be very happy to see such a terminal in action, -maybe actually being able to work on it, but I fear my chances are null. -.P -The check only prevented a pager to be placed between the outputting -program (\c -.Pn mhl ) -and the terminal. -In nmh, this could have been ensured with the -.Sw -nomoreproc -at the command line statically, too. -In mmh, set the profile entry -.Pe Pager -or the environment variable -.Ev PAGER -to -.Pn cat . - - - - -.H2 "Attachments -.P -The mind model of email attachments is unrelated to MIME. -Although the MIME RFCs (2045 through 2049) define the technical -requirements for having attachments, they do not mention the the word -``attachment''. -Instead of attachments, MIME talks about ``multi-part message bodies'' -[RFC\|2045], a more general concept. -Multi-part messages are messages -``in which one or more different -sets of data are combined in a single body'' -[RFC\|2046]. -MIME keeps its descriptions generic; -it does not imply specific usage models. -In email one usage model became prevalent: attachments. -The idea is having a main text document with files of arbitrary kind -attached to it. -In MIME terms, this is a multi-part message having a text part first -and parts of arbitray type following. -.P -MH's MIME support is a direct implementation of the RFCs. -The perception of the topic described in the RFCs is clearly visible -in MH's implementation. -Thus, MH had all the MIME features but no idea of attachments. -Today, however, users don't need all the MIME features but they want -convenient attachment handling. - -.U3 "Composing MIME Messages -.P -In order to improve the situation on the message composing side, -Jon Steinhart had added an attachment system to nmh in 2002. -.Ci 7480dbc14bc90f2d872d434205c0784704213252 -In the file -.Fn docs/README-ATTACHMENTS , -he described his motivation to do so as such: -.QS -Although nmh contains the necessary functionality for MIME message handing, -the interface to this functionality is pretty obtuse. -There's no way that I'm ever going to convince my partner to write -.Pn mhbuild -composition files! -.QE -.LP -With this change, the mind model of attachments entered nmh. -In the same document: -.QS -These changes simplify the task of managing attachments on draft files. -They allow attachments to be added, listed, and deleted. -MIME messages are automatically created when drafts with attachments -are sent. -.QE -.LP -Unfortunately, the attachment system, -like any new facilities in nmh, -was deactive by default. -.P -During my work in Argentina, I tried to improve the attachment system. -But, because of great opposition in the nmh community, -my patch died as a proposal on the mailing list, after long discussions. -.[ -nmh-workers attachment proposal -.] -In Januar 2012, I extended the patch and applied it to mmh. -.Ci 8ff284ff9167eff8f5349481529332d59ed913b1 -In mmh, the attachment system is active by default. -Instead of command line switches, the -.Pe Attachment-Header -profile entry is used to specify -the name of the attachment header field. -It is pre-defined to -.Hd Attach . -.P -To add an attachment to a draft, simply add an attachment header: -.VS -To: bob -Subject: The file you wanted -Attach: /path/to/the/file-bob-wanted --------- -Here it is. -VE -The header field can be added to the draft manually in the editor, -or by using the `attach' command at the WhatNow prompt, or -non-interactively with -.Pn anno : -.VS -anno -append -nodate -component Attach -text /path/to/attachment -VE -Drafts with attachment headers are converted to MIME automatically by -.Pn send . -The conversion to MIME is invisible to the user. -The draft stored in the draft folder is always in source form, with -attachment headers. -If the MIMEification fails, for instance because the file to attach -is not accessible, the original draft is not changed. -.P -The attachment system handles the forwarding of messages, too. -If the attachment header value starts with a plus character (`+'), -like in -.Cl "Attach: +bob 30 42" , -The given messages in the specified folder will be attached. -This allowed to simplify -.Pn forw . -.Ci f41f04cf4ceca7355232cf7413e59afafccc9550 -.P -Closely related to attachments is non-ASCII text content, -because it requires MIME too. -In nmh, the user needed to call `mime' at the WhatNow prompt -to have the draft converted to MIME. -This was necessary whenever the draft contained non-ASCII characters. -If the user did not call `mime', a broken message would be sent. -Therefore, the -.Pe automimeproc -profile entry could be specified to have the `mime' command invoked -automatically each time. -Unfortunately, this approach conflicted with with attachment system -because the draft would already be in MIME format at the time -when the attachment system wanted to MIMEify it. -To use nmh's attachment system, `mime' must not be called at the -WhatNow prompt and -.Pe automimeproc -must not be set in the profile. -But then the case of non-ASCII text without attachment headers was -not caught. -All in all, the solution was complex and irritating. -My patch from December 2010 would have simplified the situation. -.P -Mmh's current solution is even more elaborate. -Any necessary MIMEification is done automatically. -There is no `mime' command at the WhatNow prompt anymore. -The draft will be converted automatically to MIME when either an -attachment header or non-ASCII text is present. -Further more, the special meaning of the hash character (`#') -at line beginnings in the draft message is removed. -Users need not at all deal with the whole topic. -.P -Although the new approach does not anymore support arbitrary MIME -compositions directly, the full power of -.Pn mhbuild -can still be accessed. -Given no attachment headers are included, the user can create -.Pn mhbuild -composition drafts like in nmh. -Then, at the WhatNow prompt, he needs to invoke -.Cl "edit mhbuild -to convert it to MIME. -Because the resulting draft does neither contain non-aASCII characters -nor has it attachment headers, the attachment system will not touch it. -.P -The approach taken in mmh is taylored towards todays most common case: -a text part with possibly attachments. -This case is simplified a lot for users. - -.U3 "MIME Type Guessing -.P -The use of -.Pn mhbuild -composition drafts had one notable advantage over attachment headers -from the programmer's point of view: The user provides the appropriate -MIME types for files to include. -The attachment system needs to find out the correct MIME type itself. -This is a difficult task, yet it spares the user irritating work. -Determining the correct MIME type of content is partly mechanical, -partly intelligent work. -Forcing the user to find out the correct MIME type, -forces him to do partly mechanical work. -Letting the computer do the work, can lead to bad choices for difficult -content. -For mmh, the latter option was chosen. -.P -Determining the MIME type by the suffix of the file name is a dumb -approach, yet it is simple to implement and provides good results -for the common cases. -Mmh implements this approach in the -.Pn print-mimetype -script. -Using it is the default choice. -.P -A far better but less portable approach is the use of -.Pn file . -This standard tool tries to determine the type of files. -Unfortunately, its capabilities and accuracy varies from system to system. -Additionally, its output was only intended for human beings, -but not to be used by programs. -It varies much. -Nevertheless, modern versions of GNU -.Pn file , -which is prevalent on the popular GNU/Linux systems, -provides MIME type output in machine-readable form. -Although this solution is highly system-dependent, -it solves the difficult problem well. -On systems where GNU -.Pn file , -version 5.04 or higher, is available it should be used. -One needs to specify the following profile entry to do so: -.VS -Mime-Type-Query: file -b --mime -VE -.LP -Other versions of -.Pn file -might possibly be usable with wrapper scripts to reformat the output. -The diversity among -.Pn file -implementations is great; one needs to check the local variant. -.P -If no MIME type can be determined, text content gets sent as -`text/plain' and anything else under the generic fall-back type -`application/octet-stream'. -It is not possible in mmh to override the automatic MIME type guessing -for a specific file. -To do so, the user would need to know in advance for which file -the automatic guessing does fail, or the system would require interaction. -I consider both cases impractical. -The existing solution should be sufficient. -If not, the user may always fall back to -.Pn mhbuild -composition drafts and ignore the attachment system. - - -.U3 "Storing Attachments -.P -FIXME - - -.U3 "Showing MIME Messages -.P -FIXME - - - -.H2 "Digital Cryptography -.P -Signing and encryption. - - - -.H2 "Modern Defaults -.P -Just to give one example, for me it took one year of using nmh -before I became aware of the existence of the attachment system. -One could argue that this fact disqualifies my reading of the -documentation. -If I would have installed nmh from source back then, I could agree. -Yet I had used a prepackaged version and had expected that it would -just work. - - - -.H1 "Code Style -.P -foo - - -.H2 "Standard Code -.P -POSIX - -.U3 "Converting to Standard Code -.P -One part of this task was converting obsolete code constructs -to standard constructs. -As I'm not even thirty years old and have no more than seven years of -Unix experience, I needed to learn about the history in retrospective. -Older people likely have used those ancient constructs themselves -and have suffered from their incompatibilities and have longed for -standardization. -Unfortunately, I have only read that others had done so. -This put me in a much more difficult positions when working on the old -code. -I needed to recherche what other would have known by heart from -experience. -All my programming experience comes from a time past ANSI C -and past POSIX. -Although I knew about the times before, I took the -current state implicitly for granted most of the time. -.P -Being aware of -these facts, I rather let people with more historic experience solve the -task of converting the ancient code constructs to standardized ones. -Luckily, Lyndon Nerenberg focused on this task at the nmh project. -He converted large parts of the code to POSIX constructs, removing -the conditionals compilation for now standardized features. -I'm thankful for this task being solved. -I only pulled the changes into -mmh. - - - - -.H2 "Separation - -.U2 "MH Directory Split -.P -In MH and nmh, a personal setup had consisted of two parts: -The MH profile, named -.Fn \&.mh_profile -and being located directly in the user's home directory. -And the MH directory, where all his mail messages and also his personal -forms, scan formats, other configuration files are stored. -The location -of this directory could be user-chosen. -The default was to name it -.Fn Mail -and have it directly in the home directory. -.P -I've never liked the data storage and the configuration to be intermixed. -They are different kinds of data. -One part, are the messages, -which are the data to operate on. -The other part, are the personal -configuration files, which are able to change the behavior of the operations. -The actual operations are defined in the profile, however. -.P -When storing data, one should try to group data by its type. -There's sense in the Unix file system hierarchy, where configuration -file are stored separate (\c -.Fn /etc ) -to the programs (\c -.Fn /bin -and -.Fn /usr/bin ) -to their sources (\c -.Fn /usr/src ). -Such separation eases the backup management, for instance. -.P -In mmh, I've reorganized the file locations. -Still there are two places: -There's the mail storage directory, which, like in MH, contains all the -messages, but, unlike in MH, nothing else. -Its location still is user-chosen, with the default name -.Fn Mail , -in the user's home directory. -This is much similar to the case in nmh. -The configuration files, however, are grouped together in the new directory -.Fn \&.mmh -in the user's home directory. -The user's profile now is a file, named -.Fn profile , -in this mmh directory. -Consistently, the context file and all the personal forms, scan formats, -and the like, are also there. -.P -The naming changed with the relocation. -The directory where everything, except the profile, had been stored (\c -.Fn $HOME/Mail ), -used to be called \fIMH directory\fP. -Now, this directory is called the -user's \fImail storage\fP. -The name \fImmh directory\fP is now given to -the new directory -(\c -.Fn $HOME/.mmh ), -containing all the personal configuration files. -.P -The separation of the files by type of content is logical and convenient. -There are no functional differences as any possible setup known to me -can be implemented with both approaches, although likely a bit easier -with the new approach. -The main goal of the change had been to provide -sensible storage locations for any type of personal mmh file. -.P -In order for one user to have multiple MH setups, he can use the -environment variable -.Ev MH -the point to a different profile file. -The MH directory (mail storage plus personal configuration files) is -defined by the -.Pe Path -profile entry. -The context file could be defined by the -.Pe context -profile entry or by the -.Ev MHCONTEXT -environment variable. -The latter is useful to have a distinct context (e.g. current folders) -in each terminal window, for instance. -In mmh, there are three environment variables now. -.Ev MMH -may be used to change the location of the mmh directory. -.Ev MMHP -and -.Ev MMHC -change the profile and context files, respectively. -Besides providing a more consistent feel (which simply is the result -of being designed anew), the set of personal configuration files can -be chosen independently from the profile (including mail storage location) -and context, now. -Being it relevant for practical use or not, it -de-facto is an improvement. -However, the main achievement is the -split between mail storage and personal configuration files. - - -.H2 "Modularization -.P -whatnowproc -.P -The \fIMH library\fP -.Fn libmh.a -collects a bunch of standard functions that many of the MH tools need, -like reading the profile or context files. -This doesn't hurt the separation. - - -.H2 "Style -.P -Code layout, goto, ... - -.P -anno rework - - - - -.H1 "Concept Exploitation/Homogeneity - - -.H2 "Draft Folder -.P -Historically, MH provided exactly one draft message, named -.Fn draft -and -being located in the MH directory. -When starting to compose another message -before the former one was sent, the user had been questioned whether to use, -refile or replace the old draft. -Working on multiple drafts at the same time -was impossible. -One could only work on them in alteration by refiling the -previous one to some directory and fetching some other one for reediting. -This manual draft management needed to be done each time the user wanted -to switch between editing one draft to editing another. -.P -To allow true parallel editing of drafts, in a straight forward way, the -draft folder facility exists. -It had been introduced already in July 1984 -by Marshall T. Rose. -The facility was deactivated by default. -Even in nmh, the draft folder facility remained deactivated by default. -At least, Richard Coleman added the man page -.Mp mh-draft(5) -to document -the feature well. -.P -The only advantage of not using the draft folder facility is the static -name of the draft file. -This could be an issue for MH front-ends like mh-e. -But as they likely want to provide working on multiple drafts in parallel, -the issue is only concerning compatibility. -The aim of nmh to stay compatible -prevented the default activation of the draft folder facility. -.P -On the other hand, a draft folder is the much more natural concept than -a draft message. -MH's mail storage consists of folders and messages, -the messages named with ascending numbers. -A draft message breaks with this -concept by introducing a message in a file named -.Fn draft . -This draft -message is special. -It can not be simply listed with the available tools, -but instead requires special switches. -I.e. corner-cases were -introduced. -A draft folder, in contrast, does not introduce such -corner-cases. -The available tools can operate on the messages within that -folder like on any messages within any mail folders. -The only difference -is the fact that the default folder for -.Pn send -is the draft folder, -instead of the current folder, like for all other tools. -.P -The trivial part of the change was activating the draft folder facility -by default and setting a default name for this folder. -Obviously, I chose -the name -.Fn +drafts . -This made the -.Sw -draftfolder -and -.Sw -draftmessage -switches useless, and I could remove them. -The more difficult but also the part that showed the real improvement, -was updating the tools to the new concept. -.Sw -draft -switches could -be dropped, as operating on a draft message became indistinguishable to -operating on any other message for the tools. -.Pn comp -still has its -.Sw -use -switch for switching between its two modes: (1) Compose a new -draft, possibly by taking some existing message as a form. -(2) Modify -an existing draft. -In either case, the behavior of -.Pn comp is -deterministic. -There is no more need to query the user. -I consider this -a major improvement. -By making -.Pn send -simply operate on the current -message in the draft folder by default, with message and folder both -overridable by specifying them on the command line, it is now possible -to send a draft anywhere within the storage by simply specifying its folder -and name. -.P -All theses changes converted special cases to regular cases, thus -simplifying the tools and increasing the flexibility. - - -.H2 "Trash Folder -.P -Similar to the situation for drafts is the situation for removed messages. -Historically, a message was deleted by renaming. -A specific -\fIbackup prefix\fP, often comma (\c -.Fn , ) -or hash (\c -.Fn # ), -being prepended to the file name. -Thus, MH wouldn't recognize the file -as a message anymore, as only files whose name consists of digits only -are treated as messages. -The removed messages remained as files in the -same directory and needed some maintenance job to truly delete them after -some grace time. -Usually, by running a command similar to -.VS -find /home/user/Mail -ctime +7 -name ',*' | xargs rm -VE -in a cron job. -Within the grace time interval -the original message could be restored by stripping the -the backup prefix from the file name. -If however, the last message of -a folder is been removed \(en say message -.Fn 6 -becomes file -.Fn ,6 -\(en and a new message enters the same folder, thus the same -numbered being given again \(en in our case -.Fn 6 -\(en, if that one -is removed too, then the backup of the former message gets overwritten. -Thus, the ability to restore removed messages does not only depend on -the ``sweeping cron job'' but also on the removing of further messages. -This is undesirable, because the real mechanism is hidden from the user -and the consequences of further removals are not always obvious. -Further more, the backup files are scattered within the whole mail -storage, instead of being collected at one place. -.P -To improve the situation, the profile entry -.Pe rmmproc -(previously named -.Pe Delete-Prog ) -was introduced, very early. -It could be set to any command, which would care for the mail removal -instead of taking the default action, described above. -Refiling the to-be-removed files to some garbage folder was a common -example. -Nmh's man page -.Mp rmm(1) -proposes -.Cl "refile +d -to move messages to the garbage folder and -.Cl "rm `mhpath +d all` -the empty the garbage folder. -Managing the message removal this way is a sane approach. -It keeps -the removed messages in one place, makes it easy to remove the backup -files, and, most important, enables the user to use the tools of MH -itself to operate on the removed messages. -One can -.Pn scan -them, -.Pn show -them, and restore them with -.Pn refile . -There's no more -need to use -.Pn mhpath -to switch over from MH tools to Unix tools \(en MH can do it all itself. -.P -This approach matches perfect with the concepts of MH, thus making -it powerful. -Hence, I made it the default. -And even more, I also -removed the old backup prefix approach, as it is clearly less powerful. -Keeping unused alternative in the code is a bad choice as they likely -gather bugs, by not being constantly tested. -Also, the increased code -size and more conditions crease the maintenance costs. -By strictly -converting to the trash folder approach, I simplified the code base. -.Pn rmm -calls -.Pn refile -internally to move the to-be-removed -message to the trash folder (\c -.Fn +trash -by default). -Messages -there can be operated on like on any other message in the storage. -The sweep clean, one can use -.Cl "rmm -unlink +trash a" , -where the -.Sw -unlink -switch causes the files to be truly unliked instead -of moved to the trash folder. - - -.H2 "Path Notations -.P -foo - - -.H2 "MIME Integration -.P -user-visible access to whole messages and MIME parts are inherently -different - - -.H2 "Of One Cast -.P
--- a/ch04.roff Sat Jun 23 22:08:17 2012 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,16 +0,0 @@ -.H0 "Summary - -.P -Because of several circumstances, my experimental version is rather -a fork today, although this may change again in the future. - -.P -Although mmh bases on nmh, it is likely seen as a step backward. -I agree. -However, this step backward actually is a step forward, -although in a different direction. - -.P -.\" Top candidate for the final sentence: -This enabled me to follow my vision straightly and thus produce -a result of greater pureness.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/discussion.roff Sat Jun 23 22:12:14 2012 +0200 @@ -0,0 +1,2527 @@ +.H0 "Discussion +.P +This main chapter discusses the practical work done in the mmh project. +It is structured along the goals to achieve. +The concrete work done +is described in the examples of how the general goals were achieved. +The discussion compares the current version of mmh with the state of +nmh just before the mmh project started, i.e. Fall 2011. +Current changes of nmh will be mentioned only as side notes. +.\" XXX where do I discuss the parallel development of nmh? + + + +.H1 "Stream-Lining + +.P +MH had been considered an all-in-one system for mail handling. +The community around nmh has a similar understanding. +In fundamental difference, mmh shall be a MUA only. +I believe that the development of all-in-one mail systems is obsolete. +Today, email is too complex to be fully covered by single projects. +Such a project won't be able to excel in all aspects. +Instead, the aspects of email should be covered my multiple projects, +which then can be combined to form a complete system. +Excellent implementations for the various aspects of email exist already. +Just to name three examples: Postfix is a specialized MTA, +Procmail is a specialized MDA, and Fetchmail is a specialized MRA. +I believe that it is best to use such specialized tools instead of +providing the same function again as a side-component in the project. +.P +Doing something well, requires to focus on a small set of specific aspects. +Under the assumption that focused development produces better results +in the particular area, specialized projects will be superior +in their field of focus. +Hence, all-in-one mail system projects \(en no matter if monolithic +or modular \(en will never be the best choice in any of the fields. +Even in providing the best consistent all-in-one system they are likely +to be beaten by projects that focus only on integrating existing mail +components to a homogeneous system. +.P +The limiting resource in Free Software community development +is usually man power. +If the development power is spread over a large development area, +it becomes even more difficult to compete with the specialists in the +various fields. +The concrete situation for MH-based mail systems is even tougher, +given the small and aged community, including both developers and users, +it has. +.P +In consequence, I believe that the available development resources +should focus on the point where MH is most unique. +This is clearly the user interface \(en the MUA. +Peripheral parts should be removed to stream-line mmh for the MUA task. + + +.H2 "Mail Transfer Facilities +.P +In contrast to nmh, which also provides mail submission and mail retrieval +agents, mmh is a MUA only. +This general difference initiated the development of mmh. +Removing the mail transfer facilities had been the first work task +in the mmh project. +.P +Focusing on one mail agent role only is motivated by Eric Allman's +experience with Sendmail. +He identified limiting Sendmail the MTA task had be one reason for +its success: +.[ [ +costales sendmail +.], p. xviii] +.QS +Second, I limited myself to the routing function \(en +I wouldn't write user agents or delivery backends. +This was a departure of the dominant through of the time, +in which routing logic, local delivery, and often the network code +were incorporated directly into the user agents. +.QE +.P +In mmh, the Mail Submission Agent (MSA) is called +\fIMessage Transfer Service\fP (MTS). +This facility, implemented by the +.Pn post +command, established network connections and spoke SMTP to submit +messages for relay to the outside world. +The changes in email demanded changes in this part of nmh too. +Encryption and authentication for network connections +needed to be supported, hence TLS and SASL were introduced into nmh. +This added complexity to nmh without improving it in its core functions. +Also, keeping up with recent developments in the field of +mail transfer requires development power and specialists. +In mmh this whole facility was simply cut off. +.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226 +.Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3 +.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b +Instead, mmh depends on an external MSA. +The only outgoing interface available to mmh is the +.Pn sendmail +command, which almost any MSA provides. +If not, a wrapper program can be written. +It must read the message from the standard input, extract the +recipient addresses from the message header, and hand the message +over to the MSA. +For example, a wrapper script for qmail would be: +.VS +#!/bin/sh +# ignore command line arguments +exec qmail-inject +VE +The requirement to parse the recipient addresses out of the message header +is likely to be removed in the future. +Then mmh would give the recipient addresses as command line arguments. +This appears to be the better interface. +.\" XXX implement it +.P +To retrieve mail, the +.Pn inc +command acted as Mail Retrieval Agent (MRA). +It established network connections +and spoke POP3 to retrieve mail from remote servers. +As with mail submission, the network connections required encryption and +authentication, thus TLS and SASL were added. +Support for message retrieval through IMAP will become necessary +to be added soon, too, and likewise for any other changes in mail transfer. +Not so for mmh because it has dropped the support for retrieving mail +from remote locations. +.Ci ab7b48411962d26439f92f35ed084d3d6275459c +Instead, it depends on an external tool to cover this task. +In mmh exist two paths for messages to enter mmh's mail storage: +(1) Mail can be incorporated with +.Pn inc +from the system maildrop, or (2) with +.Pn rcvstore +by reading them, one at a time, from the standard input. +.P +With the removal of the MSA and MRA, mmh converted from an all-in-one +mail system to being a MUA only. +Now, of course, mmh depends on third-party software. +An external MSA is required to transfer mail to the outside world; +an external MRA is required to retrieve mail from remote machines. +There exist excellent implementations of such software, +which do this specific task likely better than the internal +versions had done it. +Also, the best suiting programs can be freely chosen. +.P +As it had already been possible to use an external MSA or MRA, +why not keep the internal version for convenience? +The question whether there is sense in having a fall-back pager in all +the command line tools, for the cases when +.Pn more +or +.Pn less +aren't available, appears to be ridiculous. +Of course, MSAs and MRAs are more complex than text pagers +and not necessarily available but still the concept of orthogonal +design holds: ``Write programs that do one thing and do it well.'' +.[ +mcilroy unix phil +p. 53 +.] +.[ +mcilroy bstj foreword +.] +Here, this part of the Unix philosophy was applied not only +to the programs but to the project itself. +In other words: +``Develop projects that focus on one thing and do it well.'' +Projects grown complex should be split for the same reasons programs grown +complex should be split. +If it is conceptionally more elegant to have the MSA and MRA as +separate projects then they should be separated. +This is the case here, in my opinion. +The RFCs propose this separation by clearly distinguishing the different +mail handling tasks. +.[ +rfc 821 +.] +The small interfaces between the mail agents support the separation. +.P +In the beginning, email had been small and simple. +At that time, +.Pn /bin/mail +had covered anything there was to email and still had been small +and simple. +Later, the essential complexity of email increased. +(Essential complexity is the complexity defined by the problem itself.\0 +.[[ +brooks no silver bullet +.]]) +Email systems reacted to this change: They grew. +RFCs started to introduce the concept of mail agents to separate the +various tasks because they became more extensive and new tasks appeared. +As the mail systems grew even more, parts were split off. +In nmh, for instance, the POP server, which was included in the original +MH, was removed. +Now is the time to go one step further and split the MSA and MRA off, too. +Not only does this decrease the code size of the project, +but, more important, it unburdens mmh of the whole field of +message transfer with all its implications for the project. +There is no more need to concern with changes in network transfer. +This independence is received by depending on an external program +that covers the field. +Today, this is a reasonable exchange. +.P +Functionality can be added in three different ways: +.BU +Implementing the function originally in the project. +.BU +Depending on a library that provides the function. +.BU +Depending on a program that provides the function. +.P +Whereas adding the function originally to the project increases the +code size most and requires most maintenance and development work, +it makes the project most independent of other software. +Using libraries or external programs require less maintenance work +but introduces dependencies on external software. +Programs have the smallest interfaces and provide the best separation +but possibly limit the information exchange. +External libraries are stronger connected than external programs, +thus information can be exchanged more flexible. +Adding code to a project increases maintenance work. +.\" XXX ref +Implementing complex functions originally in the project adds +a lot of code. +This should be avoided if possible. +Hence, the dependencies only change in kind, not in their existence. +In mmh, library dependencies on +.Pn libsasl2 +and +.Pn libcrypto /\c +.Pn libssl +were treated against program dependencies on an MSA and an MRA. +This also meant treating build-time dependencies against run-time +dependencies. +Besides program dependencies providing the stronger separation +and being more flexible, they also allowed +over 6\|000 lines of code to be removed from mmh. +This made mmh's code base about 12\|% smaller. +Reducing the project's code size by such an amount without actually +losing functionality is a convincing argument. +Actually, as external MSAs and MRAs are likely superior to the +project's internal versions, the common user even gains functionality. +.P +Users of MH should not have problems to set up an external MSA and MRA. +Also, the popular MSAs and MRAs have large communities and a lot +of documentation available. +Choices for MSAs range from full-featured MTAs like +.I Postfix +over mid-size MTAs like +.I masqmail +and +.I dma +to small forwarders like +.I ssmtp +and +.I nullmailer . +Choices for MRAs include +.I fetchmail , +.I getmail , +.I mpop +and +.I fdm . + + +.H2 "Non-MUA Tools +.P +One goal of mmh is to remove the tools that are not part of the MUA's task. +Further more, any tools that don't improve the MUA's job significantly +should be removed. +Loosely related and rarely used tools distract from the lean appearance. +They require maintenance work without adding much to the core task. +By removing these tools, the project shall become more stream-lined +and focused. +In mmh the following tools are not available anymore: +.BU +.Pn conflict +was removed +.Ci 8b235097cbd11d728c07b966cf131aa7133ce5a9 +because it is a mail system maintenance tool that is not MUA-related. +It even checked +.Fn /etc/passwd +and +.Fn /etc/group +for consistency, which is completely unrelated to email. +A tool like +.Pn conflict +is surely useful, but it should not be shipped with mmh. +.\" XXX historic reasons? +.BU +.Pn rcvtty +was removed +.Ci 14767c94b3827be7c867196467ed7aea5f6f49b0 +because its use case of writing to the user's terminal +on receiving of mail is obsolete. +If users like to be informed of new mail, the shell's +.Ev MAILPATH +variable or graphical notifications are technically more appealing. +Writing directly to terminals is hardly ever wanted today. +If though one wants to have it this way, the standard tool +.Pn write +can be used in a way similar to: +.VS +scan -file - | write `id -un` +VE +.BU +.Pn viamail +was removed +.Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932 +when the new attachment system was activated, because +.Pn forw +could then cover the task itself. +The program +.Pn sendfiles +was rewritten as a shell script wrapper around +.Pn forw . +.Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6 +.BU +.Pn msgchk +was removed +.Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe , +because it lost its use case when POP support was removed. +A call to +.Pn msgchk +provided hardly more information than: +.VS +ls -l /var/mail/meillo +VE +It did distinguish between old and new mail, but +this detail information can be retrieved with +.Pn stat (1), +too. +A small shell script could be written to print the information +in a similar way, if truly necessary. +As mmh's +.Pn inc +only incorporates mail from the user's local maildrop, +and thus no data transfers over slow networks are involved, +there's hardly any need to check for new mail before incorporating it. +.BU +.Pn msh +was removed +.Ci 916690191222433a6923a4be54b0d8f6ac01bd02 +because the tool was in conflict with the philosophy of MH. +It provided an interactive shell to access the features of MH, +but it wasn't just a shell, tailored to the needs of mail handling. +Instead it was one large program that had several MH tools built in. +This conflicts with the major feature of MH of being a tool chest. +.Pn msh 's +main use case had been accessing Bulletin Boards, which have seized to +be popular. +.P +Removing +.Pn msh , +together with the truly archaic code relicts +.Pn vmh +and +.Pn wmh , +saved more than 7\|000 lines of C code \(en +about 15\|% of the project's original source code amount. +Having less code \(en with equal readability, of course \(en +for the same functionality is an advantage. +Less code means less bugs and less maintenance work. +As +.Pn rcvtty +and +.Pn msgchk +are assumed to be rarely used and can be implemented in different ways, +why should one keep them? +Removing them stream-lines mmh. +.Pn viamail 's +use case is now partly obsolete and partly covered by +.Pn forw , +hence there's no reason to still maintain it. +.Pn conflict +is not related to the mail client, and +.Pn msh +conflicts with the basic concept of MH. +Theses two tools might still be useful, but they should not be part of mmh. +.P +Finally, there's +.Pn slocal . +.Pn slocal +is an MDA and thus not directly MUA-related. +It should be removed from mmh, because including it conflicts with +the idea that mmh is a MUA only. +.Pn slocal +should rather become a separate project. +However, +.Pn slocal +provides rule-based processing of messages, like filing them into +different folders, which is otherwise not available in mmh. +Although +.Pn slocal +does neither pull in dependencies nor does it include a separate +technical area (cf. Sec. XXX), still, +it accounts for about 1\|000 lines of code that need to be maintained. +As +.Pn slocal +is almost self-standing, it should be split off into a separate project. +This would cut the strong connection between the MUA mmh and the MDA +.Pn slocal . +For anyone not using MH, +.Pn slocal +would become yet another independent MDA, like +.I procmail . +Then +.Pn slocal +could be installed without the complete MH system. +Likewise, mmh users could decide to use +.I procmail +without having a second, unused MDA, +.Pn slocal , +installed. +That appears to be conceptionally the best solution. +Yet, +.Pn slocal +is not split off. +I defer the decision over +.Pn slocal +in need for deeper investigation. +In the meanwhile, it remains part of mmh. +That does not hurt because +.Pn slocal +is unrelated to the rest of the project. + + +.H2 "\fLshow\fP and \fPmhshow\fP +.P +Since the very beginning \(en already in the first concept paper \(en +.Pn show +had been MH's message display program. +.Pn show +mapped message numbers and sequences to files and invoked +.Pn mhl +to have the files formatted. +With MIME, this approach wasn't sufficient anymore. +MIME messages can consist of multiple parts. Some parts are not +directly displayable and text content might be encoded in +foreign charsets. +.Pn show 's +understanding of messages and +.Pn mhl 's +display capabilities couldn't cope with the task any longer. +.P +Instead of extending these tools, additional tools were written from +scratch and added to the MH tool chest. +Doing so is encouraged by the tool chest approach. +Modular design is a great advantage for extending a system, +as new tools can be added without interfering with existing ones. +First, the new MIME features were added in form of the single program +.Pn mhn . +The command +.Cl "mhn -show 42 +would show the MIME message numbered 42. +With the 1.0 release of nmh in February 1999, Richard Coleman finished +the split of +.Pn mhn +into a set of specialized tools, which together covered the +multiple aspects of MIME. +One of them was +.Pn mhshow , +which replaced +.Cl "mhn -show" . +It was capable of displaying MIME messages appropriately. +.P +From then on, two message display tools were part of nmh, +.Pn show +and +.Pn mhshow . +To ease the life of users, +.Pn show +was extended to automatically hand the job over to +.Pn mhshow +if displaying the message would be beyond +.Pn show 's +abilities. +In consequence, the user would simply invoke +.Pn show +(possibly through +.Pn next +or +.Pn prev ) +and get the message printed with either +.Pn show +or +.Pn mhshow , +whatever was more appropriate. +.P +Having two similar tools for essentially the same task is redundant. +Usually, +users wouldn't distinguish between +.Pn show +and +.Pn mhshow +in their daily mail reading. +Having two separate display programs was therefore mainly unnecessary +from a user's point of view. +Besides, the development of both programs needed to be in sync, +to ensure that the programs behaved in a similar way, +because they were used like a single tool. +Different behavior would have surprised the user. +.P +Today, non-MIME messages are rather seen to be a special case of +MIME messages, although it is the other way round. +As +.Pn mhshow +had already be able to display non-MIME messages, it appeared natural +to drop +.Pn show +in favor of using +.Pn mhshow +exclusively. +.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853 +Removing +.Pn show +is no loss in function, because functionally +.Pn mhshow +covers it completely. +The old behavior of +.Pn show +can still be emulated with the simple command line: +.VS +mhl `mhpath c` +VE +.P +For convenience, +.Pn mhshow +was renamed to +.Pn show +after +.Pn show +was gone. +It is clear that such a rename may confuse future developers when +trying to understand the history. +Nevertheless, I consider the convenience on the user's side, +to call +.Pn show +when they want a message to be displayed, to outweigh the inconvenience +on the developer's side when understanding the project history. +.P +To prepare for the transition, +.Pn mhshow +was reworked to behave more like +.Pn show +first. +(cf. Sec. XXX) +Once the tools behaved more alike, the replacing appeared to be +even more natural. +Today, mmh's new +.Pn show +became the one single message display program again, with the difference +that today it handles MIME messages as well as non-MIME messages. +The outcome of the transition is one program less to maintain, +no second display program for users to deal with, +and less system complexity. +.P +Still, removing the old +.Pn show +hurts in one regard: It had been such a simple program. +Its lean elegance is missing to the new +.Pn show . +But there is no chance; +supporting MIME demands for higher essential complexity. + + +.H2 "Configure Options +.P +Customization is a double-edged sword. +It allows better suiting setups, but not for free. +There is the cost of code complexity to be able to customize. +There is the cost of less tested setups, because there are +more possible setups and especially corner-cases. +And, there is the cost of choice itself. +The code complexity directly affects the developers. +Less tested code affects both, users and developers. +The problem of choice affects the users, for once by having to +choose, but also by more complex interfaces that require more documentation. +Whenever options add little advantages, they should be considered for +removal. +I have reduced the number of project-specific configure options from +fifteen to three. + +.U3 "Mail Transfer Facilities +.P +With the removal of the mail transfer facilities five configure +options vanished: +.P +The switches +.Sw --with-tls +and +.Sw --with-cyrus-sasl +had activated the support for transfer encryption and authentication. +This is not needed anymore. +.Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3 +.Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b +.P +The configure switch +.Sw --enable-pop +activated the message retrieval facility. +The code area that would be conditionally compiled in for TLS and SASL +support had been small. +The conditionally compiled code area for POP support had been much larger. +Whereas the code base changes would only slightly change on toggling +TLS or SASL support, it changed much on toggling POP support. +The changes in the code base could hardly be overviewed. +By having POP support togglable a second code base had been created, +one that needed to be tested. +This situation is basically similar for the conditional TLS and SASL +code, but there the changes are minor and can yet be overviewed. +Still, conditional compilation of a code base creates variations +of the original program. +More variations require more testing and maintenance work. +.P +Two other options only specified default configuration values: +.Sw --with-mts +defined the default transport service, either +.Ar smtp +or +.Ar sendmail . +In mmh this fixed to +.Ar sendmail . +.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226 +With +.Sw --with-smtpservers +default SMTP servers for the +.Ar smtp +transport service could be specified. +.Ci 128545e06224233b7e91fc4c83f8830252fe16c9 +Both of them became irrelevant. + +.U3 "Backup Prefix +.P +The backup prefix is the string that was prepended to message +filenames to tag them as deleted. +By default it had been the comma character `\f(CW,\fP'. +In July 2000, Kimmo Suominen introduced +the configure option +.Sw --with-hash-backup +to change the default to the hash symbol `\f(CW#\fP'. +The choice was probably personal preference, because first, the +option was named +.Sw --with-backup-prefix. +and had the prefix symbol as argument. +But giving the hash symbol as argument caused too many problems +for Autoconf, +thus the option was limited to use the hash symbol as the default prefix. +This supports the assumption, that the choice for the hash was +personal preference only. +Being related or not, words that start with the hash symbol +introduce a comment in the Unix shell. +Thus, the command line +.Cl "rm #13 #15 +calls +.Pn rm +without arguments because the first hash symbol starts the comment +that reaches until the end of the line. +To delete the backup files, +.Cl "rm ./#13 ./#15" +needs to be used. +Using the hash as backup prefix can be seen as a precaution against +data loss. +.P +I removed the configure option but added the profile entry +.Pe backup-prefix , +which allows to specify an arbitrary string as backup prefix. +.Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086 +Profile entries are the common method to change mmh's behavior. +This change did not remove the choice but moved it to a location where +it suited better. +.P +Eventually, however, the new trash folder concept +.Cf "Sec. XXX +obsoleted the concept of the backup prefix completely. +.Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173 +.\" (Well, there still are corner-cases to remove until the backup +.\" prefix can be laid to rest, eventually.) +.\" FIXME: Do this work in the code! + +.U3 "Editor and Pager +.P +The two configure options +.CW --with-editor=EDITOR +.CW --with-pager=PAGER +were used to specify the default editor and pager at configure time. +Doing so at configure time made sense in the Eighties, +when the set of available editors and pagers varied much across +different systems. +Today, the situation is more homogeneous. +The programs +.Pn vi +and +.Pn more +can be expected to be available on every Unix system, +as they are specified by POSIX since two decades. +(The specifications for +.Pn vi +and +.Pn more +appeared in +.[ +posix 1987 +.] +and, +.[ +posix 1992 +.] +respectively.) +As a first step, these two tools were hard-coded as defaults. +.Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f +Not changed were the +.Pe editor +and +.Pe moreproc +profile entries, which allowed the user to override the system defaults. +Later, the concept was reworked to respect the standard environment +variables +.Ev VISUAL +and +.Ev PAGER +if they are set. +Today, mmh determines the editor to use in the following order, +taking the first available and non-empty item: +.IP (1) +Environment variable +.Ev MMHEDITOR +.IP (2) +Profile entry +.Pe Editor +.IP (3) +Environment variable +.Ev VISUAL +.IP (4) +Environment variable +.Ev EDITOR +.IP (5) +Command +.Pn vi . +.P +.Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b +.P +The pager to use is determined in a similar order, +also taking the first available and non-empty item: +.IP (1) +Environment variable +.Ev MMHPAGER +.IP (2) +Profile entry +.Pe Pager +(replaces +.Pe moreproc ) +.IP (3) +Environment variable +.Ev PAGER +.IP (4) +Command +.Pn more . +.P +.Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e +.P +By respecting the +.Ev VISUAL /\c +.Ev EDITOR +and +.Ev PAGER +environment variables, +the new behavior confirms better to the common style on Unix systems. +Additionally, the new approach is more uniform and clearer to users. + + +.U3 "ndbm +.P +.Pn slocal +used to depend on +.I ndbm , +a database library. +The database is used to store the `\fLMessage-ID\fP's of all +messages delivered. +This enables +.Pn slocal +to suppress delivering the same message to the same user twice. +(This features was enabled by the +.Sw -suppressdup +switch.) +.P +A variety of versions of the database library exist. +.[ +wolter unix incompat notes dbm +.] +Complicated autoconf code was needed to detect them correctly. +Further more, the configure switches +.Sw --with-ndbm=ARG +and +.Sw --with-ndbmheader=ARG +were added to help with difficult setups that would +not be detected automatically or correctly. +.P +By removing the suppress duplicates feature of +.Pn slocal , +the dependency on +.I ndbm +vanished and 120 lines of complex autoconf code could be saved. +.Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf +The change removed functionality too, but that is minor to the +improvement by dropping the dependency and the complex autoconf code. + +.U3 "mh-e Support +.P +The configure option +.Sw --disable-mhe +was removed when the mh-e support was reworked. +Mh-e is the Emacs front-end to MH. +It requires MH to provide minor additional functions. +The +.Sw --disable-mhe +configure option could switch these extensions off. +After removing the support for old versions of mh-e, +only the +.Sw -build +switches of +.Pn forw +and +.Pn repl +are left to be mh-e extensions. +They are now always built in because they add little code and complexity. +In consequence, the +.Sw --disable-mhe +configure option was removed +.Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643 +Removing the option removed a second code setup that would have +needed to be tested. +This change was first done in nmh and thereafter merged into mmh. +.P +The interface changes in mmh require mh-e to be adjusted in order +to be able to use mmh as back-end. +This will require minor changes to mh-e, but removing the +.Sw -build +switches would require more rework. + +.U3 "Masquerading +.P +The configure option +.Sw --enable-masquerade +could take up to three arguments: +`draft_from', `mmailid', and `username_extension'. +They activated different types of address masquerading. +All of them were implemented in the SMTP-speaking +.Pn post +command, which provided an MSA. +Address masquerading is an MTA's task and mmh does not cover +this field anymore. +Hence, true masquerading needs to be implemented in the external MTA. +.P +The +.I mmailid +masquerading type is the oldest one of the three and the only one +available in the original MH. +It provided a +.I username +to +.I fakeusername +mapping, based on the password file's GECOS field. +The man page +.Mp mh-tailor(5) +described the use case as being the following: +.QS +This is useful if you want the messages you send to always +appear to come from the name of an MTA alias rather than your +actual account name. For instance, many organizations set up +`First.Last' sendmail aliases for all users. If this is +the case, the GECOS field for each user should look like: +``First [Middle] Last <First.Last>'' +.QE +.P +As mmh sends outgoing mail via the local MTA only, +the best location to do such global rewrites is there. +Besides, the MTA is conceptionally the right location because it +does the reverse mapping for incoming mail (aliasing), too. +Further more, masquerading set up there is readily available for all +mail software on the system. +Hence, mmailid masquerading was removed. +.Ci 0836c8000ccb34b59410ef1c15b1b7feac70ce5f +.P +The +.I username_extension +masquerading type did not replace the username but would append a suffix, +specified by the +.Ev USERNAME_EXTENSION +environment variable, to it. +This provided support for the +.I user-extension +feature of qmail and the similar +.I "plussed user +processing of sendmail. +The decision to remove this username_extension masquerading was +motivated by the fact that +.Pn spost +hadn't supported it already. +.Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9 +Username extensions are possible in mmh, but less convenient to use. +.\" XXX format file %(getenv USERNAME_EXTENSION) +.P +The +.I draft_from +masquerading type instructed +.Pn post +to use the value of the +.Hd From +header field as SMTP envelope sender. +Sender addresses could be replaced completely. +.Ci b14ea6073f77b4359aaf3fddd0e105989db9 +Mmh offers a kind of masquerading similar in effect, but +with technical differences. +As mmh does not transfer messages itself, the local MTA has final control +over the sender's address. Any masquerading mmh introduces may be reverted +by the MTA. +In times of pedantic spam checking, an MTA will take care to use +sensible envelope sender addresses to keep its own reputation up. +Nonetheless, the MUA can set the +.Hd From +header field and thereby propose +a sender address to the MTA. +The MTA may then decide to take that one or generate the canonical sender +address for use as envelope sender address. +.P +In mmh, the MTA will always extract the recipient and sender from the +message header (\c +.Pn sendmail 's +.Sw -t +switch). +The +.Hd From +header field of the draft may be set arbitrary by the user. +If it is missing, the canonical sender address will be generated by the MTA. + +.U3 "Remaining Options +.P +Two configure options remain in mmh. +One is the locking method to use: +.Sw --with-locking=[dot|fcntl|flock|lockf] . +The idea of removing all methods except the portable dot locking +and having that one as the default is appealing, but this change +requires deeper technical investigation into the topic. +The other option, +.Sw --enable-debug , +compiles the programs with debugging symbols and does not strip them. +This option is likely to stay. + + + + +.H2 "Command Line Switches +.P +The command line switches of MH tools follow the X Window style. +They are words, introduced by a single dash. +For example: +.Cl "-truncate" . +Every program in mmh has two generic switches: +.Sw -help , +to print a short message on how to use the program, and +.Sw -Version , +to tell what version of mmh the program belongs to. +.P +Switches change the behavior of programs. +Programs that do one thing in one way require no switches. +In most cases, doing something in exactly one way is too limiting. +If there is basically one task to accomplish, but it should be done +in various ways, switches are a good approach to alter the behavior +of a program. +Changing the behavior of programs provides flexibility and customization +to users, but at the same time it complicates the code, documentation and +usage of the program. +.\" XXX: Ref +Therefore, the number of switches should be kept small. +A small set of well-chosen switches does no harm. +But usually, the number of switches increases over time. +Already in 1985, Rose and Romine have identified this as a major +problem of MH: +.[ [ +rose romine real work +.], p. 12] +.QS +A complaint often heard about systems which undergo substantial development +by many people over a number of years, is that more and more options are +introduced which add little to the functionality but greatly increase the +amount of information a user needs to know in order to get useful work done. +This is usually referred to as creeping featurism. +.QP +Unfortunately MH, having undergone six years of off-and-on development by +ten or so well-meaning programmers (the present authors included), +suffers mightily from this. +.QE +.P +Being reluctant to adding new switches \(en or `options', +as Rose and Romine call them \(en is one part of a counter-action, +the other part is removing hardly used switches. +Nmh's tools had lots of switches already implemented, +hence, cleaning up by removing some of them was the more important part +of the counter-action. +Removing existing functionality is always difficult because it +breaks programs that use these functions. +Also, for every obsolete feature, there'll always be someone who still +uses it and thus opposes its removal. +This puts the developer into the position, +where sensible improvements to style are regarded as destructive acts. +Yet, living with the featurism is far worse, in my eyes, because +future needs will demand adding further features, +worsening the situation more and more. +Rose and Romine added in a footnote, +``[...] +.Pn send +will no doubt acquire an endless number of switches in the years to come.'' +Although clearly humorous, the comment points to the nature of the problem. +Refusing to add any new switches would encounter the problem at its root, +but this is not practical. +New needs will require new switches and it would be unwise to block +them strictly. +Nevertheless, removing obsolete switches still is an effective approach +to deal with the problem. +Working on an experimental branch without an established user base, +eased my work because I did not offend users when I removed existing +funtions. +.P +Rose and Romine counted 24 visible and 9 more hidden switches for +.Pn send . +In nmh, they increased up to 32 visible and 12 hidden ones. +At the time of writing, no more than 7 visible switches and 1 hidden switch +have remained in mmh's +.Pn send . +(These numbers include two generic switches, help and version.) +.P +Fig. XXX +.\" XXX Ref +displays the number of switches for each of the tools that is available +in both, nmh and mmh. +The tools are sorted by the number of switches they had in nmh. +Visible and hidden switches were counted, +but not the generic help and version switches. +Whereas in the beginning of the project, the average tool had 11 switches, +now it has no more than 5 \(en only half as many. +If the `no' switches and similar inverse variant are folded onto +their counter-parts, the average tool had 8 switches in pre-mmh times and +has 4 now. +The total number of functional switches in mmh dropped from 465 +to 234. + +.KS +.in 1c +.so input/switches.grap +.KE + +.P +A part of the switches vanished after functions were removed. +This was the case for network mail transfer, for instance. +Sometimes, however, the work flow was the other way: +I looked through the +.Mp mh-chart (7) +man page to identify the tools with apparently too many switches. +Then considering the value of each of the switches by examining +the tool's man page and source code, aided by recherche and testing. +This way, the removal of functions was suggested by the aim to reduce +the number of switches per command. + + +.U3 "Draft Folder Facility +.P +A change early in the project was the complete transition from +the single draft message to the draft folder facility. +.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 +The draft folder facility was introduced in the mid-Eighties, when +Rose and Romine called it a ``relatively new feature''. +.[ +rose romine real work +.] +Since then, the facility had existed but was deactivated by default. +The default activation and the related rework of the tools made it +possible to remove the +.Sw -[no]draftfolder , +and +.Sw -draftmessage +switches from +.Pn comp , +.Pn repl , +.Pn forw , +.Pn dist , +.Pn whatnow , +and +.Pn send . +.Ci 337338b404931f06f0db2119c9e145e8ca5a9860 +The only flexibility removed with this change is having multiple +draft folders within one profile. +I consider this a theoretical problem only. +In the same go, the +.Sw -draft +switch of +.Pn anno , +.Pn refile , +and +.Pn send +was removed. +The special-casing of `the' draft message became irrelevant after +the rework of the draft system. +(See Sec. XXX.) +Equally, +.Pn comp +lost its +.Sw -file +switch. +The draft folder facility, together with the +.Sw -form +switch, are sufficient. + + +.U3 "In Place Editing +.P +.Pn anno +had the switches +.Sw -[no]inplace +to either annotate the message in place and thus preserve hard links, +or annotate a copy to replace the original message, breaking hard links. +Following the assumption that linked messages should truly be the +same message, and annotating it should not break the link, the +.Sw -[no]inplace +switches were removed and the previous default +.Sw -inplace +was made the only behavior. +.Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0 +The +.Sw -[no]inplace +switches of +.Pn repl , +.Pn forw , +and +.Pn dist +could be removed, too, as they were simply passed through to +.Pn anno . +.P +.Pn burst +also had +.Sw -[no]inplace +switches, but with different meaning. +With +.Sw -inplace , +the digest had been replaced by the table of contents (i.e. the +introduction text) and the bursted messages were placed right +after this message, renumbering all following messages. +Also, any trailing text of the digest was lost, though, +in practice, it usually consists of an end-of-digest marker only. +Nontheless, this behavior appeared less elegant than the +.Sw -noinplace +behavior, which already had been the default. +Nmh's +.Mp burst (1) +man page reads: +.sp \n(PDu +.QS +If -noinplace is given, each digest is preserved, no table +of contents is produced, and the messages contained within +the digest are placed at the end of the folder. Other messages +are not tampered with in any way. +.QE +.LP +The decision to drop the +.Sw -inplace +behavior was supported by the code complexity and the possible data loss +it caused. +.Sw -noinplace +was chosen to be the definitive behavior. +.Ci 68a686adeb39223a5e1ad35e4a24890ec053679d + + +.U3 "Forms and Format Strings +.P +Historically, the tools that had +.Sw -form +switches to supply a form file had +.Sw -format +switches as well to supply the contents of a form file as a string +on the command line directly. +In consequence, the following two lines equaled: +.VS +scan -form scan.mailx +scan -format "`cat .../scan.mailx`" +VE +The +.Sw -format +switches were dropped in favor for extending the +.Sw -form +switches. +.Ci f51956be123db66b00138f80464d06f030dbb88d +If their argument starts with an equal sign (`='), +then the rest of the argument is taken as a format string, +otherwise the arguments is treated as the name of a format file. +Thus, now the following two lines equal: +.VS +scan -form scan.mailx +scan -form "=`cat .../scan.mailx`" +VE +This rework removed the prefix collision between +.Sw -form +and +.Sw -format . +Now, typing +.Sw -fo +suffices to specify form or format string. +.P +The different meaning of +.Sw -format +for +.Pn repl +and +.Pn forw +was removed in mmh. +.Pn forw +was completely switched to MIME-type forwarding, thus removing the +.Sw -[no]format . +.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1 +For +.Pn repl , +the +.Sw -[no]format +switches were reworked to +.Sw -[no]filter +switches. +.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6 +The +.Sw -format +switches of +.Pn send +and +.Pn post , +which had a third meaning, +were removed likewise. +.Ci f3cb7cde0e6f10451b6848678d95860d512224b9 +Eventually, the ambiguity of the +.Sw -format +switches was resolved by not anymore having any such switch in mmh. + + +.U3 "MIME Tools +.P +The MIME tools, which were once part of +.Pn mhn +[sic!], +had several switches that added little practical value to the programs. +The +.Sw -[no]realsize +switches of +.Pn mhbuild +and +.Pn mhlist +were removed, doing real size calculations always now +.Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c , +as +``This provides an accurate count at the expense of a small delay.'' +This small delay is not noticable on modern systems. +.P +The +.Sw -[no]check +switches were removed together with the support for +.Hd Content-MD5 +header fields. +.[ +rfc 1864 +.] +.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda +(See Sec. XXX) +.P +The +.Sw -[no]ebcdicsafe +and +.Sw -[no]rfc934mode +switches of +.Pn mhbuild +were removed because they are considered obsolete. +.Ci 01a3480928da485b4d6109d36d751dfa71799d58 +.Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88 +.P +Content caching of external MIME parts, activated with the +.Sw -rcache +and +.Sw -wcache +switches was completely removed. +.Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269 +External MIME parts are rare today, having a caching facility +for them is appears to be unnecessary. +.P +In pre-MIME times, +.Pn mhl +had covered many tasks that are part of MIME handling today. +Therefore, +.Pn mhl +could be simplified to a large extend, reducing the number of its +switches from 21 to 6. +.Ci 350ad6d3542a07639213cf2a4fe524e829c1e7b6 +.Ci 0e46503be3c855bddaeae3843e1b659279c35d70 + + +.U3 "Mail Transfer Switches +.P +With the removal of the mail transfer facilities, a lot of switches +vanished automatically. +.Pn inc +lost 9 switches, namely +.Sw -host , +.Sw -port , +.Sw -user , +.Sw -proxy , +.Sw -snoop , +.Sw -[no]pack , +as well as +.Sw -sasl +and +.Sw -saslmech . +.Pn send +and +.Pn post +lost 11 switches each, namely +.Sw -server , +.Sw -port , +.Sw -client , +.Sw -user , +.Sw -mail , +.Sw -saml , +.Sw -send , +.Sw -soml , +.Sw -snoop , +as well as +.Sw -sasl , +.Sw -saslmech , +and +.Sw -tls . +.Pn send +had the switches only to pass them further to +.Pn post , +because the user would invoke +.Pn post +not directly, but through +.Pn send . +All these switches, except +.Sw -snoop +were usually defined as default switches in the user's profile, +but hardly given in interactive usage. +.P +Of course, those switches did not really ``vanish'', but the configuration +they did was handed over to external MSAs and MRAs. +Instead of setting up the mail transfer in mmh, it is set up in +external tools. +Yet, this simplifies mmh. +Specialized external tools will likely have simple configuration files. +Hence, instead of having one complicated central configuration file, +the configuration of each domain is separate. +Although the user needs to learn to configure each of the tools, +each configuration is likely much simpler. + + +.U3 "Maildrop Formats +.P +With the removal of MMDF maildrop format support, +.Pn packf +and +.Pn rcvpack +no longer needed their +.Sw -mbox +and +.Sw -mmdf +switches. +.Sw -mbox +is the sole behavior now. +.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0 +In the same go, +.Pn packf +and +.Pn rcvpack +were reworked (see Sec. XXX) and their +.Sw -file +switch became unnecessary. +.Ci ca1023716d4c2ab890696f3e41fa0d94267a940e + + +.U3 "Terminal Magic +.P +Mmh's tools will no longer clear the screen (\c +.Pn scan 's +and +.Pn mhl 's +.Sw -[no]clear +switches +.Ci e57b17343dcb3ff373ef4dd089fbe778f0c7c270 +.Ci 943765e7ac5693ae177fd8d2b5a2440e53ce816e ). +Neither will +.Pn mhl +ring the bell (\c +.Sw -[no]bell +.Ci e11983f44e59d8de236affa5b0d0d3067c192e24 ) +nor page the output itself (\c +.Sw -length +.Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ). +.P +Generally, the pager to use is no longer specified with the +.Sw -[no]moreproc +command line switches for +.Pn mhl +and +.Pn show /\c +.Pn mhshow . +.Ci 39e87a75b5c2d3572ec72e717720b44af291e88a +.P +.Pn prompter +lost its +.Sw -erase +and +.Sw -kill +switches because today the terminal cares for the line editing keys. + + +.U3 "Header Printing +.P +.Pn folder 's +data output is self-explaining enough that +displaying the header line makes few sense. +Hence, the +.Sw -[no]header +switch was removed and headers are never printed. +.Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7 +.P +In +.Pn mhlist , +the +.Sw -[no]header +switches were removed, too. +.Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f +But in this case headers are always printed, +because the output is not self-explaining. +.P +.Pn scan +also had +.Sw -[no]header +switches. +Printing the header had been sensible until the introduction of +format strings made it impossible to display the column headings. +Only the folder name and the current date remained to be printed. +As this information can be perfectly retrieved by +.Pn folder +and +.Pn date , +consequently, the switches were removed. +.Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e +.P +By removing all +.Sw -header +switches, the collision with +.Sw -help +on the first two letters was resolved. +Currently, +.Sw -h +evaluates to +.Sw -help +for all tools of mmh. + + +.U3 "Suppressing Edits or the WhatNow Shell +.P +The +.Sw -noedit +switch of +.Pn comp , +.Pn repl , +.Pn forw , +.Pn dist , +and +.Pn whatnow +was removed, but it can now be replaced by specifying +.Sw -editor +with an empty argument. +.Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9 +(Specifying +.Cl "-editor true +is nearly the same, only differing by the previous editor being set.) +.P +The more important change is the removal of the +.Sw -nowhatnowproc +switch. +.Ci ee4f43cf2ef0084ec698e4e87159a94c01940622 +This switch had introduced an awkward behavior, as explained in nmh's +man page for +.Mp comp (1): +.QS +The \-editor editor switch indicates the editor to use for +the initial edit. Upon exiting from the editor, comp will +invoke the whatnow program. See whatnow(1) for a discussion +of available options. The invocation of this program can be +inhibited by using the \-nowhatnowproc switch. (In truth of +fact, it is the whatnow program which starts the initial +edit. Hence, \-nowhatnowproc will prevent any edit from +occurring.) +.QE +.P +Effectively, the +.Sw -nowhatnowproc +switch creates only a draft message. +As +.Cl "-whatnowproc true +causes the same behavior, the +.Sw -nowhatnowproc +switch was removed for being redundant. +Likely, the +.Sw -nowhatnowproc +switch was intended to be used by front-ends. + + +.U3 "Compatibility Switches +.BU +The hidden +.Sw -[no]total +switches of +.Pn flist . +They were simply the inverse of the visible +.Sw -[no]fast +switches: +.Sw -total +was +.Sw -nofast +and +.Sw -nototal +was +.Sw -fast . +I removed the +.Sw -[no]total +legacy. +.Ci ea21fe2c4bd23c639bef251398fae809875732ec +.BU +The +.Sw -subject +switch of +.Pn sortm +existed for compatibility only. +It can be fully replaced by +.Cl "-textfield subject +thus it was removed. +.Ci 00140a3c86e9def69d98ba2ffd4d6e50ef6326ea + + +.U3 "Various +.BU +In order to avoid prefix collisions among switch names, the +.Sw -version +switch was renamed to +.Sw -Version +(with capital `V'). +.Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a +Every program has the +.Sw -version +switch but its first three letters collided with the +.Sw -verbose +switch, present in many programs. +The rename solved this problem once for all. +Although this rename breaks a basic interface, having the +.Sw -V +abbreviation to display the version information, isn't all too bad. +.BU +.Sw -[no]preserve +of +.Pn refile +was removed because what use was it anyway? +.QS +Normally when a message is refiled, for each destination +folder it is assigned the number which is one above the current +highest message number in that folder. Use of the +\-preserv [sic!] switch will override this message renaming, and try +to preserve the number of the message. If a conflict for a +particular folder occurs when using the \-preserve switch, +then refile will use the next available message number which +is above the message number you wish to preserve. +.QE +.BU +The removal of the +.Sw -[no]reverse +switches of +.Pn scan +.Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173 +is a bug fix, supported by the comments +``\-[no]reverse under #ifdef BERK (I really HATE this)'' +by Rose and +``Lists messages in reverse order with the `\-reverse' switch. +This should be considered a bug.'' by Romine in the documentation. +The question remains why neither Rose and Romine had fixed this +bug in the Eighties when they wrote these comments nor has anyone +thereafter. + + +.ig + +forw: [no]dashstuffing(mhl) + +mhshow: [no]pause [no]serialonly + +mhmail: resent queued +inc: snoop, (pop) + +mhl: [no]faceproc folder sleep + [no]dashstuffing(forw) digest list volume number issue number + +prompter: [no]doteof + +refile: [no]preserve [no]unlink [no]rmmproc + +send: [no]forward [no]mime [no]msgid + [no]push split [no]unique (sasl) width snoop [no]dashstuffing + attach attachformat +whatnow: (noedit) attach + +slocal: [no]suppressdups + +spost: [no]filter [no]backup width [no]push idanno + [no]check(whom) whom(whom) + +whom: ??? + +.. + + +.ig + +.P +In the best case, all switches are unambiguous on the first character, +or on the three-letter prefix for the `no' variants. +Reducing switch prefix collisions, shortens the necessary prefix length +the user must type. +Having less switches helps best. + +.. + + +.\" XXX: whatnow prompt commands + + + + +.H1 "Modernizing +.P +The code base of mmh originates from the late Seventies. +Through the Eighties, extensive work had been done on it. +In the Nineties, it had been partly reorganized and extended. +Relicts from each decade have gathered in the code base. +My goal was to modernize the code base. + +.P +FIXME functional aspect only here +.P +FIXME ref to `code style' for non-functional aspects. + + +.H2 "Code Relicts +.P +My position to drop obsolete functionality of mmh to remove old code +is much more revolutional than the nmh community likes to have it. +Working on an experimental version, I was able to quickly drop +functionality I considered ancient. +The need for consensus with peers would have slowed this process down. +Without the need to justify my decisions, I was able to rush forward. +In Dezember 2011, Paul Vixie motivated the nmh developers to just +do the work: +.[ +paul vixie edginess nmh-workers +.] +.QS +let's stop walking on egg shells with this code base. there's no need to +discuss whether to keep using vfork, just note in [sic!] passing, [...] +we don't need a separate branch for removing vmh +or ridding ourselves of #ifdef's or removing posix replacement functions +or depending on pure ansi/posix "libc". +.QP +these things should each be a day or two of work and the "main branch" +should just be modern. [...] +let's push forward, aggressively. +.QE +.LP +I did so already in the months before. +I pushed forward. +I simply dropped the cruft. +.P +The decision to drop a feature was based on literature research and +careful thinking, but whether having had contact to this particular +feature within my own computer life served as a rule of thumb. +My reasons are always made clean in the commit message for the +version control system. +Hence, others can comprehend my view and argue for undoing the change +if I have missed an important aspect. + + +.U3 "Forking +.P +In being a tool chest, MH creates many processes. +In earlier times +.Fu fork() +had been an expensive system call, because the process's image needed +to be duplicated completely at once. +This was especially painfull in the common case when the image gets +replaced by a call to +.Fu exec() +right after having forked the child process. +The +.Fu vfork() +system call was invented to speed up this particular case. +It completely omits the duplication of the image. +On old systems this resulted in significant speed ups. +Therefore MH used +.Fu vfork() +whenever possible. +.P +Modern memory management units support copy-on-write semantics, which make +.Fu fork() +almost as fast as +.Fu vfork() . +The man page of +.Mp vfork (2) +in FreeBSD 8.0 states: +.QS +This system call will be eliminated when proper system sharing mechanisms +are implemented. Users should not depend on the memory sharing semantics +of vfork() as it will, in that case, be made synonymous to fork(2). +.QE +.LP +Vixie supports the removal with the note that ``the last +system on which fork was so slow that an mh user would notice it, was +Eunice. that was 1987''. +.[ +nmh-workers vixie edginess +.] +I replaced all calls to +.Fu vfork() +with calls to +.Fu fork() . +.P +Related to the costs of +.Fu fork() +is the probability of its success. +In the Eighties on heavy loaded systems, calls to +.Fu fork() +were prone to failure. +Hence, many of the +.Fu fork() +calls in the code were wrapped into loops to retry the +.Fu fork() +several times, for higher changes to succeed, eventually. +On modern systems, failing calls to +.Fu fork() +are unusual. +Hence, in the rare case when +.Fu fork() +fails, mmh programs simply abort. + + +.U3 "Obsolete Header Fields +.BU +The +.Hd Encrypted +header field was introduced by RFC\|822, +but already marked legacy in RFC\|2822. +OpenPGP provides the basis for standardized exchange of encrypted +messages [RFC\|4880, RFC\|3156]. +The support for +.Hd Encrypted +header fields is removed in mmh. +.BU +Native support for +.Hd Face +header fields has been removed, as well. +This feature is similar to the +.Hd X-Face +header field in its intent, +but takes a different approach to store the image. +Instead of encoding the image data directly into the header field, +the it contains the hostname and UDP port where the image +date could be retrieved. +There is even a third system, invented in 2005. +Although it re-uses the +.Hd Face +header field, it is the successor of +.Hd X-Face +with support for colored PNG images. +None of the Face systems described here is popular today. +Hence, mmh has no direct support for them. +.BU +The +.Hd Content-MD5 +header field was introduced by RFC\|1864. +It provides detection of data corruption during the transfer. +But it can not ensure verbatim end-to-end delivery of the contents +[RFC\|1864]. +The proper approach to verify content integrity in an +end-to-end relationship is the use of digital cryptography. +.\" XXX (RFCs FIXME). +On the other hand, transfer protocols should detect corruption during +each transmission. The TCP includes a checksum field therefore. +These two approaches in combinations render the +.Hd Content-MD5 +header field superfluous. +The nmh-workers mailing list archive contains about 4\|200 messages, +ranging from 1992 until today. +Not a single one had a +.Hd Content-MD5 +header field. +Neither did any of the 60\|000 messages in my personal mail storage. +Removing the support for this header field, +removed the last place where MD5 computation was needed. +Hence, the MD5 code could be removed as well. +Over 500 lines of code vanished by this one change. + + +.U3 "MMDF maildrop support +.P +This type of format is conceptionally similar to the mbox format, +but uses a different message delimiter (`\fL^A^A^A^A\fP' instead of +`\fLFrom\0\fP'). +Mbox is the de-facto standard maildrop format on Unix, +whereas the MMDF maildrop format is hardly still known today. +I did drop MMDF maildrop format support. +.P +The simplifications within the code were only moderate. +Switches could be removed from +.L packf +and +.L rcvpack , +which generate packed mailboxes. +Only one packed mailbox format remained: mbox. +The more important changes affected the equally named mail parsing +routine in +.Fn sbr/m_getfld.c . +The MMDF code had been removed there, but as now only one packed mailbox +format is left, further code structure simplifications may be possible. +I have not worked on them yet because +.Fu m_getfld() +is heavily optimized and thus dangerous to touch. +The risk of damaging the intricate workings of the optimized code is +too high. +.\" XXX: move somewhere else +This problem is know to the developers of nmh, too. +They also avoid touching this minefield if possible. + + +.U3 "Prompter's Control Keys +.P +The program +.Pn prompter +queries the user to fill in a message form. +When used by +.Pn comp +as +.Cl "comp -editor prompter" , +the resulting behavior is similar to +.Pn mailx . +Apparently, +.Pn prompter +hadn't been touched lately. +Otherwise it's hardly explainable why it +still offered the switches +.Sw -erase +.Ar chr +and +.Sw -kill +.Ar chr +to name the characters for command line editing. +The times when this had been necessary are long time gone. +Today these things work out-of-the-box, and if not, are configured +with the standard tool +.Pn stty . +The switches are removed now +.Ci 0bd9750710cdbab80cfb4036dd87af20afe1552f . + + +.U3 "Hardcopy terminal support +.P +More of a funny anecdote is a check for printing to a +hardcopy terminal that remained in the code until Spring 2012, +when I finally removed it +.Ci b7764c4a6b71d37918a97594d866258f154017ca . +I surely would be very happy to see such a terminal in action, +maybe actually being able to work on it, but I fear my chances are null. +.P +The check only prevented a pager to be placed between the outputting +program (\c +.Pn mhl ) +and the terminal. +In nmh, this could have been ensured with the +.Sw -nomoreproc +at the command line statically, too. +In mmh, set the profile entry +.Pe Pager +or the environment variable +.Ev PAGER +to +.Pn cat . + + + + +.H2 "Attachments +.P +The mind model of email attachments is unrelated to MIME. +Although the MIME RFCs (2045 through 2049) define the technical +requirements for having attachments, they do not mention the the word +``attachment''. +Instead of attachments, MIME talks about ``multi-part message bodies'' +[RFC\|2045], a more general concept. +Multi-part messages are messages +``in which one or more different +sets of data are combined in a single body'' +[RFC\|2046]. +MIME keeps its descriptions generic; +it does not imply specific usage models. +In email one usage model became prevalent: attachments. +The idea is having a main text document with files of arbitrary kind +attached to it. +In MIME terms, this is a multi-part message having a text part first +and parts of arbitray type following. +.P +MH's MIME support is a direct implementation of the RFCs. +The perception of the topic described in the RFCs is clearly visible +in MH's implementation. +Thus, MH had all the MIME features but no idea of attachments. +Today, however, users don't need all the MIME features but they want +convenient attachment handling. + +.U3 "Composing MIME Messages +.P +In order to improve the situation on the message composing side, +Jon Steinhart had added an attachment system to nmh in 2002. +.Ci 7480dbc14bc90f2d872d434205c0784704213252 +In the file +.Fn docs/README-ATTACHMENTS , +he described his motivation to do so as such: +.QS +Although nmh contains the necessary functionality for MIME message handing, +the interface to this functionality is pretty obtuse. +There's no way that I'm ever going to convince my partner to write +.Pn mhbuild +composition files! +.QE +.LP +With this change, the mind model of attachments entered nmh. +In the same document: +.QS +These changes simplify the task of managing attachments on draft files. +They allow attachments to be added, listed, and deleted. +MIME messages are automatically created when drafts with attachments +are sent. +.QE +.LP +Unfortunately, the attachment system, +like any new facilities in nmh, +was deactive by default. +.P +During my work in Argentina, I tried to improve the attachment system. +But, because of great opposition in the nmh community, +my patch died as a proposal on the mailing list, after long discussions. +.[ +nmh-workers attachment proposal +.] +In Januar 2012, I extended the patch and applied it to mmh. +.Ci 8ff284ff9167eff8f5349481529332d59ed913b1 +In mmh, the attachment system is active by default. +Instead of command line switches, the +.Pe Attachment-Header +profile entry is used to specify +the name of the attachment header field. +It is pre-defined to +.Hd Attach . +.P +To add an attachment to a draft, simply add an attachment header: +.VS +To: bob +Subject: The file you wanted +Attach: /path/to/the/file-bob-wanted +-------- +Here it is. +VE +The header field can be added to the draft manually in the editor, +or by using the `attach' command at the WhatNow prompt, or +non-interactively with +.Pn anno : +.VS +anno -append -nodate -component Attach -text /path/to/attachment +VE +Drafts with attachment headers are converted to MIME automatically by +.Pn send . +The conversion to MIME is invisible to the user. +The draft stored in the draft folder is always in source form, with +attachment headers. +If the MIMEification fails, for instance because the file to attach +is not accessible, the original draft is not changed. +.P +The attachment system handles the forwarding of messages, too. +If the attachment header value starts with a plus character (`+'), +like in +.Cl "Attach: +bob 30 42" , +The given messages in the specified folder will be attached. +This allowed to simplify +.Pn forw . +.Ci f41f04cf4ceca7355232cf7413e59afafccc9550 +.P +Closely related to attachments is non-ASCII text content, +because it requires MIME too. +In nmh, the user needed to call `mime' at the WhatNow prompt +to have the draft converted to MIME. +This was necessary whenever the draft contained non-ASCII characters. +If the user did not call `mime', a broken message would be sent. +Therefore, the +.Pe automimeproc +profile entry could be specified to have the `mime' command invoked +automatically each time. +Unfortunately, this approach conflicted with with attachment system +because the draft would already be in MIME format at the time +when the attachment system wanted to MIMEify it. +To use nmh's attachment system, `mime' must not be called at the +WhatNow prompt and +.Pe automimeproc +must not be set in the profile. +But then the case of non-ASCII text without attachment headers was +not caught. +All in all, the solution was complex and irritating. +My patch from December 2010 would have simplified the situation. +.P +Mmh's current solution is even more elaborate. +Any necessary MIMEification is done automatically. +There is no `mime' command at the WhatNow prompt anymore. +The draft will be converted automatically to MIME when either an +attachment header or non-ASCII text is present. +Further more, the special meaning of the hash character (`#') +at line beginnings in the draft message is removed. +Users need not at all deal with the whole topic. +.P +Although the new approach does not anymore support arbitrary MIME +compositions directly, the full power of +.Pn mhbuild +can still be accessed. +Given no attachment headers are included, the user can create +.Pn mhbuild +composition drafts like in nmh. +Then, at the WhatNow prompt, he needs to invoke +.Cl "edit mhbuild +to convert it to MIME. +Because the resulting draft does neither contain non-aASCII characters +nor has it attachment headers, the attachment system will not touch it. +.P +The approach taken in mmh is taylored towards todays most common case: +a text part with possibly attachments. +This case is simplified a lot for users. + +.U3 "MIME Type Guessing +.P +The use of +.Pn mhbuild +composition drafts had one notable advantage over attachment headers +from the programmer's point of view: The user provides the appropriate +MIME types for files to include. +The attachment system needs to find out the correct MIME type itself. +This is a difficult task, yet it spares the user irritating work. +Determining the correct MIME type of content is partly mechanical, +partly intelligent work. +Forcing the user to find out the correct MIME type, +forces him to do partly mechanical work. +Letting the computer do the work, can lead to bad choices for difficult +content. +For mmh, the latter option was chosen. +.P +Determining the MIME type by the suffix of the file name is a dumb +approach, yet it is simple to implement and provides good results +for the common cases. +Mmh implements this approach in the +.Pn print-mimetype +script. +Using it is the default choice. +.P +A far better but less portable approach is the use of +.Pn file . +This standard tool tries to determine the type of files. +Unfortunately, its capabilities and accuracy varies from system to system. +Additionally, its output was only intended for human beings, +but not to be used by programs. +It varies much. +Nevertheless, modern versions of GNU +.Pn file , +which is prevalent on the popular GNU/Linux systems, +provides MIME type output in machine-readable form. +Although this solution is highly system-dependent, +it solves the difficult problem well. +On systems where GNU +.Pn file , +version 5.04 or higher, is available it should be used. +One needs to specify the following profile entry to do so: +.VS +Mime-Type-Query: file -b --mime +VE +.LP +Other versions of +.Pn file +might possibly be usable with wrapper scripts to reformat the output. +The diversity among +.Pn file +implementations is great; one needs to check the local variant. +.P +If no MIME type can be determined, text content gets sent as +`text/plain' and anything else under the generic fall-back type +`application/octet-stream'. +It is not possible in mmh to override the automatic MIME type guessing +for a specific file. +To do so, the user would need to know in advance for which file +the automatic guessing does fail, or the system would require interaction. +I consider both cases impractical. +The existing solution should be sufficient. +If not, the user may always fall back to +.Pn mhbuild +composition drafts and ignore the attachment system. + + +.U3 "Storing Attachments +.P +FIXME + + +.U3 "Showing MIME Messages +.P +FIXME + + + +.H2 "Digital Cryptography +.P +Signing and encryption. + + + +.H2 "Modern Defaults +.P +Just to give one example, for me it took one year of using nmh +before I became aware of the existence of the attachment system. +One could argue that this fact disqualifies my reading of the +documentation. +If I would have installed nmh from source back then, I could agree. +Yet I had used a prepackaged version and had expected that it would +just work. + + + +.H1 "Code Style +.P +foo + + +.H2 "Standard Code +.P +POSIX + +.U3 "Converting to Standard Code +.P +One part of this task was converting obsolete code constructs +to standard constructs. +As I'm not even thirty years old and have no more than seven years of +Unix experience, I needed to learn about the history in retrospective. +Older people likely have used those ancient constructs themselves +and have suffered from their incompatibilities and have longed for +standardization. +Unfortunately, I have only read that others had done so. +This put me in a much more difficult positions when working on the old +code. +I needed to recherche what other would have known by heart from +experience. +All my programming experience comes from a time past ANSI C +and past POSIX. +Although I knew about the times before, I took the +current state implicitly for granted most of the time. +.P +Being aware of +these facts, I rather let people with more historic experience solve the +task of converting the ancient code constructs to standardized ones. +Luckily, Lyndon Nerenberg focused on this task at the nmh project. +He converted large parts of the code to POSIX constructs, removing +the conditionals compilation for now standardized features. +I'm thankful for this task being solved. +I only pulled the changes into +mmh. + + + + +.H2 "Separation + +.U2 "MH Directory Split +.P +In MH and nmh, a personal setup had consisted of two parts: +The MH profile, named +.Fn \&.mh_profile +and being located directly in the user's home directory. +And the MH directory, where all his mail messages and also his personal +forms, scan formats, other configuration files are stored. +The location +of this directory could be user-chosen. +The default was to name it +.Fn Mail +and have it directly in the home directory. +.P +I've never liked the data storage and the configuration to be intermixed. +They are different kinds of data. +One part, are the messages, +which are the data to operate on. +The other part, are the personal +configuration files, which are able to change the behavior of the operations. +The actual operations are defined in the profile, however. +.P +When storing data, one should try to group data by its type. +There's sense in the Unix file system hierarchy, where configuration +file are stored separate (\c +.Fn /etc ) +to the programs (\c +.Fn /bin +and +.Fn /usr/bin ) +to their sources (\c +.Fn /usr/src ). +Such separation eases the backup management, for instance. +.P +In mmh, I've reorganized the file locations. +Still there are two places: +There's the mail storage directory, which, like in MH, contains all the +messages, but, unlike in MH, nothing else. +Its location still is user-chosen, with the default name +.Fn Mail , +in the user's home directory. +This is much similar to the case in nmh. +The configuration files, however, are grouped together in the new directory +.Fn \&.mmh +in the user's home directory. +The user's profile now is a file, named +.Fn profile , +in this mmh directory. +Consistently, the context file and all the personal forms, scan formats, +and the like, are also there. +.P +The naming changed with the relocation. +The directory where everything, except the profile, had been stored (\c +.Fn $HOME/Mail ), +used to be called \fIMH directory\fP. +Now, this directory is called the +user's \fImail storage\fP. +The name \fImmh directory\fP is now given to +the new directory +(\c +.Fn $HOME/.mmh ), +containing all the personal configuration files. +.P +The separation of the files by type of content is logical and convenient. +There are no functional differences as any possible setup known to me +can be implemented with both approaches, although likely a bit easier +with the new approach. +The main goal of the change had been to provide +sensible storage locations for any type of personal mmh file. +.P +In order for one user to have multiple MH setups, he can use the +environment variable +.Ev MH +the point to a different profile file. +The MH directory (mail storage plus personal configuration files) is +defined by the +.Pe Path +profile entry. +The context file could be defined by the +.Pe context +profile entry or by the +.Ev MHCONTEXT +environment variable. +The latter is useful to have a distinct context (e.g. current folders) +in each terminal window, for instance. +In mmh, there are three environment variables now. +.Ev MMH +may be used to change the location of the mmh directory. +.Ev MMHP +and +.Ev MMHC +change the profile and context files, respectively. +Besides providing a more consistent feel (which simply is the result +of being designed anew), the set of personal configuration files can +be chosen independently from the profile (including mail storage location) +and context, now. +Being it relevant for practical use or not, it +de-facto is an improvement. +However, the main achievement is the +split between mail storage and personal configuration files. + + +.H2 "Modularization +.P +whatnowproc +.P +The \fIMH library\fP +.Fn libmh.a +collects a bunch of standard functions that many of the MH tools need, +like reading the profile or context files. +This doesn't hurt the separation. + + +.H2 "Style +.P +Code layout, goto, ... + +.P +anno rework + + + + +.H1 "Concept Exploitation/Homogeneity + + +.H2 "Draft Folder +.P +Historically, MH provided exactly one draft message, named +.Fn draft +and +being located in the MH directory. +When starting to compose another message +before the former one was sent, the user had been questioned whether to use, +refile or replace the old draft. +Working on multiple drafts at the same time +was impossible. +One could only work on them in alteration by refiling the +previous one to some directory and fetching some other one for reediting. +This manual draft management needed to be done each time the user wanted +to switch between editing one draft to editing another. +.P +To allow true parallel editing of drafts, in a straight forward way, the +draft folder facility exists. +It had been introduced already in July 1984 +by Marshall T. Rose. +The facility was deactivated by default. +Even in nmh, the draft folder facility remained deactivated by default. +At least, Richard Coleman added the man page +.Mp mh-draft(5) +to document +the feature well. +.P +The only advantage of not using the draft folder facility is the static +name of the draft file. +This could be an issue for MH front-ends like mh-e. +But as they likely want to provide working on multiple drafts in parallel, +the issue is only concerning compatibility. +The aim of nmh to stay compatible +prevented the default activation of the draft folder facility. +.P +On the other hand, a draft folder is the much more natural concept than +a draft message. +MH's mail storage consists of folders and messages, +the messages named with ascending numbers. +A draft message breaks with this +concept by introducing a message in a file named +.Fn draft . +This draft +message is special. +It can not be simply listed with the available tools, +but instead requires special switches. +I.e. corner-cases were +introduced. +A draft folder, in contrast, does not introduce such +corner-cases. +The available tools can operate on the messages within that +folder like on any messages within any mail folders. +The only difference +is the fact that the default folder for +.Pn send +is the draft folder, +instead of the current folder, like for all other tools. +.P +The trivial part of the change was activating the draft folder facility +by default and setting a default name for this folder. +Obviously, I chose +the name +.Fn +drafts . +This made the +.Sw -draftfolder +and +.Sw -draftmessage +switches useless, and I could remove them. +The more difficult but also the part that showed the real improvement, +was updating the tools to the new concept. +.Sw -draft +switches could +be dropped, as operating on a draft message became indistinguishable to +operating on any other message for the tools. +.Pn comp +still has its +.Sw -use +switch for switching between its two modes: (1) Compose a new +draft, possibly by taking some existing message as a form. +(2) Modify +an existing draft. +In either case, the behavior of +.Pn comp is +deterministic. +There is no more need to query the user. +I consider this +a major improvement. +By making +.Pn send +simply operate on the current +message in the draft folder by default, with message and folder both +overridable by specifying them on the command line, it is now possible +to send a draft anywhere within the storage by simply specifying its folder +and name. +.P +All theses changes converted special cases to regular cases, thus +simplifying the tools and increasing the flexibility. + + +.H2 "Trash Folder +.P +Similar to the situation for drafts is the situation for removed messages. +Historically, a message was deleted by renaming. +A specific +\fIbackup prefix\fP, often comma (\c +.Fn , ) +or hash (\c +.Fn # ), +being prepended to the file name. +Thus, MH wouldn't recognize the file +as a message anymore, as only files whose name consists of digits only +are treated as messages. +The removed messages remained as files in the +same directory and needed some maintenance job to truly delete them after +some grace time. +Usually, by running a command similar to +.VS +find /home/user/Mail -ctime +7 -name ',*' | xargs rm +VE +in a cron job. +Within the grace time interval +the original message could be restored by stripping the +the backup prefix from the file name. +If however, the last message of +a folder is been removed \(en say message +.Fn 6 +becomes file +.Fn ,6 +\(en and a new message enters the same folder, thus the same +numbered being given again \(en in our case +.Fn 6 +\(en, if that one +is removed too, then the backup of the former message gets overwritten. +Thus, the ability to restore removed messages does not only depend on +the ``sweeping cron job'' but also on the removing of further messages. +This is undesirable, because the real mechanism is hidden from the user +and the consequences of further removals are not always obvious. +Further more, the backup files are scattered within the whole mail +storage, instead of being collected at one place. +.P +To improve the situation, the profile entry +.Pe rmmproc +(previously named +.Pe Delete-Prog ) +was introduced, very early. +It could be set to any command, which would care for the mail removal +instead of taking the default action, described above. +Refiling the to-be-removed files to some garbage folder was a common +example. +Nmh's man page +.Mp rmm(1) +proposes +.Cl "refile +d +to move messages to the garbage folder and +.Cl "rm `mhpath +d all` +the empty the garbage folder. +Managing the message removal this way is a sane approach. +It keeps +the removed messages in one place, makes it easy to remove the backup +files, and, most important, enables the user to use the tools of MH +itself to operate on the removed messages. +One can +.Pn scan +them, +.Pn show +them, and restore them with +.Pn refile . +There's no more +need to use +.Pn mhpath +to switch over from MH tools to Unix tools \(en MH can do it all itself. +.P +This approach matches perfect with the concepts of MH, thus making +it powerful. +Hence, I made it the default. +And even more, I also +removed the old backup prefix approach, as it is clearly less powerful. +Keeping unused alternative in the code is a bad choice as they likely +gather bugs, by not being constantly tested. +Also, the increased code +size and more conditions crease the maintenance costs. +By strictly +converting to the trash folder approach, I simplified the code base. +.Pn rmm +calls +.Pn refile +internally to move the to-be-removed +message to the trash folder (\c +.Fn +trash +by default). +Messages +there can be operated on like on any other message in the storage. +The sweep clean, one can use +.Cl "rmm -unlink +trash a" , +where the +.Sw -unlink +switch causes the files to be truly unliked instead +of moved to the trash folder. + + +.H2 "Path Notations +.P +foo + + +.H2 "MIME Integration +.P +user-visible access to whole messages and MIME parts are inherently +different + + +.H2 "Of One Cast +.P
--- /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.
--- a/makefile Sat Jun 23 22:08:17 2012 +0200 +++ b/makefile Sat Jun 23 22:12:14 2012 +0200 @@ -1,6 +1,6 @@ NAME = thesis CHAPS = style front.roff dedication.roff abstract.roff toc.roff \ - preface.roff ch*.roff refs.roff + preface.roff intro.roff discussion.roff summary.roff refs.roff PDFFLAGS = -sPAPERSIZE=a4 -dPDFSETTINGS=/prepress all: $(NAME).ps
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/summary.roff Sat Jun 23 22:12:14 2012 +0200 @@ -0,0 +1,16 @@ +.H0 "Summary + +.P +Because of several circumstances, my experimental version is rather +a fork today, although this may change again in the future. + +.P +Although mmh bases on nmh, it is likely seen as a step backward. +I agree. +However, this step backward actually is a step forward, +although in a different direction. + +.P +.\" Top candidate for the final sentence: +This enabled me to follow my vision straightly and thus produce +a result of greater pureness.