.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 specilized 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 likely 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 homogenious 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 be focused 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 "Removal of the 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 in the view on the character of nmh
initiated the development of mmh.
Removing the mail transfer facilities had been the first work task
in the mmh project.
.P
The MSA is called \fIMessage Transfer Service\fP (MTS) in nmh.
The facility established network connections and spoke SMTP to submit
messages for relay to the outside world.
This part was implemented by the
.Pn post
command.
The changes in emailing in the last years
demanded changes in this part of nmh too.
Encryption and authetication 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 is clearly the better interface, but mmh does not provide it yet.
.\" XXX implement it
.P
To retrieve mail, the
.Pn inc
command 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 so on for any changes in mail transfer.
Mmh 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 there exist two paths for messages to enter mmh's mail storage:
(1) Mail can be incorporate 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.
Following the Unix philosophy, it now focuses on one job and
tries to do that one well.
Not only the programs follow that tenet but also the project itself does so.
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.
Now, an MSA or MRA is more complex than a text pager
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
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.
(\c
.Pn /bin/mail
had once covered anything there was to email and still had been small
and simple.)
Then 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 mail agents and separated the various tasks
because the existing tasks became more extensive and new tasks appeared.
Again, email systems grew, or they split parts off.
In nmh, for instance, the POP server, which the original MH had included,
was removed.
Now is the time to go one step further and remove the MSA and MRA, 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's 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
Function 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 will add
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 "Removal of 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 significently
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.
On 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 usecase 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 a 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 distinguished between old and new mail, but
this detail information and can be retrieved with
.Pn stat (1),
too.
A very small shell script could be written to output 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.
.P
Having less code (with equal readability, of course)
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, because including it is a violation
of the idea that mmh is a MUA only.
It should 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 .
The need to install a complete MH system to have
.Pn slocal
would be gone.
Likewise, mmh users could decide to use
.I procmail
without having a second, unused MDA,
.Pn slocal ,
installed.
That's conceptionally the best solution.
Yet,
.Pn slocal
is not split off.
I feel unsure with removing it from mmh.
Hence, I defer the decision over
.Pn slocal .
In the meanwhile
.Pn slocal
does not hurt because it is unrelated to the rest of mmh.


.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 formated.
For MIME, this approach wasn't sufficient anymore.
MIME messages can consist of multiple parts, some of which aren't
directly displayable, and text content might be encoded in
foreign charsets.
.Pn show 's
understanding of messages and
.Pn mhl 's
limited display facilities couldn't cope with the task any longer.
.P
Instead of extending these tools, additional tools were written from scratch
and then added to the MH tool chest. Doing so is encouraged by the
tool chest approach. The new tools could be added without interfering
with the existing ones.
Modular design is a great advantage for extending a system.
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 programs, which together covered the
multiple aspects of MIME. One of these resulting tools was
.Pn mhshow ,
which replaced the
.Cl "mhn -show
call.
It was capable to display a MIME message appropriately.
.P
From then on, two message display tools were part of nmh:
.Pn show
and
.Pn mhshow .
Because the user should not need to invoke the right tool
whether the message uses MIME or not,
.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 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.
(There was also a switch for
.Pn show
to never invoke
.Pn mhshow .
.Pn show
was able to display MIME messages if they contained only a single text
part.)
.P
Having two similar tools for essentially the same task is redundant.
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, than MIME messages are seen to be an extension to
original email.
As
.Pn mhshow
had already be able to display non-MIME messages, it was natural
to drop
.Pn show
in favor of using
.Pn mhshow
exclusively.
This decision followed the idea of orthogonal design.
For convenience,
.Pn mhshow
was then renamed to
.Pn show .
.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
.P
To prepare for this transition,
.Pn mhshow
was reworked to behave more like
.Pn show
first.
(Section XXX describes this rework from a different perspective.)
Once the tools behaved similar, the replacing became a natural decision.
In mmh,
.Pn show
is the one single message display program again, but it handles
MIME messages as well as non-MIME messages.
Now, there's only one program to maintain, and users don't need to deal
with the existance of two display programs.
.P
There's one reason why removing the old
.Pn show
hurts: It had been such a simple program.
Its lean elegance is missing to
.Pn mhshow ,
i.e. the new
.Pn show .
But there is no chance, because supporting MIME causes essentially
higher complexity.


.H2 "Removal of 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 complexer 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 authetication.
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=[smtp|sendmail]
defined the default transport service.
In mmh this fixed to
.Ar sendmail .
.Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
With
.Sw --with-smtpservers=[server1...]
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.
Because giving the hash symbol as argument caused to many problems
for configure,
the option was limited to use the hash symbol as the default prefix.
This makes me believe, that the choice for the hash was personal preference.
Being it 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 agains
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 layed 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 homegeneic.
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 deteminded 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 "Locale
.P
The configure option
.Sw --disable-locale
was removed because POSIX provides locale support and there's
hardly any need to disable locale support.
.Ci ccf4f175ef4c4e7522f9510a4a1149c15d810dd9

.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 version 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 funtionality 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:
.QP
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>''
.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 "Removal of switches
.P




.H1 "Modernizing


