docs/master
view ch03.roff @ 62:24aabbfe5794
Minor rework of larger text areas.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Fri, 01 Jun 2012 17:15:38 +0200 |
| parents | 6a92e0208de0 |
| children | abbaca05ee8e |
line source
1 .H0 "Discussion
2 .P
3 This main chapter discusses the practical work done in the mmh project.
4 It is structured along the goals to achieve. The concrete work done
5 is described in the examples of how the general goals were achieved.
10 .H1 "Stream-lining
12 .P
13 MH had been considered an all-in-one system for mail handling.
14 The community around nmh has a similar understanding.
15 In fundamental difference, I believe that mmh should be a MUA but
16 nothing more. I believe that all-in-one mail systems are not the way
17 to go. There are excellent specialized MTAs, like Postfix;
18 there are specialized MDAs, like Procmail; there are specialized
19 MRAs, like Fetchmail. I believe it's best to use them instead of
20 providing the same function ourselves. Doing something well requires to
21 focus on this particular aspect or a small set of aspects. The more
22 it is possible to focus, the better the result in this particular
23 area will be. The limiting resource in Free Software community development
24 usually is human power. If the low development power is even parted
25 into multiple development areas, it will hardly be possible to
26 compete with the specialists in the various fields. This is even
27 increased, given the small community \(en developers and users \(en
28 that MH-based mail systems have. In consequence, I believe that the
29 available resources should be concentrated at the point where MH is
30 most unique. This is clearly the MUA part.
31 .P
32 The goal for mmh was to remove peripheral parts and stream-line
33 it for the MUA task.
36 .H2 "Removal of Mail Transfer Facilities
37 .P
38 In contrast to nmh, which also provides mail submission and mail retrieval
39 facilities, mmh is a MUA only.
40 .P
41 The MSA is called ``Message Transfer Service'' (MTS) in nmh.
42 The facility establishes TCP/IP connections and speaks SMTP to submit
43 messages for relay to the outside world.
44 This part is implemented in the
45 .Pn post
46 command.
47 Demanded by the changes in
48 emailing, this part of nmh required changes in the last years.
49 Encrypted connections needed to be supported, hence SASL was introduced
50 into nmh. This added complexity to the nmh without improving it in
51 its core functions. Also, keeping up with recent developments in
52 this field needs requires development power and specialists.
53 Mmh cuts this whole facility off and depends on an external MTA instead.
54 The only outgoing interface available to mmh is the
55 .Pn sendmail
56 command.
57 Almost any MTA provides a
58 .Pn sendmail
59 command.
60 It not, any program can be substituted if it reads the
61 message from the standard input, extracts the recipient addresses
62 from the message header and does not conflict
63 with sendmail-specific command line arguments.
64 .P
65 To retrieve mail, the
66 .Pn inc
67 command in nmh has the ability to establish TCP/IP connections
68 and speaks POP3 to retrieve mail from remote servers.
69 As with mail submission, here encrypted connections are required
70 today, thus SASL support was added.
71 As POP3 is superseded by IMAP more and more, support for message
72 retrieval through IMAP will become necessary to be added soon.
73 Mmh has no support for retrieving mail from remote locations.
74 It depends on an external tool to cover this task.
75 There are two ways for messages to enter mmh's mail storage:
76 Incorporate them with
77 .Pn inc
78 from the system maildrop, or with
79 .Pn rcvstore
80 from the standard input.
81 .P
82 In consequence, mmh includes neither networking nor SASL code anymore.
83 Two large separate functional units are removed.
84 They account for about XXX lines of code and XXX libraries.
85 .P
86 With the removal of the MSA and MRA, mmh converted from an all-in-one
87 mail system to the core: the MUA.
88 Following the Unix philosophy, it focuses on one job and to do that well.
89 Now, of course, mmh depends on third-party software.
90 An external MTA/MSA is required to transfer mail to the outside world;
91 an external MRA is required to retrieve mail from remote machines.
92 There exist excellent implementations of such software,
93 which do this specific task likely much better than the internal
94 versions of nmh do it. Also, this provides the choice for the best
95 suiting one of the available implementation.
96 .P
97 As it had already been possible to use an external MSA or MRA,
98 why not keep the internal version for convenience?
99 If this would question the sense in having a fall-back pager in all
100 the command line tools, in case
101 .Pn more
102 or
103 .Pn less
104 wouldn't be available, the answer is intuitively seen.
105 Now, an MSA or MRA is clearly more complex than a text pager, but
106 still the concept holds: If programs become complex, split them;
107 if projects become complex, split them.
108 Complexity is demanded by the problem to solve. Decades ago,
109 emailing had been small and simple.
110 (Remember,
111 .Pn /bin/mail
112 had once covered anything there was to email.)
113 As the complexity in emailing increased, MH remainded mostly unchanged.
114 Nontheless, in nmh the POP server, which the original MH had included,
115 was removed. Now is the time to take one step further and remove
116 the MSA and MRA.
117 Not only does it decrease the code amount of the project,
118 but more important, it removes the whole field of message transfer
119 with all its implications from the project.
120 .P
121 Users of MH are usually able to set up an external MSA and MRA.
122 Also, the popular MSAs and MRAs have large communities and a lot
123 of documentation available.
124 .P
125 Choices for MSAs range from the full-featured
126 .I Postfix
127 over mid-size solutions like
128 .I masqmail
129 and
130 .I dma
131 to small forwarders like
132 .I ssmtp
133 and
134 .I nullmailer .
135 Choices for MRAs include
136 .I fetchmail ,
137 .I getmail ,
138 .I mpop
139 and
140 .I fdm .
143 .H2 "Removal of non-MUA Tools
144 .P
145 Some of nmh's tools were removed from mmh because they didn't
146 match the main focus of adding to the MUA's task.
147 .BU
148 .Pn conflict
149 was removed because it is a mail system maintenance tool.
150 Besides, it even checks
151 .Fn /etc/passwd
152 and
153 .Fn /etc/group
154 for consistency, which has nothing at all to do with emailing.
155 The tool might be useful, but it should not be shipped with mmh.
156 .BU
157 .Pn rcvtty
158 was removed because its usecase of writing to the user's terminal
159 on receiving of mail is hardly wanted today. If users like to be
160 informed of new mail, then using the shell's
161 .Ev MAILPATH
162 variable or graphical notifications are likely more
163 appealing.
164 Writing directly to a terminals is hardly ever wanted today.
165 If though one wants to have it this way, the standard tool
166 .Pn write
167 can be used in a way similar to:
168 .DS
169 scan -file - | write `id -un`
170 .DE
171 .BU
172 .Pn viamail
173 was removed when the new attachment system was introduced, because
174 .Pn forw
175 could can now the task itself.
176 The program
177 .Pn sendfiles
178 was rewritten as a shell script wrapper around
179 .Pn forw .
180 .BU
181 .Pn msgchk
182 was removed, because it lost its usefulness when POP support was removed.
183 .Pn msgchk
184 provides hardly more information than:
185 .DS
186 ls -l /var/mail/meillo
187 .DE
188 It does separate between old and new mail, but that's merely a detail
189 and can be done with
190 .Pn stat (1)
191 too.
192 A very small shell script could be written to output the information
193 in a convenient way, if truly necessary.
194 As mmh's inc only incorporates mail from the user's local maildrop
195 and thus no data transfers over slow networks are involved,
196 there's hardly need to check for new mail before incorporating it.
197 .BU
198 .Pn msh
199 was removed because the tool was in conflict with the
200 philosophy of MH. It provided an interactive shell to access the
201 features of MH. One major feature of MH is being a tool chest.
202 .Pn msh
203 wouldn't be just another shell, tailored to the needs of mail
204 handling, but one large program to have the MH tools built in.
205 It's main use was for accessing Bulletin Boards, which have seized to
206 be popular.
207 .P
208 XXX discuss
209 .P
210 Removing
211 .Pn msh ,
212 together with the truly obsolete code relicts
213 .Pn vmh
214 and
215 .Pn wmh ,
216 saved more than 7\|000 lines of C code \(en
217 that's about 15\|% less code in the project.
220 .H2 "Merge of \f(CWshow\fP and \f(CWmhshow\fP
221 .P
222 Since the very beginning, already in the first concept paper,
223 .Pn show
224 had been MH's message display program.
225 .Pn show
226 found out which pathnames the relevant messages had and invoked
227 .Pn mhl
228 then to have the content formated.
229 With the advent of MIME, this approach wasn't sufficient anymore.
230 MIME messages can consist of multiple parts, some of which aren't
231 directly displayable, and text content might be encoded in
232 foreign charsets.
233 .Pn show 's
234 simple approach and
235 .Pn mhl 's
236 limited display facilities couldn't cope with the task any longer.
237 .P
238 Instead of extending these tools, new ones were written from scratch
239 and then added to the MH tool chest. Doing so is encouraged by the
240 tool chest approach. The new tools could be added without interfering
241 with the existing ones. This is great. The ease of adding new tools
242 even made MH the first MUA to implement MIME.
243 .P
244 First, the new MIME features were added in form of the single program
245 .Pn mhn .
246 The command
247 .Cl "mhn \-show 42
248 would show the MIME message numbered 42.
249 With the 1.0 release of nmh in February 1999, Richard Coleman finished
250 the split of
251 .Pn mhn
252 into a set of specialized programs, which together covered the
253 multiple aspects of MIME. One of these resulting tools was
254 .Pn mhshow .
255 .Pn mhshow
256 resembled the
257 .Cl "mhn \-show
258 call.
259 .P
262 .H2 "Removal of Configure Options
263 .P
265 .H2 "Removal of switches
266 .P
271 .H1 "Moderizing
274 .H2 "Removal of Code Relicts
275 .P
276 The code base of mmh originates from the late Seventies,
277 had been extensively
278 worked on in the mid Eighties, and had been partly reorganized and extended
279 in the Nineties. Relicts of all those times had gathered in the code base.
280 My goal was to remove any ancient code parts. One part of the task was
281 converting obsolete code constructs to standard constructs, the other part
282 was dropping obsolete functions.
283 .P
284 As I'm not even thirty years old and have no more than seven years of
285 Unix experience, I needed to learn about the history in retrospective.
286 Older people likely have used those ancient constructs themselves
287 and have suffered from their incompatibilities and have longed for
288 standardization. Unfortunately, I have only read that others had done so.
289 This put me in a much more difficult positions when working on the old
290 code. I needed to recherche what other would have known by heart from
291 experience. All my programming experience comes from a time past ANSI C
292 and past POSIX. Although I knew about the times before, I took the
293 current state implicitly for granted most of the time.
294 .P
295 Being aware of
296 these facts, I rather let people with more historic experience solve the
297 task of converting the ancient code constructs to standardized ones.
298 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
299 He converted large parts of the code to POSIX constructs, removing
300 the conditionals compilation for now standardized features.
301 I'm thankful for this task being solved. I only pulled the changes into
302 mmh.
303 .P
304 The other task \(en dropping ancient functionality to remove old code \(en
305 I did myself, though. My position to strip mmh to the bare minimum of
306 frequently used features is much more revolutional than the nmh community
307 likes it. Without the need to justify my decisions, I was able to quickly
308 remove functionality I considered ancient.
309 The need to discuss my decisions with
310 peers likely would have slowed this process down. Of course, I researched
311 if a particular feature really should be dropped. Having not had any
312 contact to this feature within my computer life was a first indicator to
313 drop it, but I also asked others and searched the literature for modern
314 usage of the feature. If it appeared to be truly ancient, I dropped it.
315 The reason for dropping is always part of the commit message in the
316 version control system. Thus, it is easy for others to check their
317 view on the topic with mine and possibly to argue for reinclusion.
319 .U2 "MMDF maildrop support
320 .P
321 I did drop any support for the MMDF maildrop format. This type of format
322 is conceptionally similar to the mbox format, but uses four bytes with
323 value 1 (\fL^A^A^A^A\fP) as message delimiter,
324 instead of the string ``\fLFrom\ \fP''.
325 Due to the similarity and mbox being the de-facto standard maildrop
326 format on Unix, but also due to the larger influence of Sendmail than MMDF,
327 the MMDF maildrop format had vanished.
328 .P
329 The simplifications within the code were only moderate. Switches could
330 be removed from tools like
331 .L packf ,
332 which generate packed mailboxes. Only one packed mailbox format remained:
333 mbox.
334 The most important changes affect the equally named mail parsing routine in
335 .L sbr/m_getfld.c .
336 The direct MMDF code had been removed, but as now only one packed mailbox
337 format is left, code structure simplifications are likely possible.
338 The reason why they are still outstanding is the heavily optimized code
339 of
340 .Fu m_getfld() .
341 Changes beyond a small local scope \(en
342 which restructuring in its core is \(en cause a high risk of damaging
343 the intricate workings of the optimized code. This problem is know
344 to the developers of nmh, too. They also avoid touching this minefield
345 if possible.
347 .U2 "UUCP Bang Paths
348 .P
349 More questionably than the former topic is the removal of support for the
350 UUCP bang path address style. However, the user may translate the bang
351 paths on retrieval to Internet addresses and the other way on posting
352 messages. The former can be done my an MDA like procmail; the latter
353 by a sendmail wrapper. This would ensure that any address handling would
354 work as expected. However, it might just work well without any
355 such modifications, as mmh does not touch addresses much, in general.
356 But I can't ensure as I have never used an environment with bang paths.
357 Also, the behavior might break at any point in further development.
359 .U2 "Hardcopy terminal support
360 .P
361 More of a funny anecdote is the remaining of a check for printing to a
362 hardcopy terminal until Spring 2012, when I finally removed it.
363 I surely would be very happy to see such a terminal in action, maybe
364 actually being able to work on it, but I fear my chances are null.
365 .P
366 The check only prevented a pager to be placed between the outputting
367 program (\c
368 .Pn mhl )
369 and the terminal. This could have been ensured with
370 the
371 .Sw \-nomoreproc
372 at the command line statically, too.
374 .U2 "Removed support for header fields
375 .P
376 The `Encrypted' header had been introduced by RFC\^822, but already
377 marked legacy in RFC 2822. It was superseded by FIXME.
378 Mmh does no more support this header.
379 .P
380 Native support for `Face' headers
381 had been removed, as well.
382 The feature is similar to the `X-Face' header in its intent,
383 but takes a different approach to store the image.
384 Instead of encoding the image data directly into the header,
385 the the header contains the hostname and UDP port where the image
386 date could be retrieved.
387 Neither `X-Face' nor the here described `Face' system
388 \**
389 .FS
390 There is also a newer but different system, invented 2005,
391 using `Face' headers.
392 It is the successor of `X-Face' providing colored PNG images.
393 .FE
394 became well used in the large scale.
395 It's still possible to use a Face systems,
396 although mmh does not provide support for any of the different systems
397 anymore. It's fairly easy to write a small shell script to
398 extract the embedded or fetch the external Face data and display the image.
399 Own Face headers can be added into the draft template files.
400 .P
401 `Content-MD5' headers were introduced by RFC\^1864. They provide only
402 a verification of data corruption during the transfer. By no means can
403 they ensure verbatim end-to-end delivery of the contents. This is clearly
404 stated in the RFC. The proper approach to provide verificationability
405 of content in an end-to-end relationship is the use of digital cryptography
406 (RFCs FIXME). On the other hand, transfer protocols should ensure the
407 integrity of the transmission. In combinations these two approaches
408 make the `Content-MD5' header field useless. In consequence, I removed
409 the support for it. By this removal, MD5 computation is not needed
410 anywhere in mmh. Hence, over 500 lines of code were removed by this one
411 change. Even if the `Content-MD5' header field is useful sometimes,
412 I value its usefulnes less than the improvement in maintainability, caused
413 by the removal.
415 .U2 "Prompter's Control Keys
416 .P
417 The program
418 .Pn prompter
419 queries the user to fill in a message form. When used by
420 .Pn comp
421 as:
422 .DS
423 comp \-editor prompter
424 .DE
425 the resulting behavior is similar to
426 .Pn mailx .
427 Apparently,
428 .Pn prompter
429 hadn't been touched lately. Otherwise it's hardly explainable why it
430 still offered the switches
431 .Sn \-erase \fUchr\fP
432 and
433 .Sn \-kill \fUchr\fP
434 to name the characters for command line editing.
435 The times when this had been necessary are long time gone.
436 Today these things work out-of-the-box, and if not, are configured
437 with the standard tool
438 .Pn stty .
440 .U2 "Vfork and Retry Loops
441 .P
442 MH creates many processes, which is a consequence of the tool chest approach.
443 In earlier times
444 .Fu fork()
445 had been an expensive system call, as the process's whole image needed
446 to be duplicated. One common case is replacing the image with
447 .Fu exec()
448 right after having forked the child process.
449 To speed up this case, the
450 .Fu vfork()
451 system call was invented at Berkeley. It completely omits copying the
452 image. If the image gets replaced right afterwards then unnecessary
453 work is omited. On old systems this results in large speed ups.
454 MH uses
455 .Fu vfork()
456 whenever possible.
457 .P
458 Memory management units that support copy-on-write semantics make
459 .Fu fork()
460 almost as fast as
461 .Fu vfork()
462 in the cases when they can be exchanged.
463 With
464 .Fu vfork()
465 being more error-prone and hardly faster, it's preferable to simply
466 use
467 .Fu fork()
468 instead.
469 .P
470 Related to the costs of
471 .Fu fork()
472 is the probability of its success.
473 Today on modern systems, the system call will succeed almost always.
474 In the Eighties on heavy loaded systems, as they were common at
475 universities, this had been different. Thus, many of the
476 .Fu fork()
477 calls were wrapped into loops to retry to fork several times in
478 short intervals, in case of previous failure.
479 In mmh, the program aborts at once if the fork failed.
480 The user can reexecute the command then. This is expected to be a
481 very rare case on modern systems, especially personal ones, which are
482 common today.
485 .H2 "Attachments
486 .P
487 MIME
490 .H2 "Digital Cryptography
491 .P
492 Signing and encryption.
495 .H2 "Good Defaults
496 .P
497 foo
502 .H1 "Code style
503 .P
504 foo
507 .H2 "Standard Code
508 .P
509 POSIX
512 .H2 "Separation
514 .U2 "MH Directory Split
515 .P
516 In MH and nmh, a personal setup had consisted of two parts:
517 The MH profile, named
518 .Fn \&.mh_profile
519 and being located directly in the user's home directory.
520 And the MH directory, where all his mail messages and also his personal
521 forms, scan formats, other configuration files are stored. The location
522 of this directory could be user-chosen. The default was to name it
523 .Fn Mail
524 and have it directly in the home directory.
525 .P
526 I've never liked the data storage and the configuration to be intermixed.
527 They are different kinds of data. One part, are the messages,
528 which are the data to operate on. The other part, are the personal
529 configuration files, which are able to change the behavior of the operations.
530 The actual operations are defined in the profile, however.
531 .P
532 When storing data, one should try to group data by its type.
533 There's sense in the Unix file system hierarchy, where configuration
534 file are stored separate (\c
535 .Fn /etc )
536 to the programs (\c
537 .Fn /bin
538 and
539 .Fn /usr/bin )
540 to their sources (\c
541 .Fn /usr/src ).
542 Such separation eases the backup management, for instance.
543 .P
544 In mmh, I've reorganized the file locations.
545 Still there are two places:
546 There's the mail storage directory, which, like in MH, contains all the
547 messages, but, unlike in MH, nothing else.
548 Its location still is user-chosen, with the default name
549 .Fn Mail ,
550 in the user's home directory. This is much similar to the case in nmh.
551 The configuration files, however, are grouped together in the new directory
552 .Fn \&.mmh
553 in the user's home directory.
554 The user's profile now is a file, named
555 .Fn profile ,
556 in this mmh directory.
557 Consistently, the context file and all the personal forms, scan formats,
558 and the like, are also there.
559 .P
560 The naming changed with the relocation.
561 The directory where everything, except the profile, had been stored (\c
562 .Fn $HOME/Mail ),
563 used to be called \fIMH directory\fP. Now, this directory is called the
564 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
565 the new directory
566 (\c
567 .Fn $HOME/.mmh ),
568 containing all the personal configuration files.
569 .P
570 The separation of the files by type of content is logical and convenient.
571 There are no functional differences as any possible setup known to me
572 can be implemented with both approaches, although likely a bit easier
573 with the new approach. The main goal of the change had been to provide
574 sensible storage locations for any type of personal mmh file.
575 .P
576 In order for one user to have multiple MH setups, he can use the
577 environment variable
578 .Ev MH
579 the point to a different profile file.
580 The MH directory (mail storage plus personal configuration files) is
581 defined by the
582 .Pe Path
583 profile entry.
584 The context file could be defined by the
585 .Pe context
586 profile entry or by the
587 .Ev MHCONTEXT
588 environment variable.
589 The latter is useful to have a distinct context (e.g. current folders)
590 in each terminal window, for instance.
591 In mmh, there are three environment variables now.
592 .Ev MMH
593 may be used to change the location of the mmh directory.
594 .Ev MMHP
595 and
596 .Ev MMHC
597 change the profile and context files, respectively.
598 Besides providing a more consistent feel (which simply is the result
599 of being designed anew), the set of personal configuration files can
600 be chosen independently from the profile (including mail storage location)
601 and context, now. Being it relevant for practical use or not, it
602 de-facto is an improvement. However, the main achievement is the
603 split between mail storage and personal configuration files.
606 .H2 "Modularization
607 .P
608 whatnowproc
609 .P
610 The \fIMH library\fP
611 .Fn libmh.a
612 collects a bunch of standard functions that many of the MH tools need,
613 like reading the profile or context files.
614 This doesn't hurt the separation.
617 .H2 "Style
618 .P
619 Code layout, goto, ...
624 .H1 "Concept Exploitation/Homogeniety
627 .H2 "Draft Folder
628 .P
629 Historically, MH provided exactly one draft message, named
630 .Fn draft
631 and
632 being located in the MH directory. When starting to compose another message
633 before the former one was sent, the user had been questioned whether to use,
634 refile or replace the old draft. Working on multiple drafts at the same time
635 was impossible. One could only work on them in alteration by refiling the
636 previous one to some directory and fetching some other one for reediting.
637 This manual draft management needed to be done each time the user wanted
638 to switch between editing one draft to editing another.
639 .P
640 To allow true parallel editing of drafts, in a straight forward way, the
641 draft folder facility exists. It had been introduced already in July 1984
642 by Marshall T. Rose. The facility was deactivated by default.
643 Even in nmh, the draft folder facility remained deactivated by default.
644 At least, Richard Coleman added the man page
645 .Mp mh-draft(5)
646 to document
647 the feature well.
648 .P
649 The only advantage of not using the draft folder facility is the static
650 name of the draft file. This could be an issue for MH frontends like mh-e.
651 But as they likely want to provide working on multiple drafts in parallel,
652 the issue is only concerning compatibility. The aim of nmh to stay compatible
653 prevented the default activation of the draft folder facility.
654 .P
655 On the other hand, a draft folder is the much more natural concept than
656 a draft message. MH's mail storage consists of folders and messages,
657 the messages named with ascending numbers. A draft message breaks with this
658 concept by introducing a message in a file named
659 .Fn draft .
660 This draft
661 message is special. It can not be simply listed with the available tools,
662 but instead requires special switches. I.e. corner-cases were
663 introduced. A draft folder, in contrast, does not introduce such
664 corner-cases. The available tools can operate on the messages within that
665 folder like on any messages within any mail folders. The only difference
666 is the fact that the default folder for
667 .Pn send
668 is the draft folder,
669 instead of the current folder, like for all other tools.
670 .P
671 The trivial part of the change was activating the draft folder facility
672 by default and setting a default name for this folder. Obviously, I chose
673 the name
674 .Fn +drafts .
675 This made the
676 .Sw \-draftfolder
677 and
678 .Sw \-draftmessage
679 switches useless, and I could remove them.
680 The more difficult but also the part that showed the real improvement,
681 was updating the tools to the new concept.
682 .Sw \-draft
683 switches could
684 be dropped, as operating on a draft message became indistinguishable to
685 operating on any other message for the tools.
686 .Pn comp
687 still has its
688 .Sw \-use
689 switch for switching between its two modes: (1) Compose a new
690 draft, possibly by taking some existing message as a form. (2) Modify
691 an existing draft. In either case, the behavior of
692 .Pn comp is
693 deterministic. There is no more need to query the user. I consider this
694 a major improvement. By making
695 .Pn send
696 simply operate on the current
697 message in the draft folder by default, with message and folder both
698 overridable by specifying them on the command line, it is now possible
699 to send a draft anywhere within the storage by simply specifying its folder
700 and name.
701 .P
702 All theses changes converted special cases to regular cases, thus
703 simplifying the tools and increasing the flexibility.
706 .H2 "Trash Folder
707 .P
708 Similar to the situation for drafts is the situation for removed messages.
709 Historically, a message was deleted by renaming. A specific
710 \fIbackup prefix\fP, often comma (\c
711 .Fn , )
712 or hash (\c
713 .Fn # ),
714 being prepended to the file name. Thus, MH wouldn't recognize the file
715 as a message anymore, as only files whose name consists of digits only
716 are treated as messages. The removed messages remained as files in the
717 same directory and needed some maintenance job to truly delete them after
718 some grace time. Usually, by running a command similar to
719 .DS
720 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
721 .DE
722 in a cron job. Within the grace time interval
723 the original message could be restored by stripping the
724 the backup prefix from the file name. If however, the last message of
725 a folder is been removed \(en say message
726 .Fn 6
727 becomes file
728 .Fn ,6
729 \(en and a new message enters the same folder, thus the same
730 numbered being given again \(en in our case
731 .Fn 6
732 \(en, if that one
733 is removed too, then the backup of the former message gets overwritten.
734 Thus, the ability to restore removed messages does not only depend on
735 the ``sweeping cron job'' but also on the removing of further messages.
736 This is undesirable, because the real mechanism is hidden from the user
737 and the consequences of further removals are not always obvious.
738 Further more, the backup files are scattered within the whole mail
739 storage, instead of being collected at one place.
740 .P
741 To improve the situation, the profile entry
742 .Pe rmmproc
743 (previously named
744 .Pe Delete-Prog )
745 was introduced, very early.
746 It could be set to any command, which would care for the mail removal
747 instead of taking the default action, described above.
748 Refiling the to-be-removed files to some garbage folder was a common
749 example. Nmh's man page
750 .Mp rmm(1)
751 proposes
752 .Cl "refile +d
753 to move messages to the garbage folder and
754 .Cl "rm `mhpath +d all`
755 the empty the garbage folder.
756 Managing the message removal this way is a sane approach. It keeps
757 the removed messages in one place, makes it easy to remove the backup
758 files, and, most important, enables the user to use the tools of MH
759 itself to operate on the removed messages. One can
760 .Pn scan
761 them,
762 .Pn show
763 them, and restore them with
764 .Pn refile .
765 There's no more
766 need to use
767 .Pn mhpath
768 to switch over from MH tools to Unix tools \(en MH can do it all itself.
769 .P
770 This approach matches perfect with the concepts of MH, thus making
771 it powerful. Hence, I made it the default. And even more, I also
772 removed the old backup prefix approach, as it is clearly less powerful.
773 Keeping unused alternative in the code is a bad choice as they likely
774 gather bugs, by not being constantly tested. Also, the increased code
775 size and more conditions crease the maintenance costs. By strictly
776 converting to the trash folder approach, I simplified the code base.
777 .Pn rmm
778 calls
779 .Pn refile
780 internally to move the to-be-removed
781 message to the trash folder (\c
782 .Fn +trash
783 by default). Messages
784 there can be operated on like on any other message in the storage.
785 The sweep clean, one can use
786 .Cl "rmm \-unlink +trash a" ,
787 where the
788 .Sw \-unlink
789 switch causes the files to be truly unliked instead
790 of moved to the trash folder.
793 .H2 "Path Notations
794 .P
795 foo
798 .H2 "MIME Integration
799 .P
800 user-visible access to whole messages and MIME parts are inherently
801 different
804 .H2 "Of One Cast
805 .P