1.1 --- a/ch03.roff	Tue Jun 19 10:54:50 2012 +0200
     1.2 +++ b/ch03.roff	Wed Jun 20 11:48:52 2012 +0200
     1.3 @@ -1693,7 +1693,7 @@
     1.4  version control system. Thus, it is easy for others to check their
     1.5  view on the topic with mine and possibly to argue for reinclusion.
     1.6  
     1.7 -.U2 "MMDF maildrop support
     1.8 +.U3 "MMDF maildrop support
     1.9  .P
    1.10  I did drop any support for the MMDF maildrop format. This type of format
    1.11  is conceptionally similar to the mbox format, but uses four bytes with
    1.12 @@ -1721,7 +1721,7 @@
    1.13  to the developers of nmh, too. They also avoid touching this minefield
    1.14  if possible.
    1.15  
    1.16 -.U2 "UUCP Bang Paths
    1.17 +.U3 "UUCP Bang Paths
    1.18  .P
    1.19  More questionably than the former topic is the removal of support for the
    1.20  UUCP bang path address style. However, the user may translate the bang
    1.21 @@ -1733,7 +1733,7 @@
    1.22  But I can't ensure as I have never used an environment with bang paths.
    1.23  Also, the behavior might break at any point in further development.
    1.24  
    1.25 -.U2 "Hardcopy terminal support
    1.26 +.U3 "Hardcopy terminal support
    1.27  .P
    1.28  More of a funny anecdote is the remaining of a check for printing to a
    1.29  hardcopy terminal until Spring 2012, when I finally removed it.
    1.30 @@ -1748,7 +1748,7 @@
    1.31  .Sw -nomoreproc
    1.32  at the command line statically, too.
    1.33  
    1.34 -.U2 "Removed support for header fields
    1.35 +.U3 "Removed support for header fields
    1.36  .P
    1.37  The
    1.38  .Hd Encrypted
    1.39 @@ -1809,7 +1809,7 @@
    1.40  I value its usefulness less than the improvement in maintainability, caused
    1.41  by the removal.
    1.42  
    1.43 -.U2 "Prompter's Control Keys
    1.44 +.U3 "Prompter's Control Keys
    1.45  .P
    1.46  The program
    1.47  .Pn prompter
    1.48 @@ -1836,7 +1836,7 @@
    1.49  with the standard tool
    1.50  .Pn stty .
    1.51  
    1.52 -.U2 "Vfork and Retry Loops
    1.53 +.U3 "Vfork and Retry Loops
    1.54  .P
    1.55  MH creates many processes, which is a consequence of the tool chest approach.
    1.56  In earlier times
    1.57 @@ -1883,7 +1883,161 @@
    1.58  
    1.59  .H2 "Attachments
    1.60  .P
    1.61 -MIME
    1.62 +The mind model of email attachments is unrelated to MIME.
    1.63 +Although the MIME RFCs (2045 through 2049) define the technical
    1.64 +requirements for having attachments, they do not mention the the word
    1.65 +``attachment''.
    1.66 +Instead of attachments, MIME talks about ``multi-part message bodies''
    1.67 +[RFC\|2045], a more general concept.
    1.68 +Multi-part messages are messages
    1.69 +``in which one or more different
    1.70 +sets of data are combined in a single body''
    1.71 +[RFC\|2046].
    1.72 +MIME keeps its descriptions generic;
    1.73 +it does not imply specific usage models.
    1.74 +In email one usage model became prevalent: attachments.
    1.75 +The idea is having a main text document with files of arbitrary kind
    1.76 +attached to it.
    1.77 +In MIME terms, this is a multi-part message having a text part first
    1.78 +and parts of arbitray type following.
    1.79 +.P
    1.80 +MH's MIME support is a direct implementation of the RFCs.
    1.81 +The perception of the topic described in the RFCs is clearly visible
    1.82 +in MH's implementation.
    1.83 +Thus, MH had all the MIME features but no idea of attachments.
    1.84 +Today, however, users don't need all the MIME features but they want
    1.85 +convenient attachment handling.
    1.86 +In order to solve this problem, in 2002, Jon Steinhart had added an
    1.87 +attachment system to nmh.
    1.88 +.Ci 7480dbc14bc90f2d872d434205c0784704213252
    1.89 +He described his motivation to do so as such:
    1.90 +.QS
    1.91 +Although nmh contains the necessary functionality for MIME message handing,
    1.92 +the interface to this functionality is pretty obtuse.
    1.93 +There's no way that I'm ever going to convince my partner to write
    1.94 +.Pn mhbuild
    1.95 +composition files!
    1.96 +.QE
    1.97 +With this change, the mind model of attachments entered nmh:
    1.98 +.QS
    1.99 +These changes simplify the task of managing attachments on draft files.
   1.100 +They allow attachments to be added, listed, and deleted.
   1.101 +MIME messages are automatically created when drafts with attachments
   1.102 +are sent.
   1.103 +.QE
   1.104 +Unfortunately, the system had been deactivated by default,
   1.105 +like any new facilities in nmh.
   1.106 +.\" XXX move this paragraph somewhere else
   1.107 +Just to give one example, for me it took one year of using nmh
   1.108 +before I became aware of the existence of the attachment system.
   1.109 +One could argue that this fact disqualifies my reading of the
   1.110 +documentation.
   1.111 +If I would have installed nmh from source back then, I could agree.
   1.112 +Yet I had used a prepackaged version and had expected that it would
   1.113 +just work.
   1.114 +.P
   1.115 +During my work in Argentina, I tried to improve the attachment system.
   1.116 +Because of great opposition in the nmh community, after long discussions,
   1.117 +my patch died as a proposal on the mailing list.
   1.118 +.[
   1.119 +nmh-workers attachment proposal
   1.120 +.]
   1.121 +In Januar 2012, I applied the patch in an extended form to mmh.
   1.122 +.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
   1.123 +.P
   1.124 +In mmh, the attachment system is active by default.
   1.125 +There are no command line switches anymore, but a pre-defined attachment
   1.126 +header field.
   1.127 +It is named
   1.128 +.Hd Attach
   1.129 +by default, but can be renamed with the
   1.130 +.Pe Attachment-Header
   1.131 +profile entry.
   1.132 +To add an attachment to a draft, simply add an attachment header:
   1.133 +.VS
   1.134 +To: bob
   1.135 +Subject: The file you wanted
   1.136 +Attach: /path/to/the/file-bob-wanted
   1.137 +--------
   1.138 +Here it is.
   1.139 +VE
   1.140 +The header field can be added to the draft manually in the editor,
   1.141 +by using the `attach' command at the WhatNow prompt, or with
   1.142 +.Pn anno :
   1.143 +.VS
   1.144 +anno -append -nodate -component Attach -text /path/to/file
   1.145 +VE
   1.146 +Drafts with attachment headers are converted to MIME automatically
   1.147 +on sending.
   1.148 +The draft stored in the draft folder is always in source form with
   1.149 +attachment headers.
   1.150 +The convertion to MIME is done invisible to the user.
   1.151 +If the MIMEification fails, for instance because the file to attach
   1.152 +is not accessible, the original draft is not changed.
   1.153 +.P
   1.154 +Forwarding message is handled by the same attachment system.
   1.155 +If the attachment header value starts with a plus character (`+'),
   1.156 +like in
   1.157 +.Cl "Attach: +bob 30 42" ,
   1.158 +The given messages in the specified folder will be attached.
   1.159 +This allowed to simplify
   1.160 +.Pn forw .
   1.161 +.Ci f41f04cf4ceca7355232cf7413e59afafccc9550
   1.162 +.P
   1.163 +Closely related to attachments is non-ASCII text content,
   1.164 +because it requires MIME too.
   1.165 +In nmh it the user needed to invoke `mime' at the WhatNow prompt
   1.166 +to have the draft converted to MIME.
   1.167 +This was necessary if the draft contained non-ASCII characters.
   1.168 +If the user did not call `mime', a broken message would be sent.
   1.169 +Therefore, the
   1.170 +.Pe automimeproc
   1.171 +profile entry could be specified to have the `mime' command invoked
   1.172 +automatically for each message.
   1.173 +Unfortunately, this approach conflicted with with attachment system
   1.174 +because the draft would already be in MIME format at the time
   1.175 +when the attachment system wanted to MIMEify it.
   1.176 +To use the attachment system, the user must not run `mime' at the
   1.177 +WhatNow prompt nor have
   1.178 +.Pe automimeproc
   1.179 +set in the profile.
   1.180 +But then the case of non-ASCII text without attachment headers was
   1.181 +not caught.
   1.182 +All in all a bad solution.
   1.183 +My patch from December 2010 already solved this situation.
   1.184 +Mmh's current solution is even more elaborate.
   1.185 +Any necessary MIMEification is done automatically.
   1.186 +There is no `mime' command at the WhatNow prompt anymore.
   1.187 +The draft will be converted to MIME when either an attachment header
   1.188 +or non-ASCII text is present.
   1.189 +Further more, the special meaning of the hash character (`#')
   1.190 +at the beginning of the line in the draft message is removed.
   1.191 +The user needs not at all deal about the topic.
   1.192 +.P
   1.193 +This improvement has a price: The new approach does not directly
   1.194 +support arbitrary MIME compositions.
   1.195 +Nonetheless, the full power of
   1.196 +.Pn mhbuild
   1.197 +can still be accessed.
   1.198 +As long as no attachment headers are included, the user can create a
   1.199 +nonlimited
   1.200 +.Pn mhbuild
   1.201 +composition draft like in nmh.
   1.202 +Then, at the WhatNow prompt, he needs to invoke
   1.203 +.Cl "edit mhbuild
   1.204 +to convert it to MIME.
   1.205 +Because the resulting draft does only contain ASCII characters
   1.206 +and has no attachment headers, the attachment system will not touch it.
   1.207 +.P
   1.208 +The approach taken in mmh is taylored towards todays most common case:
   1.209 +a text part with possibly attachments.
   1.210 +Still, the full power of
   1.211 +.Pn mhbuild
   1.212 +can be accessed with a bit of overhead.
   1.213 +
   1.214 +.\" XXX: MIME types
   1.215 +.\" XXX: whatnow prompt commands
   1.216 +.\" XXX: anno rework
   1.217  
   1.218  
   1.219  .H2 "Digital Cryptography