# HG changeset patch # User markus schnalke # Date 1340185732 -7200 # Node ID e8e6adb14bebb0a8923ab57103e43d6a3dd15636 # Parent 6ae7dc4a3a02a846652e8f2e7d77de3711835d33 Wrote about attachments. diff -r 6ae7dc4a3a02 -r e8e6adb14beb ch03.roff --- 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