--- a/ch03.roff	Tue Jun 19 10:54:50 2012 +0200
+++ b/ch03.roff	Wed Jun 20 11:48:52 2012 +0200
@@ -1693,7 +1693,7 @@
 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
+.U3 "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
@@ -1721,7 +1721,7 @@
 to the developers of nmh, too. They also avoid touching this minefield
 if possible.
 
-.U2 "UUCP Bang Paths
+.U3 "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
@@ -1733,7 +1733,7 @@
 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
+.U3 "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.
@@ -1748,7 +1748,7 @@
 .Sw -nomoreproc
 at the command line statically, too.
 
-.U2 "Removed support for header fields
+.U3 "Removed support for header fields
 .P
 The
 .Hd Encrypted
@@ -1809,7 +1809,7 @@
 I value its usefulness less than the improvement in maintainability, caused
 by the removal.
 
-.U2 "Prompter's Control Keys
+.U3 "Prompter's Control Keys
 .P
 The program
 .Pn prompter
@@ -1836,7 +1836,7 @@
 with the standard tool
 .Pn stty .
 
-.U2 "Vfork and Retry Loops
+.U3 "Vfork and Retry Loops
 .P
 MH creates many processes, which is a consequence of the tool chest approach.
 In earlier times
@@ -1883,7 +1883,161 @@
 
 .H2 "Attachments
 .P
-MIME
+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.
+In order to solve this problem, in 2002, Jon Steinhart had added an
+attachment system to nmh.
+.Ci 7480dbc14bc90f2d872d434205c0784704213252
+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
+With this change, the mind model of attachments entered nmh:
+.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
+Unfortunately, the system had been deactivated by default,
+like any new facilities in nmh.
+.\" XXX move this paragraph somewhere else
+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.
+.P
+During my work in Argentina, I tried to improve the attachment system.
+Because of great opposition in the nmh community, after long discussions,
+my patch died as a proposal on the mailing list.
+.[
+nmh-workers attachment proposal
+.]
+In Januar 2012, I applied the patch in an extended form to mmh.
+.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
+.P
+In mmh, the attachment system is active by default.
+There are no command line switches anymore, but a pre-defined attachment
+header field.
+It is named
+.Hd Attach
+by default, but can be renamed with the
+.Pe Attachment-Header
+profile entry.
+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,
+by using the `attach' command at the WhatNow prompt, or with
+.Pn anno :
+.VS
+anno -append -nodate -component Attach -text /path/to/file
+VE
+Drafts with attachment headers are converted to MIME automatically
+on sending.
+The draft stored in the draft folder is always in source form with
+attachment headers.
+The convertion to MIME is done invisible to the user.
+If the MIMEification fails, for instance because the file to attach
+is not accessible, the original draft is not changed.
+.P
+Forwarding message is handled by the same attachment system.
+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 it the user needed to invoke `mime' at the WhatNow prompt
+to have the draft converted to MIME.
+This was necessary if 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 for each message.
+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 the attachment system, the user must not run `mime' at the
+WhatNow prompt nor have
+.Pe automimeproc
+set in the profile.
+But then the case of non-ASCII text without attachment headers was
+not caught.
+All in all a bad solution.
+My patch from December 2010 already solved this situation.
+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 to MIME when either an attachment header
+or non-ASCII text is present.
+Further more, the special meaning of the hash character (`#')
+at the beginning of the line in the draft message is removed.
+The user needs not at all deal about the topic.
+.P
+This improvement has a price: The new approach does not directly
+support arbitrary MIME compositions.
+Nonetheless, the full power of
+.Pn mhbuild
+can still be accessed.
+As long as no attachment headers are included, the user can create a
+nonlimited
+.Pn mhbuild
+composition draft 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 only contain ASCII characters
+and has no 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.
+Still, the full power of
+.Pn mhbuild
+can be accessed with a bit of overhead.
+
+.\" XXX: MIME types
+.\" XXX: whatnow prompt commands
+.\" XXX: anno rework
 
 
 .H2 "Digital Cryptography