docs/master
view ch03.roff @ 60:6a92e0208de0
Wrote about the removal of the mail transfer facilities.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Fri, 01 Jun 2012 15:33:37 +0200 |
| parents | 814c33b96d89 |
| children | 24aabbfe5794 |
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 .
144 .H2 "Removal of non-MUA Tools
145 .P
146 Several of nmh's tools were removed from mmh because they didn't
147 match the main focus of adding to the MUA's task.
148 .P
149 .Pn conflict
150 was removed because it is a mail system maintenance tool.
151 Besides, it also checks the
152 .Fn /etc/passwd
153 and
154 .Fn /etc/group
155 files.
156 The tool might be useful, but it should not be shipped with mmh.
157 .P
158 .Pn rcvtty
159 was removed because its usecase of writing to the user's terminal
160 on receiving of mail is hardly wanted today. If users like to be
161 informed of new mail, then using the shell's
162 .Ev MAILPATH
163 variable or different (graphical) notifications are likely more
164 appealing. Writing directly to other terminals is hardly ever wanted
165 today. 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 .P
172 When the new attachment system was introduced,
173 .Pn viamail
174 was removed because then
175 .Pn forw
176 could cover the task itself.
177 The wrapper program
178 .Pn sendfiles
179 was rewritten as a shell script to use
180 .Pn forw .
181 .P
182 .Pn msgchk
183 was removed as it became hardly useful when POP support was removed.
184 It is questionable if
185 .Pn msgchk
186 provides more information than:
187 .DS
188 ls -l /var/mail/meillo
189 .DE
190 It does separate between old and new mail, but that's not very
191 useful and can be found out with
192 .Pn stat (1)
193 too. A very small shell script could care for the form of output.
194 As mmh's inc only incorporates mail from the user's local maildrop
195 and thus no long data transfers are involved,
196 there's no need to check for new mail before incorporating it.
197 .P
198 .Pn msh
199 was removed because the tool was in conflict with the original
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. Removing
207 .Pn msh ,
208 together with the truly obsolete programs
209 .Pn vmh
210 and
211 .Pn wmh ,
212 saved more than 7\|000 lines of C code \(en a major achievement.
215 .H2 "mhshow show Merge
216 .P
217 Since the very beginning, already in the first concept paper,
218 .Pn show
219 had been MH's mail display program.
220 .Pn show
221 found out which pathnames the relevant messages had and invoked
222 .Pn mhl
223 then to let it render the content.
224 With the advent of MIME, this approach wasn't sufficient anymore.
225 MIME messages can consist of multiple parts, some of which aren't
226 directly displayable, and text content can be encoded in
227 foreign charsets.
228 .Pn show 's
229 simple approach and
230 .Pn mhl 's
231 limited display facilities couldn't cope with the task any longer.
232 Instead of extending these tools, new ones were written from scratch
233 and then added to the MH tool chest. Doing so is encouraged by the
234 tool chest approach. The new tools could be added without interfering
235 with the existing ones. This is great. It allowed MH to be the
236 first MUA to implement MIME.
237 .P
238 The new MIME features were added in form of the single program
239 .Pn mhn .
240 The command
241 .DS
242 mhn \-show 42
243 .DE
244 would show the MIME message numbered 42.
245 With the 1.0 release of nmh in February 1999, Richard Coleman finished
246 the split of
247 .Pn mhn
248 into a set of specialized programs, which together covered the
249 aspects of MIME. One of these resulting tools was
250 .Pn mhshow .
253 .H2 "Removal of Configure Options
254 .P
256 .H2 "Removal of switches
257 .P
262 .H1 "Moderizing
265 .H2 "Removal of Code Relicts
266 .P
267 The code base of mmh originates from the late Seventies,
268 had been extensively
269 worked on in the mid Eighties, and had been partly reorganized and extended
270 in the Nineties. Relicts of all those times had gathered in the code base.
271 My goal was to remove any ancient code parts. One part of the task was
272 converting obsolete code constructs to standard constructs, the other part
273 was dropping obsolete functions.
274 .P
275 As I'm not even thirty years old and have no more than seven years of
276 Unix experience, I needed to learn about the history in retrospective.
277 Older people likely have used those ancient constructs themselves
278 and have suffered from their incompatibilities and have longed for
279 standardization. Unfortunately, I have only read that others had done so.
280 This put me in a much more difficult positions when working on the old
281 code. I needed to recherche what other would have known by heart from
282 experience. All my programming experience comes from a time past ANSI C
283 and past POSIX. Although I knew about the times before, I took the
284 current state implicitly for granted most of the time.
285 .P
286 Being aware of
287 these facts, I rather let people with more historic experience solve the
288 task of converting the ancient code constructs to standardized ones.
289 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
290 He converted large parts of the code to POSIX constructs, removing
291 the conditionals compilation for now standardized features.
292 I'm thankful for this task being solved. I only pulled the changes into
293 mmh.
294 .P
295 The other task \(en dropping ancient functionality to remove old code \(en
296 I did myself, though. My position to strip mmh to the bare minimum of
297 frequently used features is much more revolutional than the nmh community
298 likes it. Without the need to justify my decisions, I was able to quickly
299 remove functionality I considered ancient.
300 The need to discuss my decisions with
301 peers likely would have slowed this process down. Of course, I researched
302 if a particular feature really should be dropped. Having not had any
303 contact to this feature within my computer life was a first indicator to
304 drop it, but I also asked others and searched the literature for modern
305 usage of the feature. If it appeared to be truly ancient, I dropped it.
306 The reason for dropping is always part of the commit message in the
307 version control system. Thus, it is easy for others to check their
308 view on the topic with mine and possibly to argue for reinclusion.
310 .U2 "MMDF maildrop support
311 .P
312 I did drop any support for the MMDF maildrop format. This type of format
313 is conceptionally similar to the mbox format, but uses four bytes with
314 value 1 (\fL^A^A^A^A\fP) as message delimiter,
315 instead of the string ``\fLFrom\ \fP''.
316 Due to the similarity and mbox being the de-facto standard maildrop
317 format on Unix, but also due to the larger influence of Sendmail than MMDF,
318 the MMDF maildrop format had vanished.
319 .P
320 The simplifications within the code were only moderate. Switches could
321 be removed from tools like
322 .L packf ,
323 which generate packed mailboxes. Only one packed mailbox format remained:
324 mbox.
325 The most important changes affect the equally named mail parsing routine in
326 .L sbr/m_getfld.c .
327 The direct MMDF code had been removed, but as now only one packed mailbox
328 format is left, code structure simplifications are likely possible.
329 The reason why they are still outstanding is the heavily optimized code
330 of
331 .Fu m_getfld() .
332 Changes beyond a small local scope \(en
333 which restructuring in its core is \(en cause a high risk of damaging
334 the intricate workings of the optimized code. This problem is know
335 to the developers of nmh, too. They also avoid touching this minefield
336 if possible.
338 .U2 "UUCP Bang Paths
339 .P
340 More questionably than the former topic is the removal of support for the
341 UUCP bang path address style. However, the user may translate the bang
342 paths on retrieval to Internet addresses and the other way on posting
343 messages. The former can be done my an MDA like procmail; the latter
344 by a sendmail wrapper. This would ensure that any address handling would
345 work as expected. However, it might just work well without any
346 such modifications, as mmh does not touch addresses much, in general.
347 But I can't ensure as I have never used an environment with bang paths.
348 Also, the behavior might break at any point in further development.
350 .U2 "Hardcopy terminal support
351 .P
352 More of a funny anecdote is the remaining of a check for printing to a
353 hardcopy terminal until Spring 2012, when I finally removed it.
354 I surely would be very happy to see such a terminal in action, maybe
355 actually being able to work on it, but I fear my chances are null.
356 .P
357 The check only prevented a pager to be placed between the outputting
358 program (\c
359 .Pn mhl )
360 and the terminal. This could have been ensured with
361 the
362 .Sw \-nomoreproc
363 at the command line statically, too.
365 .U2 "Removed support for header fields
366 .P
367 The `Encrypted' header had been introduced by RFC\^822, but already
368 marked legacy in RFC 2822. It was superseded by FIXME.
369 Mmh does no more support this header.
370 .P
371 Native support for `Face' headers
372 had been removed, as well.
373 The feature is similar to the `X-Face' header in its intent,
374 but takes a different approach to store the image.
375 Instead of encoding the image data directly into the header,
376 the the header contains the hostname and UDP port where the image
377 date could be retrieved.
378 Neither `X-Face' nor the here described `Face' system
379 \**
380 .FS
381 There is also a newer but different system, invented 2005,
382 using `Face' headers.
383 It is the successor of `X-Face' providing colored PNG images.
384 .FE
385 became well used in the large scale.
386 It's still possible to use a Face systems,
387 although mmh does not provide support for any of the different systems
388 anymore. It's fairly easy to write a small shell script to
389 extract the embedded or fetch the external Face data and display the image.
390 Own Face headers can be added into the draft template files.
391 .P
392 `Content-MD5' headers were introduced by RFC\^1864. They provide only
393 a verification of data corruption during the transfer. By no means can
394 they ensure verbatim end-to-end delivery of the contents. This is clearly
395 stated in the RFC. The proper approach to provide verificationability
396 of content in an end-to-end relationship is the use of digital cryptography
397 (RFCs FIXME). On the other hand, transfer protocols should ensure the
398 integrity of the transmission. In combinations these two approaches
399 make the `Content-MD5' header field useless. In consequence, I removed
400 the support for it. By this removal, MD5 computation is not needed
401 anywhere in mmh. Hence, over 500 lines of code were removed by this one
402 change. Even if the `Content-MD5' header field is useful sometimes,
403 I value its usefulnes less than the improvement in maintainability, caused
404 by the removal.
406 .U2 "Prompter's Control Keys
407 .P
408 The program
409 .Pn prompter
410 queries the user to fill in a message form. When used by
411 .Pn comp
412 as:
413 .DS
414 comp \-editor prompter
415 .DE
416 the resulting behavior is similar to
417 .Pn mailx .
418 Apparently,
419 .Pn prompter
420 hadn't been touched lately. Otherwise it's hardly explainable why it
421 still offered the switches
422 .Sn \-erase \fUchr\fP
423 and
424 .Sn \-kill \fUchr\fP
425 to name the characters for command line editing.
426 The times when this had been necessary are long time gone.
427 Today these things work out-of-the-box, and if not, are configured
428 with the standard tool
429 .Pn stty .
431 .U2 "Vfork and Retry Loops
432 .P
433 MH creates many processes, which is a consequence of the tool chest approach.
434 In earlier times
435 .Fu fork()
436 had been an expensive system call, as the process's whole image needed
437 to be duplicated. One common case is replacing the image with
438 .Fu exec()
439 right after having forked the child process.
440 To speed up this case, the
441 .Fu vfork()
442 system call was invented at Berkeley. It completely omits copying the
443 image. If the image gets replaced right afterwards then unnecessary
444 work is omited. On old systems this results in large speed ups.
445 MH uses
446 .Fu vfork()
447 whenever possible.
448 .P
449 Memory management units that support copy-on-write semantics make
450 .Fu fork()
451 almost as fast as
452 .Fu vfork()
453 in the cases when they can be exchanged.
454 With
455 .Fu vfork()
456 being more error-prone and hardly faster, it's preferable to simply
457 use
458 .Fu fork()
459 instead.
460 .P
461 Related to the costs of
462 .Fu fork()
463 is the probability of its success.
464 Today on modern systems, the system call will succeed almost always.
465 In the Eighties on heavy loaded systems, as they were common at
466 universities, this had been different. Thus, many of the
467 .Fu fork()
468 calls were wrapped into loops to retry to fork several times in
469 short intervals, in case of previous failure.
470 In mmh, the program aborts at once if the fork failed.
471 The user can reexecute the command then. This is expected to be a
472 very rare case on modern systems, especially personal ones, which are
473 common today.
476 .H2 "Attachments
477 .P
478 MIME
481 .H2 "Digital Cryptography
482 .P
483 Signing and encryption.
486 .H2 "Good Defaults
487 .P
488 foo
493 .H1 "Code style
494 .P
495 foo
498 .H2 "Standard Code
499 .P
500 POSIX
503 .H2 "Separation
505 .U2 "MH Directory Split
506 .P
507 In MH and nmh, a personal setup had consisted of two parts:
508 The MH profile, named
509 .Fn \&.mh_profile
510 and being located directly in the user's home directory.
511 And the MH directory, where all his mail messages and also his personal
512 forms, scan formats, other configuration files are stored. The location
513 of this directory could be user-chosen. The default was to name it
514 .Fn Mail
515 and have it directly in the home directory.
516 .P
517 I've never liked the data storage and the configuration to be intermixed.
518 They are different kinds of data. One part, are the messages,
519 which are the data to operate on. The other part, are the personal
520 configuration files, which are able to change the behavior of the operations.
521 The actual operations are defined in the profile, however.
522 .P
523 When storing data, one should try to group data by its type.
524 There's sense in the Unix file system hierarchy, where configuration
525 file are stored separate (\c
526 .Fn /etc )
527 to the programs (\c
528 .Fn /bin
529 and
530 .Fn /usr/bin )
531 to their sources (\c
532 .Fn /usr/src ).
533 Such separation eases the backup management, for instance.
534 .P
535 In mmh, I've reorganized the file locations.
536 Still there are two places:
537 There's the mail storage directory, which, like in MH, contains all the
538 messages, but, unlike in MH, nothing else.
539 Its location still is user-chosen, with the default name
540 .Fn Mail ,
541 in the user's home directory. This is much similar to the case in nmh.
542 The configuration files, however, are grouped together in the new directory
543 .Fn \&.mmh
544 in the user's home directory.
545 The user's profile now is a file, named
546 .Fn profile ,
547 in this mmh directory.
548 Consistently, the context file and all the personal forms, scan formats,
549 and the like, are also there.
550 .P
551 The naming changed with the relocation.
552 The directory where everything, except the profile, had been stored (\c
553 .Fn $HOME/Mail ),
554 used to be called \fIMH directory\fP. Now, this directory is called the
555 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
556 the new directory
557 (\c
558 .Fn $HOME/.mmh ),
559 containing all the personal configuration files.
560 .P
561 The separation of the files by type of content is logical and convenient.
562 There are no functional differences as any possible setup known to me
563 can be implemented with both approaches, although likely a bit easier
564 with the new approach. The main goal of the change had been to provide
565 sensible storage locations for any type of personal mmh file.
566 .P
567 In order for one user to have multiple MH setups, he can use the
568 environment variable
569 .Ev MH
570 the point to a different profile file.
571 The MH directory (mail storage plus personal configuration files) is
572 defined by the
573 .Pe Path
574 profile entry.
575 The context file could be defined by the
576 .Pe context
577 profile entry or by the
578 .Ev MHCONTEXT
579 environment variable.
580 The latter is useful to have a distinct context (e.g. current folders)
581 in each terminal window, for instance.
582 In mmh, there are three environment variables now.
583 .Ev MMH
584 may be used to change the location of the mmh directory.
585 .Ev MMHP
586 and
587 .Ev MMHC
588 change the profile and context files, respectively.
589 Besides providing a more consistent feel (which simply is the result
590 of being designed anew), the set of personal configuration files can
591 be chosen independently from the profile (including mail storage location)
592 and context, now. Being it relevant for practical use or not, it
593 de-facto is an improvement. However, the main achievement is the
594 split between mail storage and personal configuration files.
597 .H2 "Modularization
598 .P
599 whatnowproc
600 .P
601 The \fIMH library\fP
602 .Fn libmh.a
603 collects a bunch of standard functions that many of the MH tools need,
604 like reading the profile or context files.
605 This doesn't hurt the separation.
608 .H2 "Style
609 .P
610 Code layout, goto, ...
615 .H1 "Concept Exploitation/Homogeniety
618 .H2 "Draft Folder
619 .P
620 Historically, MH provided exactly one draft message, named
621 .Fn draft
622 and
623 being located in the MH directory. When starting to compose another message
624 before the former one was sent, the user had been questioned whether to use,
625 refile or replace the old draft. Working on multiple drafts at the same time
626 was impossible. One could only work on them in alteration by refiling the
627 previous one to some directory and fetching some other one for reediting.
628 This manual draft management needed to be done each time the user wanted
629 to switch between editing one draft to editing another.
630 .P
631 To allow true parallel editing of drafts, in a straight forward way, the
632 draft folder facility exists. It had been introduced already in July 1984
633 by Marshall T. Rose. The facility was deactivated by default.
634 Even in nmh, the draft folder facility remained deactivated by default.
635 At least, Richard Coleman added the man page
636 .Mp mh-draft(5)
637 to document
638 the feature well.
639 .P
640 The only advantage of not using the draft folder facility is the static
641 name of the draft file. This could be an issue for MH frontends like mh-e.
642 But as they likely want to provide working on multiple drafts in parallel,
643 the issue is only concerning compatibility. The aim of nmh to stay compatible
644 prevented the default activation of the draft folder facility.
645 .P
646 On the other hand, a draft folder is the much more natural concept than
647 a draft message. MH's mail storage consists of folders and messages,
648 the messages named with ascending numbers. A draft message breaks with this
649 concept by introducing a message in a file named
650 .Fn draft .
651 This draft
652 message is special. It can not be simply listed with the available tools,
653 but instead requires special switches. I.e. corner-cases were
654 introduced. A draft folder, in contrast, does not introduce such
655 corner-cases. The available tools can operate on the messages within that
656 folder like on any messages within any mail folders. The only difference
657 is the fact that the default folder for
658 .Pn send
659 is the draft folder,
660 instead of the current folder, like for all other tools.
661 .P
662 The trivial part of the change was activating the draft folder facility
663 by default and setting a default name for this folder. Obviously, I chose
664 the name
665 .Fn +drafts .
666 This made the
667 .Sw \-draftfolder
668 and
669 .Sw \-draftmessage
670 switches useless, and I could remove them.
671 The more difficult but also the part that showed the real improvement,
672 was updating the tools to the new concept.
673 .Sw \-draft
674 switches could
675 be dropped, as operating on a draft message became indistinguishable to
676 operating on any other message for the tools.
677 .Pn comp
678 still has its
679 .Sw \-use
680 switch for switching between its two modes: (1) Compose a new
681 draft, possibly by taking some existing message as a form. (2) Modify
682 an existing draft. In either case, the behavior of
683 .Pn comp is
684 deterministic. There is no more need to query the user. I consider this
685 a major improvement. By making
686 .Pn send
687 simply operate on the current
688 message in the draft folder by default, with message and folder both
689 overridable by specifying them on the command line, it is now possible
690 to send a draft anywhere within the storage by simply specifying its folder
691 and name.
692 .P
693 All theses changes converted special cases to regular cases, thus
694 simplifying the tools and increasing the flexibility.
697 .H2 "Trash Folder
698 .P
699 Similar to the situation for drafts is the situation for removed messages.
700 Historically, a message was deleted by renaming. A specific
701 \fIbackup prefix\fP, often comma (\c
702 .Fn , )
703 or hash (\c
704 .Fn # ),
705 being prepended to the file name. Thus, MH wouldn't recognize the file
706 as a message anymore, as only files whose name consists of digits only
707 are treated as messages. The removed messages remained as files in the
708 same directory and needed some maintenance job to truly delete them after
709 some grace time. Usually, by running a command similar to
710 .DS
711 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
712 .DE
713 in a cron job. Within the grace time interval
714 the original message could be restored by stripping the
715 the backup prefix from the file name. If however, the last message of
716 a folder is been removed \(en say message
717 .Fn 6
718 becomes file
719 .Fn ,6
720 \(en and a new message enters the same folder, thus the same
721 numbered being given again \(en in our case
722 .Fn 6
723 \(en, if that one
724 is removed too, then the backup of the former message gets overwritten.
725 Thus, the ability to restore removed messages does not only depend on
726 the ``sweeping cron job'' but also on the removing of further messages.
727 This is undesirable, because the real mechanism is hidden from the user
728 and the consequences of further removals are not always obvious.
729 Further more, the backup files are scattered within the whole mail
730 storage, instead of being collected at one place.
731 .P
732 To improve the situation, the profile entry
733 .Pe rmmproc
734 (previously named
735 .Pe Delete-Prog )
736 was introduced, very early.
737 It could be set to any command, which would care for the mail removal
738 instead of taking the default action, described above.
739 Refiling the to-be-removed files to some garbage folder was a common
740 example. Nmh's man page
741 .Mp rmm(1)
742 proposes
743 .Cl "refile +d
744 to move messages to the garbage folder and
745 .Cl "rm `mhpath +d all`
746 the empty the garbage folder.
747 Managing the message removal this way is a sane approach. It keeps
748 the removed messages in one place, makes it easy to remove the backup
749 files, and, most important, enables the user to use the tools of MH
750 itself to operate on the removed messages. One can
751 .Pn scan
752 them,
753 .Pn show
754 them, and restore them with
755 .Pn refile .
756 There's no more
757 need to use
758 .Pn mhpath
759 to switch over from MH tools to Unix tools \(en MH can do it all itself.
760 .P
761 This approach matches perfect with the concepts of MH, thus making
762 it powerful. Hence, I made it the default. And even more, I also
763 removed the old backup prefix approach, as it is clearly less powerful.
764 Keeping unused alternative in the code is a bad choice as they likely
765 gather bugs, by not being constantly tested. Also, the increased code
766 size and more conditions crease the maintenance costs. By strictly
767 converting to the trash folder approach, I simplified the code base.
768 .Pn rmm
769 calls
770 .Pn refile
771 internally to move the to-be-removed
772 message to the trash folder (\c
773 .Fn +trash
774 by default). Messages
775 there can be operated on like on any other message in the storage.
776 The sweep clean, one can use
777 .Cl "rmm \-unlink +trash a" ,
778 where the
779 .Sw \-unlink
780 switch causes the files to be truly unliked instead
781 of moved to the trash folder.
784 .H2 "Path Notations
785 .P
786 foo
789 .H2 "MIME Integration
790 .P
791 user-visible access to whole messages and MIME parts are inherently
792 different
795 .H2 "Of One Cast
796 .P