.H2 "Removal of Code Relicts
.P
The code base of mmh originates from the late Seventies,
had been extensively
worked on in the mid Eighties, and had been partly reorganized and extended
in the Nineties. Relicts of all those times had gathered in the code base.
My goal was to remove any ancient code parts. One part of the task was
converting obsolete code constructs to standard constructs, the other part
was dropping obsolete functions.
.P
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.
.P
The other task \(en dropping ancient functionality to remove old code \(en
I did myself, though. My position to strip mmh to the bare minimum of
frequently used features is much more revolutional than the nmh community
likes it. Without the need to justify my decisions, I was able to quickly
remove functionality I considered ancient.
The need to discuss my decisions with
peers likely would have slowed this process down. Of course, I researched
if a particular feature really should be dropped. Having not had any
contact to this feature within my computer life was a first indicator to
drop it, but I also asked others and searched the literature for modern
usage of the feature. If it appeared to be truly ancient, I dropped it.
The reason for dropping is always part of the commit message in the
version control system. Thus, it is easy for others to check their
view on the topic with mine and possibly to argue for reinclusion.

.U2 "MMDF maildrop support
.P
I did drop any support for the MMDF maildrop format. This type of format
is conceptionally similar to the mbox format, but uses four bytes with
value 1 (\fL^A^A^A^A\fP) as message delimiter,
instead of the string ``\fLFrom\ \fP''.
Due to the similarity and mbox being the de-facto standard maildrop
format on Unix, but also due to the larger influence of Sendmail than MMDF,
the MMDF maildrop format had vanished.
.P
The simplifications within the code were only moderate. Switches could
be removed from tools like
.L packf ,
which generate packed mailboxes. Only one packed mailbox format remained:
mbox.
The most important changes affect the equally named mail parsing routine in
.L sbr/m_getfld.c .
The direct MMDF code had been removed, but as now only one packed mailbox
format is left, code structure simplifications are likely possible.
The reason why they are still outstanding is the heavily optimized code
of
.Fu m_getfld() .
Changes beyond a small local scope \(en
which restructuring in its core is \(en cause a high risk of damaging
the intricate workings of the optimized code. This problem is know
to the developers of nmh, too. They also avoid touching this minefield
if possible.

.U2 "UUCP Bang Paths
.P
More questionably than the former topic is the removal of support for the
UUCP bang path address style. However, the user may translate the bang
paths on retrieval to Internet addresses and the other way on posting
messages. The former can be done my an MDA like procmail; the latter
by a sendmail wrapper. This would ensure that any address handling would
work as expected. However, it might just work well without any
such modifications, as mmh does not touch addresses much, in general.
But I can't ensure as I have never used an environment with bang paths.
Also, the behavior might break at any point in further development.

.U2 "Hardcopy terminal support
.P
More of a funny anecdote is the remaining of a check for printing to a
hardcopy terminal until Spring 2012, when I finally removed it.
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. This could have been ensured with
the
.Sw -nomoreproc
at the command line statically, too.

.U2 "Removed support for header fields
.P
The
.Hd Encrypted
header field had been introduced by RFC\^822, but already
marked legacy in RFC 2822. It was superseded by FIXME.
Mmh does no more support this header field.
.P
Native support for
.Hd Face
header fields had been removed, as well.
The 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.
Neither
.Hd X-Face
nor the here described
.Hd Face
system
\**
.FS
There is also a newer but different system, invented 2005,
using
.Hd Face
headers.
It is the successor of
.Hd X-Face
providing colored PNG images.
.FE
became well used in the large scale.
It's still possible to use a Face systems,
although mmh does not provide support for any of the different systems
anymore. It's fairly easy to write a small shell script to 
extract the embedded or fetch the external Face data and display the image.
Own
.Hd Face
header field can be added into the draft template files.
.P
.Hd Content-MD5
header fields were introduced by RFC\^1864. They provide only
a verification of data corruption during the transfer. By no means can
they ensure verbatim end-to-end delivery of the contents. This is clearly
stated in the RFC. The proper approach to provide verificationability
of content in an end-to-end relationship is the use of digital cryptography
(RFCs FIXME). On the other hand, transfer protocols should ensure the
integrity of the transmission. In combinations these two approaches
make the
.Hd Content-MD5
header field useless. In consequence, I removed
the support for it. By this removal, MD5 computation is not needed
anywhere in mmh. Hence, over 500 lines of code were removed by this one
change. Even if the
.Hd Content-MD5
header field is useful sometimes,
I value its usefulnes less than the improvement in maintainability, caused
by the removal.

.U2 "Prompter's Control Keys
.P
The program
.Pn prompter
queries the user to fill in a message form. When used by
.Pn comp
as:
.VS
comp -editor prompter
VE
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 .

.U2 "Vfork and Retry Loops
.P
MH creates many processes, which is a consequence of the tool chest approach.
In earlier times
.Fu fork()
had been an expensive system call, as the process's whole image needed
to be duplicated. One common case is replacing the image with
.Fu exec()
right after having forked the child process.
To speed up this case, the
.Fu vfork()
system call was invented at Berkeley. It completely omits copying the
image. If the image gets replaced right afterwards then unnecessary
work is omited. On old systems this results in large speed ups.
MH uses
.Fu vfork()
whenever possible.
.P
Memory management units that support copy-on-write semantics make
.Fu fork()
almost as fast as
.Fu vfork()
in the cases when they can be exchanged.
With
.Fu vfork()
being more error-prone and hardly faster, it's preferable to simply
use
.Fu fork()
instead.
.P
Related to the costs of
.Fu fork()
is the probability of its success.
Today on modern systems, the system call will succeed almost always.
In the Eighties on heavy loaded systems, as they were common at
universities, this had been different. Thus, many of the
.Fu fork()
calls were wrapped into loops to retry to fork several times in
short intervals, in case of previous failure.
In mmh, the program aborts at once if the fork failed.
The user can reexecute the command then. This is expected to be a
very rare case on modern systems, especially personal ones, which are
common today.


.H2 "Attachments
.P
MIME


.H2 "Digital Cryptography
.P
Signing and encryption.


.H2 "Good Defaults
.P
foo




.H1 "Code style
.P
foo


.H2 "Standard Code
.P
POSIX


.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, ...




.H1 "Concept Exploitation/Homogeniety


.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 frontends 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