docs/master
view ch03.roff @ 87:7d5b180de542
All kinds of rework plus new refs.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Tue, 12 Jun 2012 18:04:55 +0200 |
| parents | fb0d1b4c8fb1 |
| children | 30830e3b9e98 |
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.
6 The discussion compares the current version of mmh with the state of
7 nmh just before the mmh project started, i.e. Fall 2011.
8 Current changes of nmh will be mentioned only as side notes.
9 .\" XXX where do I discuss the parallel development of nmh?
13 .H1 "Stream-lining
15 .P
16 MH had been considered an all-in-one system for mail handling.
17 The community around nmh has a similar understanding.
18 In fundamental difference, mmh shall be a MUA only.
19 I believe that the development of all-in-one mail systems is obsolete.
20 Today, email is too complex to be fully covered by single projects.
21 Such a project won't be able to excel in all aspects.
22 Instead, the aspects of email should be covered my multiple projects,
23 which then can be combined to form a complete system.
24 Excellent implementations for the various aspects of email exist already.
25 Just to name three examples: Postfix is a specialized MTA,
26 Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
27 I believe that it is best to use such specilized tools instead of
28 providing the same function again as a side-component in the project.
29 .P
30 Doing something well, requires to focus on a small set of specific aspects.
31 Under the assumption that focused development produces better results
32 in the particular area, specialized projects will likely be superior
33 in their field of focus.
34 Hence, all-in-one mail system projects \(en no matter if monolithic
35 or modular \(en will never be the best choice in any of the fields.
36 Even in providing the best consistent all-in-one system they are likely
37 to be beaten by projects that focus only on integrating existing mail
38 components to a homogenious system.
39 .P
40 The limiting resource in Free Software community development
41 is usually man power.
42 If the development power is spread over a large development area,
43 it becomes even more difficult to compete with the specialists in the
44 various fields.
45 The concrete situation for MH-based mail systems is even tougher,
46 given the small and aged community, including both developers and users,
47 it has.
48 .P
49 In consequence, I believe that the available development resources
50 should be focused on the point where MH is most unique.
51 This is clearly the user interface \(en the MUA.
52 Peripheral parts should be removed to stream-line mmh for the MUA task.
55 .H2 "Removal of the Mail Transfer Facilities
56 .P
57 In contrast to nmh, which also provides mail submission and mail retrieval
58 agents, mmh is a MUA only.
59 This general difference in the view on the character of nmh
60 initiated the development of mmh.
61 Removing the mail transfer facilities had been the first work task
62 in the mmh project.
63 .P
64 The MSA is called \fIMessage Transfer Service\fP (MTS) in nmh.
65 The facility established network connections and spoke SMTP to submit
66 messages for relay to the outside world.
67 This part was implemented by the
68 .Pn post
69 command.
70 The changes in emailing in the last years
71 demanded changes in this part of nmh too.
72 Encryption and authetication for network connections
73 needed to be supported, hence TLS and SASL were introduced into nmh.
74 This added complexity to nmh without improving it in its core functions.
75 Also, keeping up with recent developments in the field of
76 mail transfer requires development power and specialists.
77 In mmh this whole facility was simply cut off.
78 .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
79 .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
80 .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
81 Instead, mmh depends on an external MSA.
82 The only outgoing interface available to mmh is the
83 .Pn sendmail
84 command, which almost any MSA provides.
85 If not, a wrapper program can be written.
86 It must read the message from the standard input, extract the
87 recipient addresses from the message header, and hand the message
88 over to the MSA.
89 For example, a wrapper script for qmail would be:
90 .VS
91 #!/bin/sh
92 # ignore command line arguments
93 exec qmail-inject
94 VE
95 The requirement to parse the recipient addresses out of the message header
96 is likely to be removed in the future.
97 Then mmh would give the recipient addresses as command line arguments.
98 This is clearly the better interface, but mmh does not provide it yet.
99 .\" XXX implement it
100 .P
101 To retrieve mail, the
102 .Pn inc
103 command established network connections
104 and spoke POP3 to retrieve mail from remote servers.
105 As with mail submission, the network connections required encryption and
106 authentication, thus TLS and SASL were added.
107 Support for message retrieval through IMAP will become necessary
108 to be added soon, too, and so on for any changes in mail transfer.
109 Mmh has dropped the support for retrieving mail from remote locations.
110 .Ci ab7b48411962d26439f92f35ed084d3d6275459c
111 Instead, it depends on an external tool to cover this task.
112 In mmh there exist two paths for messages to enter mmh's mail storage:
113 (1) Mail can be incorporate with
114 .Pn inc
115 from the system maildrop, or (2) with
116 .Pn rcvstore
117 by reading them, one at a time, from the standard input.
118 .P
119 With the removal of the MSA and MRA, mmh converted from an all-in-one
120 mail system to being a MUA only.
121 Following the Unix philosophy, it now focuses on one job and
122 tries to do that one well.
123 Not only the programs follow that tenet but also the project itself does so.
124 Now, of course, mmh depends on third-party software.
125 An external MSA is required to transfer mail to the outside world;
126 an external MRA is required to retrieve mail from remote machines.
127 There exist excellent implementations of such software,
128 which do this specific task likely better than the internal
129 versions had done it.
130 Also, the best suiting programs can be freely chosen.
131 .P
132 As it had already been possible to use an external MSA or MRA,
133 why not keep the internal version for convenience?
134 The question whether there is sense in having a fall-back pager in all
135 the command line tools, for the cases when
136 .Pn more
137 or
138 .Pn less
139 aren't available, appears to be ridiculous.
140 Now, an MSA or MRA is more complex than a text pager
141 and not necessarily available but still the concept of orthogonal
142 design holds: ``Write programs that do one thing and do it well.''
143 .[
144 mcilroy unix phil
145 p. 53
146 .]
147 .[
148 mcilroy bstj foreword
149 .]
150 Here, this part of the Unix philosophy was applied not only
151 to the programs but to the project itself.
152 In other words:
153 ``Develop projects that focus on one thing and do it well.''
154 Projects grown complex should be split for the same reasons programs grown
155 complex should be split.
156 If it is conceptionally more elegant to have the MSA and MRA
157 separate projects then they should be separated.
158 This is the case here, in my opinion.
159 The RFCs propose this separation by clearly distinguishing the different
160 mail handling tasks.
161 .[
162 rfc 821
163 .]
164 The small interfaces between the mail agents support the separation.
165 .P
166 In the beginning, email had been small and simple.
167 (\c
168 .Pn /bin/mail
169 had once covered anything there was to email and still had been small
170 and simple.)
171 Then the essential complexity of email increased.
172 (Essential complexity is the complexity defined by the problem itself.\0
173 .[[
174 brooks no silver bullet
175 .]])
176 Email systems reacted to this change: They grew.
177 RFCs started to introduce mail agents and separated the various tasks
178 because the existing tasks became more extensive and new tasks appeared.
179 Again, email systems grew, or they split parts off.
180 In nmh, for instance, the POP server, which the original MH had included,
181 was removed.
182 Now is the time to go one step further and remove the MSA and MRA, too.
183 Not only does this decrease the code size of the project,
184 but, more important, it unburdens mmh of the whole field of
185 message transfer with all its implications for the project.
186 There's no more need to concern with changes in network transfer.
187 This independence is received by depending on an external program
188 that covers the field.
189 Today, this is a reasonable exchange.
190 .P
191 Function can be added in three different ways:
192 .BU
193 Implementing the function originally in the project.
194 .BU
195 Depending on a library that provides the function.
196 .BU
197 Depending on a program that provides the function.
198 .P
199 Whereas adding the function originally to the project increases the
200 code size most and requires most maintenance and development work,
201 it makes the project most independent of other software.
202 Using libraries or external programs require less maintenance work
203 but introduces dependencies on external software.
204 Programs have the smallest interfaces and provide the best separation
205 but possibly limit the information exchange.
206 External libraries are stronger connected than external programs,
207 thus information can be exchanged more flexible.
208 Adding code to a project increases maintenance work.
209 .\" XXX ref
210 Implementing complex functions originally in the project will add
211 a lot of code.
212 This should be avoided if possible.
213 Hence, the dependencies only change in kind, not in their existence.
214 In mmh, library dependencies on
215 .Pn libsasl2
216 and
217 .Pn libcrypto /\c
218 .Pn libssl
219 were treated against program dependencies on an MSA and an MRA.
220 This also meant treating build-time dependencies against run-time
221 dependencies.
222 Besides program dependencies providing the stronger separation
223 and being more flexible, they also allowed
224 over 6\|000 lines of code to be removed from mmh.
225 This made mmh's code base about 12\|% smaller.
226 Reducing the project's code size by such an amount without actually
227 losing functionality is a convincing argument.
228 Actually, as external MSAs and MRAs are likely superior to the
229 project's internal versions, the common user even gains functionality.
230 .P
231 Users of MH should not have problems to set up an external MSA and MRA.
232 Also, the popular MSAs and MRAs have large communities and a lot
233 of documentation available.
234 Choices for MSAs range from full-featured MTAs like
235 .I Postfix
236 over mid-size MTAs like
237 .I masqmail
238 and
239 .I dma
240 to small forwarders like
241 .I ssmtp
242 and
243 .I nullmailer .
244 Choices for MRAs include
245 .I fetchmail ,
246 .I getmail ,
247 .I mpop
248 and
249 .I fdm .
252 .H2 "Removal of non-MUA Tools
253 .P
254 One goal of mmh is to remove the tools that are not part of the MUA's task.
255 Further more, any tools that don't improve the MUA's job significently
256 should be removed.
257 Loosely related and rarely used tools distract from the lean appearance.
258 They require maintenance work without adding much to the core task.
259 On removing these tools, the project shall become more stream-lined
260 and focused.
261 In mmh the following tools are not available anymore:
262 .BU
263 .Pn conflict
264 was removed
265 .Ci 8b235097cbd11d728c07b966cf131aa7133ce5a9
266 because it is a mail system maintenance tool that is not MUA-related.
267 It even checked
268 .Fn /etc/passwd
269 and
270 .Fn /etc/group
271 for consistency, which is completely unrelated to email.
272 A tool like
273 .Pn conflict
274 is surely useful, but it should not be shipped with mmh.
275 .\" XXX historic reasons?
276 .BU
277 .Pn rcvtty
278 was removed
279 .Ci 14767c94b3827be7c867196467ed7aea5f6f49b0
280 because its usecase of writing to the user's terminal
281 on receiving of mail is obsolete.
282 If users like to be informed of new mail, the shell's
283 .Ev MAILPATH
284 variable or graphical notifications are technically more appealing.
285 Writing directly to a terminals is hardly ever wanted today.
286 If though one wants to have it this way, the standard tool
287 .Pn write
288 can be used in a way similar to:
289 .VS
290 scan -file - | write `id -un`
291 VE
292 .BU
293 .Pn viamail
294 was removed
295 .Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932
296 when the new attachment system was activated, because
297 .Pn forw
298 could then cover the task itself.
299 The program
300 .Pn sendfiles
301 was rewritten as a shell script wrapper around
302 .Pn forw .
303 .Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6
304 .BU
305 .Pn msgchk
306 was removed
307 .Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe ,
308 because it lost its use case when POP support was removed.
309 A call to
310 .Pn msgchk
311 provided hardly more information than:
312 .VS
313 ls -l /var/mail/meillo
314 VE
315 It did distinguished between old and new mail, but
316 this detail information and can be retrieved with
317 .Pn stat (1),
318 too.
319 A very small shell script could be written to output the information
320 in a similar way, if truly necessary.
321 As mmh's
322 .Pn inc
323 only incorporates mail from the user's local maildrop,
324 and thus no data transfers over slow networks are involved,
325 there's hardly any need to check for new mail before incorporating it.
326 .BU
327 .Pn msh
328 was removed
329 .Ci 916690191222433a6923a4be54b0d8f6ac01bd02
330 because the tool was in conflict with the philosophy of MH.
331 It provided an interactive shell to access the features of MH,
332 but it wasn't just a shell, tailored to the needs of mail handling.
333 Instead it was one large program that had several MH tools built in.
334 This conflicts with the major feature of MH of being a tool chest.
335 .Pn msh 's
336 main use case had been accessing Bulletin Boards, which have seized to
337 be popular.
338 .P
339 Removing
340 .Pn msh ,
341 together with the truly archaic code relicts
342 .Pn vmh
343 and
344 .Pn wmh ,
345 saved more than 7\|000 lines of C code \(en
346 about 15\|% of the project's original source code amount.
347 .P
348 Having less code (with equal readability, of course)
349 for the same functionality is an advantage.
350 Less code means less bugs and less maintenance work.
351 As
352 .Pn rcvtty
353 and
354 .Pn msgchk
355 are assumed to be rarely used and can be implemented in different ways,
356 why should one keep them?
357 Removing them stream-lines mmh.
358 .Pn viamail 's
359 use case is now partly obsolete and partly covered by
360 .Pn forw ,
361 hence there's no reason to still maintain it.
362 .Pn conflict
363 is not related to the mail client, and
364 .Pn msh
365 conflicts with the basic concept of MH.
366 Theses two tools might still be useful, but they should not be part of mmh.
367 .P
368 Finally, there's
369 .Pn slocal .
370 .Pn slocal
371 is an MDA and thus not directly MUA-related.
372 It should be removed, because including it is a violation
373 of the idea that mmh is a MUA only.
374 It should become a separate project.
375 However,
376 .Pn slocal
377 provides rule-based processing of messages, like filing them into
378 different folders, which is otherwise not available in mmh.
379 Although
380 .Pn slocal
381 does neither pull in dependencies nor does it include a separate
382 technical area (cf. Sec. XXX),
383 still it accounts for about 1\|000 lines of code that need to be maintained.
384 As
385 .Pn slocal
386 is almost self-standing, it should be split off into a separate project.
387 This would cut the strong connection between the MUA mmh and the MDA
388 .Pn slocal .
389 For anyone not using MH,
390 .Pn slocal
391 would become yet another independent MDA, like
392 .I procmail .
393 The need to install a complete MH system to have
394 .Pn slocal
395 would be gone.
396 Likewise, mmh users could decide to use
397 .I procmail
398 without having a second, unused MDA,
399 .Pn slocal ,
400 installed.
401 That's conceptionally the best solution.
402 Yet,
403 .Pn slocal
404 is not split off.
405 I feel unsure with removing it from mmh.
406 Hence, I defer the decision over
407 .Pn slocal .
408 In the meanwhile
409 .Pn slocal
410 does not hurt because it is unrelated to the rest of mmh.
413 .H2 "\fLshow\fP and \fPmhshow\fP
414 .P
415 Since the very beginning \(en already in the first concept paper \(en
416 .Pn show
417 had been MH's message display program.
418 .Pn show
419 mapped message numbers and sequences to files and invoked
420 .Pn mhl
421 to have the files formated.
422 For MIME, this approach wasn't sufficient anymore.
423 MIME messages can consist of multiple parts, some of which aren't
424 directly displayable, and text content might be encoded in
425 foreign charsets.
426 .Pn show 's
427 understanding of messages and
428 .Pn mhl 's
429 limited display facilities couldn't cope with the task any longer.
430 .P
431 Instead of extending these tools, additional tools were written from scratch
432 and then added to the MH tool chest. Doing so is encouraged by the
433 tool chest approach. The new tools could be added without interfering
434 with the existing ones.
435 Modular design is a great advantage for extending a system.
436 First, the new MIME features were added in form of the single program
437 .Pn mhn .
438 The command
439 .Cl "mhn -show 42
440 would show the MIME message numbered 42.
441 With the 1.0 release of nmh in February 1999, Richard Coleman finished
442 the split of
443 .Pn mhn
444 into a set of specialized programs, which together covered the
445 multiple aspects of MIME. One of these resulting tools was
446 .Pn mhshow ,
447 which replaced the
448 .Cl "mhn -show
449 call.
450 It was capable to display a MIME message appropriately.
451 .P
452 From then on, two message display tools were part of nmh:
453 .Pn show
454 and
455 .Pn mhshow .
456 Because the user should not need to invoke the right tool
457 whether the message uses MIME or not,
458 .Pn show
459 was extended to automatically hand the job over to
460 .Pn mhshow
461 if displaying the message would be beyond
462 .Pn show 's
463 abilities.
464 In consequence, the user would invoke
465 .Pn show
466 (possibly through
467 .Pn next
468 or
469 .Pn prev )
470 and get the message printed with either
471 .Pn show
472 or
473 .Pn mhshow ,
474 whatever was more appropriate.
475 (There was also a switch for
476 .Pn show
477 to never invoke
478 .Pn mhshow .
479 .Pn show
480 was able to display MIME messages if they contained only a single text
481 part.)
482 .P
483 Having two similar tools for essentially the same task is redundant.
484 The development of both programs needed to be in sync,
485 to ensure that the programs behaved in a similar way,
486 because they were used like a single tool.
487 Different behavior would have surprised the user.
488 .P
489 Today, non-MIME messages are rather seen to be a special case of
490 MIME messages, than MIME messages are seen to be an extension to
491 original email.
492 As
493 .Pn mhshow
494 had already be able to display non-MIME messages, it was natural
495 to drop
496 .Pn show
497 in favor of using
498 .Pn mhshow
499 exclusively.
500 This decision followed the idea of orthogonal design.
501 For convenience,
502 .Pn mhshow
503 was then renamed to
504 .Pn show .
505 .Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
506 .P
507 To prepare for this transition,
508 .Pn mhshow
509 was reworked to behave more like
510 .Pn show
511 first.
512 (Section XXX describes this rework from a different perspective.)
513 Once the tools behaved similar, the replacing became a natural decision.
514 In mmh,
515 .Pn show
516 is the one single message display program again, but it handles
517 MIME messages as well as non-MIME messages.
518 Now, there's only one program to maintain, and users don't need to deal
519 with the existance of two display programs.
520 .P
521 There's one reason why removing the old
522 .Pn show
523 hurts: It had been such a simple program.
524 Its lean elegance is missing to
525 .Pn mhshow ,
526 i.e. the new
527 .Pn show .
528 But there is no chance, because supporting MIME causes essentially
529 higher complexity.
532 .H2 "Removal of Configure Options
533 .P
534 Customization is a double-edged sword.
535 It allows better suiting setups, but not for free.
536 There is the cost of code complexity to be able to customize.
537 There is the cost of less tested setups, because there are
538 more possible setups and especially corner-cases.
539 And, there is the cost of choice itself.
540 The code complexity directly affects the developers.
541 Less tested code affects both, users and developers.
542 The problem of choice affects the users, for once by having to
543 choose, but also by complexer interfaces that require more documentation.
544 Whenever options add little advantages, they should be considered for
545 removal.
546 I have reduced the number of project-specific configure options from
547 fifteen to three.
549 .U3 "Mail Transfer Facilities
550 .P
551 With the removal of the mail transfer facilities five configure
552 options vanished:
553 .P
554 The switches
555 .Sw --with-tls
556 and
557 .Sw --with-cyrus-sasl
558 had activated the support for transfer encryption and authetication.
559 This is not needed anymore.
560 .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
561 .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
562 .P
563 The configure switch
564 .Sw --enable-pop
565 activated the message retrieval facility.
566 The code area that would be conditionally compiled in for TLS and SASL
567 support had been small.
568 The conditionally compiled code area for POP support had been much larger.
569 Whereas the code base changes would only slightly change on toggling
570 TLS or SASL support, it changed much on toggling POP support.
571 The changes in the code base could hardly be overviewed.
572 By having POP support togglable a second code base had been created,
573 one that needed to be tested.
574 This situation is basically similar for the conditional TLS and SASL
575 code, but there the changes are minor and can yet be overviewed.
576 Still, conditional compilation of a code base creates variations
577 of the original program.
578 More variations require more testing and maintenance work.
579 .P
580 Two other options only specified default configuration values:
581 .Sw --with-mts=[smtp|sendmail]
582 defined the default transport service.
583 In mmh this fixed to
584 .Ar sendmail .
585 .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
586 With
587 .Sw --with-smtpservers=[server1...]
588 default SMTP servers for the
589 .Ar smtp
590 transport service could be specified.
591 .Ci 128545e06224233b7e91fc4c83f8830252fe16c9
592 Both of them became irrelevant.
594 .U3 "Backup Prefix
595 .P
596 The backup prefix is the string that was prepended to message
597 filenames to tag them as deleted.
598 By default it had been the comma character `\f(CW,\fP'.
599 In July 2000, Kimmo Suominen introduced
600 the configure option
601 .Sw --with-hash-backup
602 to change the default to the hash symbol `\f(CW#\fP'.
603 The choice was probably personal preference, because first, the
604 option was named
605 .Sw --with-backup-prefix.
606 and had the prefix symbol as argument.
607 Because giving the hash symbol as argument caused to many problems
608 for configure,
609 the option was limited to use the hash symbol as the default prefix.
610 This makes me believe, that the choice for the hash was personal preference.
611 Being it related or not, words that start with the hash symbol
612 introduce a comment in the Unix shell.
613 Thus, the command line
614 .Cl "rm #13 #15
615 calls
616 .Pn rm
617 without arguments because the first hash symbol starts the comment
618 that reaches until the end of the line.
619 To delete the backup files,
620 .Cl "rm ./#13 ./#15"
621 needs to be used.
622 Using the hash as backup prefix can be seen as a precaution agains
623 data loss.
624 .P
625 I removed the configure option but added the profile entry
626 .Pe backup-prefix ,
627 which allows to specify an arbitrary string as backup prefix.
628 .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
629 Profile entries are the common method to change mmh's behavior.
630 This change did not remove the choice but moved it to a location where
631 it suited better.
632 .P
633 Eventually, however, the new trash folder concept
634 .Cf "Sec. XXX
635 obsoleted the concept of the backup prefix completely.
636 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
637 (Well, there still are corner-cases to remove until the backup
638 prefix can be layed to rest, eventually.)
639 .\" FIXME: Do this work in the code!
641 .U3 "Editor and Pager
642 .P
643 The two configure options
644 .CW --with-editor=EDITOR
645 .CW --with-pager=PAGER
646 were used to specify the default editor and pager at configure time.
647 Doing so at configure time made sense in the Eighties,
648 when the set of available editors and pagers varied much across
649 different systems.
650 Today, the situation is more homegeneic.
651 The programs
652 .Pn vi
653 and
654 .Pn more
655 can be expected to be available on every Unix system,
656 as they are specified by POSIX since two decades.
657 (The specifications for
658 .Pn vi
659 and
660 .Pn more
661 appeared in
662 .[
663 posix 1987
664 .]
665 and,
666 .[
667 posix 1992
668 .]
669 respectively.)
670 As a first step, these two tools were hard-coded as defaults.
671 .Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f
672 Not changed were the
673 .Pe editor
674 and
675 .Pe moreproc
676 profile entries, which allowed the user to override the system defaults.
677 Later, the concept was reworked to respect the standard environment
678 variables
679 .Ev VISUAL
680 and
681 .Ev PAGER
682 if they are set.
683 Today, mmh determines the editor to use in the following order,
684 taking the first available and non-empty item:
685 .IP (1)
686 Environment variable
687 .Ev MMHEDITOR
688 .IP (2)
689 Profile entry
690 .Pe Editor
691 .IP (3)
692 Environment variable
693 .Ev VISUAL
694 .IP (4)
695 Environment variable
696 .Ev EDITOR
697 .IP (5)
698 Command
699 .Pn vi .
700 .P
701 .Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
702 .P
703 The pager to use is deteminded in a similar order,
704 also taking the first available and non-empty item:
705 .IP (1)
706 Environment variable
707 .Ev MMHPAGER
708 .IP (2)
709 Profile entry
710 .Pe Pager
711 (replaces
712 .Pe moreproc )
713 .IP (3)
714 Environment variable
715 .Ev PAGER
716 .IP (4)
717 Command
718 .Pn more .
719 .P
720 .Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e
721 .P
722 By respecting the
723 .Ev VISUAL /\c
724 .Ev EDITOR
725 and
726 .Ev PAGER
727 environment variables,
728 the new behavior confirms better to the common style on Unix systems.
729 Additionally, the new approach is more uniform and clearer to users.
731 .U3 "Locale
732 .P
733 The configure option
734 .Sw --disable-locale
735 was removed because POSIX provides locale support and there's
736 hardly any need to disable locale support.
737 .Ci ccf4f175ef4c4e7522f9510a4a1149c15d810dd9
739 .U3 "ndbm
740 .P
741 .Pn slocal
742 used to depend on
743 .I ndbm ,
744 a database library.
745 The database is used to store the `\fLMessage-ID\fP's of all
746 messages delivered.
747 This enables
748 .Pn slocal
749 to suppress delivering the same message to the same user twice.
750 (This features was enabled by the
751 .Sw -suppressdup
752 switch.)
753 .P
754 A variety of version of the database library exist.
755 .[
756 wolter unix incompat notes dbm
757 .]
758 Complicated autoconf code was needed to detect them correctly.
759 Further more, the configure switches
760 .Sw --with-ndbm=ARG
761 and
762 .Sw --with-ndbmheader=ARG
763 were added to help with difficult setups that would
764 not be detected automatically or correctly.
765 .P
766 By removing the suppress duplicates feature of
767 .Pn slocal ,
768 the dependency on
769 .I ndbm
770 vanished and 120 lines of complex autoconf code could be saved.
771 .Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
772 The change removed funtionality too, but that is minor to the
773 improvement by dropping the dependency and the complex autoconf code.
775 .U3 "mh-e Support
776 .P
777 The configure option
778 .Sw --disable-mhe
779 was removed when the mh-e support was reworked.
780 Mh-e is the Emacs front-end to MH.
781 It requires MH to provide minor additional functions.
782 The
783 .Sw --disable-mhe
784 configure option could switch these extensions off.
785 After removing the support for old versions of mh-e,
786 only the
787 .Sw -build
788 switches of
789 .Pn forw
790 and
791 .Pn repl
792 are left to be mh-e extensions.
793 They are now always built in because they add little code and complexity.
794 In consequence, the
795 .Sw --disable-mhe
796 configure option was removed
797 .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
798 Removing the option removed a second code setup that would have
799 needed to be tested.
800 This change was first done in nmh and thereafter merged into mmh.
801 .P
802 The interface changes in mmh require mh-e to be adjusted in order
803 to be able to use mmh as back-end.
804 This will require minor changes to mh-e, but removing the
805 .Sw -build
806 switches would require more rework.
808 .U3 "Masquerading
809 .P
810 The configure option
811 .Sw --enable-masquerade
812 could take up to three arguments:
813 `draft_from', `mmailid', and `username_extension'.
814 They activated different types of address masquerading.
815 All of them were implemented in the SMTP-speaking
816 .Pn post
817 command, which provided an MSA.
818 Address masquerading is an MTA's task and mmh does not cover
819 this field anymore.
820 Hence, true masquerading needs to be implemented in the external MTA.
821 .P
822 The
823 .I mmailid
824 masquerading type is the oldest one of the three and the only one
825 available in the original MH.
826 It provided a
827 .I username
828 to
829 .I fakeusername
830 mapping, based on the password file's GECOS field.
831 The man page
832 .Mp mh-tailor(5)
833 described the use case as being the following:
834 .QP
835 This is useful if you want the messages you send to always
836 appear to come from the name of an MTA alias rather than your
837 actual account name. For instance, many organizations set up
838 `First.Last' sendmail aliases for all users. If this is
839 the case, the GECOS field for each user should look like:
840 ``First [Middle] Last <First.Last>''
841 .P
842 As mmh sends outgoing mail via the local MTA only,
843 the best location to do such global rewrites is there.
844 Besides, the MTA is conceptionally the right location because it
845 does the reverse mapping for incoming mail (aliasing), too.
846 Further more, masquerading set up there is readily available for all
847 mail software on the system.
848 Hence, mmailid masquerading was removed.
849 .Ci 0836c8000ccb34b59410ef1c15b1b7feac70ce5f
850 .P
851 The
852 .I username_extension
853 masquerading type did not replace the username but would append a suffix,
854 specified by the
855 .Ev USERNAME_EXTENSION
856 environment variable, to it.
857 This provided support for the
858 .I user-extension
859 feature of qmail and the similar
860 .I "plussed user
861 processing of sendmail.
862 The decision to remove this username_extension masquerading was
863 motivated by the fact that
864 .Pn spost
865 hadn't supported it already.
866 .Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
867 Username extensions are possible in mmh, but less convenient to use.
868 .\" XXX format file %(getenv USERNAME_EXTENSION)
869 .P
870 The
871 .I draft_from
872 masquerading type instructed
873 .Pn post
874 to use the value of the
875 .Hd From
876 header field as SMTP envelope sender.
877 Sender addresses could be replaced completely.
878 .Ci b14ea6073f77b4359aaf3fddd0e105989db9
879 Mmh offers a kind of masquerading similar in effect, but
880 with technical differences.
881 As mmh does not transfer messages itself, the local MTA has final control
882 over the sender's address. Any masquerading mmh introduces may be reverted
883 by the MTA.
884 In times of pedantic spam checking, an MTA will take care to use
885 sensible envelope sender addresses to keep its own reputation up.
886 Nonetheless, the MUA can set the
887 .Hd From
888 header field and thereby propose
889 a sender address to the MTA.
890 The MTA may then decide to take that one or generate the canonical sender
891 address for use as envelope sender address.
892 .P
893 In mmh, the MTA will always extract the recipient and sender from the
894 message header (\c
895 .Pn sendmail 's
896 .Sw -t
897 switch).
898 The
899 .Hd From
900 header field of the draft may be set arbitrary by the user.
901 If it is missing, the canonical sender address will be generated by the MTA.
903 .U3 "Remaining Options
904 .P
905 Two configure options remain in mmh.
906 One is the locking method to use:
907 .Sw --with-locking=[dot|fcntl|flock|lockf] .
908 The idea of removing all methods except the portable dot locking
909 and having that one as the default is appealing, but this change
910 requires deeper technical investigation into the topic.
911 The other option,
912 .Sw --enable-debug ,
913 compiles the programs with debugging symbols and does not strip them.
914 This option is likely to stay.
919 .H2 "Removal of switches
920 .P
925 .H1 "Modernizing
928 .H2 "Removal of Code Relicts
929 .P
930 The code base of mmh originates from the late Seventies,
931 had been extensively
932 worked on in the mid Eighties, and had been partly reorganized and extended
933 in the Nineties. Relicts of all those times had gathered in the code base.
934 My goal was to remove any ancient code parts. One part of the task was
935 converting obsolete code constructs to standard constructs, the other part
936 was dropping obsolete functions.
937 .P
938 As I'm not even thirty years old and have no more than seven years of
939 Unix experience, I needed to learn about the history in retrospective.
940 Older people likely have used those ancient constructs themselves
941 and have suffered from their incompatibilities and have longed for
942 standardization. Unfortunately, I have only read that others had done so.
943 This put me in a much more difficult positions when working on the old
944 code. I needed to recherche what other would have known by heart from
945 experience. All my programming experience comes from a time past ANSI C
946 and past POSIX. Although I knew about the times before, I took the
947 current state implicitly for granted most of the time.
948 .P
949 Being aware of
950 these facts, I rather let people with more historic experience solve the
951 task of converting the ancient code constructs to standardized ones.
952 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
953 He converted large parts of the code to POSIX constructs, removing
954 the conditionals compilation for now standardized features.
955 I'm thankful for this task being solved. I only pulled the changes into
956 mmh.
957 .P
958 The other task \(en dropping ancient functionality to remove old code \(en
959 I did myself, though. My position to strip mmh to the bare minimum of
960 frequently used features is much more revolutional than the nmh community
961 likes it. Without the need to justify my decisions, I was able to quickly
962 remove functionality I considered ancient.
963 The need to discuss my decisions with
964 peers likely would have slowed this process down. Of course, I researched
965 if a particular feature really should be dropped. Having not had any
966 contact to this feature within my computer life was a first indicator to
967 drop it, but I also asked others and searched the literature for modern
968 usage of the feature. If it appeared to be truly ancient, I dropped it.
969 The reason for dropping is always part of the commit message in the
970 version control system. Thus, it is easy for others to check their
971 view on the topic with mine and possibly to argue for reinclusion.
973 .U2 "MMDF maildrop support
974 .P
975 I did drop any support for the MMDF maildrop format. This type of format
976 is conceptionally similar to the mbox format, but uses four bytes with
977 value 1 (\fL^A^A^A^A\fP) as message delimiter,
978 instead of the string ``\fLFrom\ \fP''.
979 Due to the similarity and mbox being the de-facto standard maildrop
980 format on Unix, but also due to the larger influence of Sendmail than MMDF,
981 the MMDF maildrop format had vanished.
982 .P
983 The simplifications within the code were only moderate. Switches could
984 be removed from tools like
985 .L packf ,
986 which generate packed mailboxes. Only one packed mailbox format remained:
987 mbox.
988 The most important changes affect the equally named mail parsing routine in
989 .L sbr/m_getfld.c .
990 The direct MMDF code had been removed, but as now only one packed mailbox
991 format is left, code structure simplifications are likely possible.
992 The reason why they are still outstanding is the heavily optimized code
993 of
994 .Fu m_getfld() .
995 Changes beyond a small local scope \(en
996 which restructuring in its core is \(en cause a high risk of damaging
997 the intricate workings of the optimized code. This problem is know
998 to the developers of nmh, too. They also avoid touching this minefield
999 if possible.
1001 .U2 "UUCP Bang Paths
1002 .P
1003 More questionably than the former topic is the removal of support for the
1004 UUCP bang path address style. However, the user may translate the bang
1005 paths on retrieval to Internet addresses and the other way on posting
1006 messages. The former can be done my an MDA like procmail; the latter
1007 by a sendmail wrapper. This would ensure that any address handling would
1008 work as expected. However, it might just work well without any
1009 such modifications, as mmh does not touch addresses much, in general.
1010 But I can't ensure as I have never used an environment with bang paths.
1011 Also, the behavior might break at any point in further development.
1013 .U2 "Hardcopy terminal support
1014 .P
1015 More of a funny anecdote is the remaining of a check for printing to a
1016 hardcopy terminal until Spring 2012, when I finally removed it.
1017 I surely would be very happy to see such a terminal in action, maybe
1018 actually being able to work on it, but I fear my chances are null.
1019 .P
1020 The check only prevented a pager to be placed between the outputting
1021 program (\c
1022 .Pn mhl )
1023 and the terminal. This could have been ensured with
1024 the
1025 .Sw -nomoreproc
1026 at the command line statically, too.
1028 .U2 "Removed support for header fields
1029 .P
1030 The
1031 .Hd Encrypted
1032 header field had been introduced by RFC\^822, but already
1033 marked legacy in RFC 2822. It was superseded by FIXME.
1034 Mmh does no more support this header field.
1035 .P
1036 Native support for
1037 .Hd Face
1038 header fields had been removed, as well.
1039 The feature is similar to the
1040 .Hd X-Face
1041 header field in its intent,
1042 but takes a different approach to store the image.
1043 Instead of encoding the image data directly into the header field,
1044 the it contains the hostname and UDP port where the image
1045 date could be retrieved.
1046 Neither
1047 .Hd X-Face
1048 nor the here described
1049 .Hd Face
1050 system
1051 \**
1052 .FS
1053 There is also a newer but different system, invented 2005,
1054 using
1055 .Hd Face
1056 headers.
1057 It is the successor of
1058 .Hd X-Face
1059 providing colored PNG images.
1060 .FE
1061 became well used in the large scale.
1062 It's still possible to use a Face systems,
1063 although mmh does not provide support for any of the different systems
1064 anymore. It's fairly easy to write a small shell script to
1065 extract the embedded or fetch the external Face data and display the image.
1066 Own
1067 .Hd Face
1068 header field can be added into the draft template files.
1069 .P
1070 .Hd Content-MD5
1071 header fields were introduced by RFC\^1864. They provide only
1072 a verification of data corruption during the transfer. By no means can
1073 they ensure verbatim end-to-end delivery of the contents. This is clearly
1074 stated in the RFC. The proper approach to provide verificationability
1075 of content in an end-to-end relationship is the use of digital cryptography
1076 (RFCs FIXME). On the other hand, transfer protocols should ensure the
1077 integrity of the transmission. In combinations these two approaches
1078 make the
1079 .Hd Content-MD5
1080 header field useless. In consequence, I removed
1081 the support for it. By this removal, MD5 computation is not needed
1082 anywhere in mmh. Hence, over 500 lines of code were removed by this one
1083 change. Even if the
1084 .Hd Content-MD5
1085 header field is useful sometimes,
1086 I value its usefulnes less than the improvement in maintainability, caused
1087 by the removal.
1089 .U2 "Prompter's Control Keys
1090 .P
1091 The program
1092 .Pn prompter
1093 queries the user to fill in a message form. When used by
1094 .Pn comp
1095 as:
1096 .VS
1097 comp -editor prompter
1098 VE
1099 the resulting behavior is similar to
1100 .Pn mailx .
1101 Apparently,
1102 .Pn prompter
1103 hadn't been touched lately. Otherwise it's hardly explainable why it
1104 still offered the switches
1105 .Sw -erase
1106 .Ar chr
1107 and
1108 .Sw -kill
1109 .Ar chr
1110 to name the characters for command line editing.
1111 The times when this had been necessary are long time gone.
1112 Today these things work out-of-the-box, and if not, are configured
1113 with the standard tool
1114 .Pn stty .
1116 .U2 "Vfork and Retry Loops
1117 .P
1118 MH creates many processes, which is a consequence of the tool chest approach.
1119 In earlier times
1120 .Fu fork()
1121 had been an expensive system call, as the process's whole image needed
1122 to be duplicated. One common case is replacing the image with
1123 .Fu exec()
1124 right after having forked the child process.
1125 To speed up this case, the
1126 .Fu vfork()
1127 system call was invented at Berkeley. It completely omits copying the
1128 image. If the image gets replaced right afterwards then unnecessary
1129 work is omited. On old systems this results in large speed ups.
1130 MH uses
1131 .Fu vfork()
1132 whenever possible.
1133 .P
1134 Memory management units that support copy-on-write semantics make
1135 .Fu fork()
1136 almost as fast as
1137 .Fu vfork()
1138 in the cases when they can be exchanged.
1139 With
1140 .Fu vfork()
1141 being more error-prone and hardly faster, it's preferable to simply
1142 use
1143 .Fu fork()
1144 instead.
1145 .P
1146 Related to the costs of
1147 .Fu fork()
1148 is the probability of its success.
1149 Today on modern systems, the system call will succeed almost always.
1150 In the Eighties on heavy loaded systems, as they were common at
1151 universities, this had been different. Thus, many of the
1152 .Fu fork()
1153 calls were wrapped into loops to retry to fork several times in
1154 short intervals, in case of previous failure.
1155 In mmh, the program aborts at once if the fork failed.
1156 The user can reexecute the command then. This is expected to be a
1157 very rare case on modern systems, especially personal ones, which are
1158 common today.
1161 .H2 "Attachments
1162 .P
1163 MIME
1166 .H2 "Digital Cryptography
1167 .P
1168 Signing and encryption.
1171 .H2 "Good Defaults
1172 .P
1173 foo
1178 .H1 "Code style
1179 .P
1180 foo
1183 .H2 "Standard Code
1184 .P
1185 POSIX
1188 .H2 "Separation
1190 .U2 "MH Directory Split
1191 .P
1192 In MH and nmh, a personal setup had consisted of two parts:
1193 The MH profile, named
1194 .Fn \&.mh_profile
1195 and being located directly in the user's home directory.
1196 And the MH directory, where all his mail messages and also his personal
1197 forms, scan formats, other configuration files are stored. The location
1198 of this directory could be user-chosen. The default was to name it
1199 .Fn Mail
1200 and have it directly in the home directory.
1201 .P
1202 I've never liked the data storage and the configuration to be intermixed.
1203 They are different kinds of data. One part, are the messages,
1204 which are the data to operate on. The other part, are the personal
1205 configuration files, which are able to change the behavior of the operations.
1206 The actual operations are defined in the profile, however.
1207 .P
1208 When storing data, one should try to group data by its type.
1209 There's sense in the Unix file system hierarchy, where configuration
1210 file are stored separate (\c
1211 .Fn /etc )
1212 to the programs (\c
1213 .Fn /bin
1214 and
1215 .Fn /usr/bin )
1216 to their sources (\c
1217 .Fn /usr/src ).
1218 Such separation eases the backup management, for instance.
1219 .P
1220 In mmh, I've reorganized the file locations.
1221 Still there are two places:
1222 There's the mail storage directory, which, like in MH, contains all the
1223 messages, but, unlike in MH, nothing else.
1224 Its location still is user-chosen, with the default name
1225 .Fn Mail ,
1226 in the user's home directory. This is much similar to the case in nmh.
1227 The configuration files, however, are grouped together in the new directory
1228 .Fn \&.mmh
1229 in the user's home directory.
1230 The user's profile now is a file, named
1231 .Fn profile ,
1232 in this mmh directory.
1233 Consistently, the context file and all the personal forms, scan formats,
1234 and the like, are also there.
1235 .P
1236 The naming changed with the relocation.
1237 The directory where everything, except the profile, had been stored (\c
1238 .Fn $HOME/Mail ),
1239 used to be called \fIMH directory\fP. Now, this directory is called the
1240 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
1241 the new directory
1242 (\c
1243 .Fn $HOME/.mmh ),
1244 containing all the personal configuration files.
1245 .P
1246 The separation of the files by type of content is logical and convenient.
1247 There are no functional differences as any possible setup known to me
1248 can be implemented with both approaches, although likely a bit easier
1249 with the new approach. The main goal of the change had been to provide
1250 sensible storage locations for any type of personal mmh file.
1251 .P
1252 In order for one user to have multiple MH setups, he can use the
1253 environment variable
1254 .Ev MH
1255 the point to a different profile file.
1256 The MH directory (mail storage plus personal configuration files) is
1257 defined by the
1258 .Pe Path
1259 profile entry.
1260 The context file could be defined by the
1261 .Pe context
1262 profile entry or by the
1263 .Ev MHCONTEXT
1264 environment variable.
1265 The latter is useful to have a distinct context (e.g. current folders)
1266 in each terminal window, for instance.
1267 In mmh, there are three environment variables now.
1268 .Ev MMH
1269 may be used to change the location of the mmh directory.
1270 .Ev MMHP
1271 and
1272 .Ev MMHC
1273 change the profile and context files, respectively.
1274 Besides providing a more consistent feel (which simply is the result
1275 of being designed anew), the set of personal configuration files can
1276 be chosen independently from the profile (including mail storage location)
1277 and context, now. Being it relevant for practical use or not, it
1278 de-facto is an improvement. However, the main achievement is the
1279 split between mail storage and personal configuration files.
1282 .H2 "Modularization
1283 .P
1284 whatnowproc
1285 .P
1286 The \fIMH library\fP
1287 .Fn libmh.a
1288 collects a bunch of standard functions that many of the MH tools need,
1289 like reading the profile or context files.
1290 This doesn't hurt the separation.
1293 .H2 "Style
1294 .P
1295 Code layout, goto, ...
1300 .H1 "Concept Exploitation/Homogeniety
1303 .H2 "Draft Folder
1304 .P
1305 Historically, MH provided exactly one draft message, named
1306 .Fn draft
1307 and
1308 being located in the MH directory. When starting to compose another message
1309 before the former one was sent, the user had been questioned whether to use,
1310 refile or replace the old draft. Working on multiple drafts at the same time
1311 was impossible. One could only work on them in alteration by refiling the
1312 previous one to some directory and fetching some other one for reediting.
1313 This manual draft management needed to be done each time the user wanted
1314 to switch between editing one draft to editing another.
1315 .P
1316 To allow true parallel editing of drafts, in a straight forward way, the
1317 draft folder facility exists. It had been introduced already in July 1984
1318 by Marshall T. Rose. The facility was deactivated by default.
1319 Even in nmh, the draft folder facility remained deactivated by default.
1320 At least, Richard Coleman added the man page
1321 .Mp mh-draft(5)
1322 to document
1323 the feature well.
1324 .P
1325 The only advantage of not using the draft folder facility is the static
1326 name of the draft file. This could be an issue for MH frontends like mh-e.
1327 But as they likely want to provide working on multiple drafts in parallel,
1328 the issue is only concerning compatibility. The aim of nmh to stay compatible
1329 prevented the default activation of the draft folder facility.
1330 .P
1331 On the other hand, a draft folder is the much more natural concept than
1332 a draft message. MH's mail storage consists of folders and messages,
1333 the messages named with ascending numbers. A draft message breaks with this
1334 concept by introducing a message in a file named
1335 .Fn draft .
1336 This draft
1337 message is special. It can not be simply listed with the available tools,
1338 but instead requires special switches. I.e. corner-cases were
1339 introduced. A draft folder, in contrast, does not introduce such
1340 corner-cases. The available tools can operate on the messages within that
1341 folder like on any messages within any mail folders. The only difference
1342 is the fact that the default folder for
1343 .Pn send
1344 is the draft folder,
1345 instead of the current folder, like for all other tools.
1346 .P
1347 The trivial part of the change was activating the draft folder facility
1348 by default and setting a default name for this folder. Obviously, I chose
1349 the name
1350 .Fn +drafts .
1351 This made the
1352 .Sw -draftfolder
1353 and
1354 .Sw -draftmessage
1355 switches useless, and I could remove them.
1356 The more difficult but also the part that showed the real improvement,
1357 was updating the tools to the new concept.
1358 .Sw -draft
1359 switches could
1360 be dropped, as operating on a draft message became indistinguishable to
1361 operating on any other message for the tools.
1362 .Pn comp
1363 still has its
1364 .Sw -use
1365 switch for switching between its two modes: (1) Compose a new
1366 draft, possibly by taking some existing message as a form. (2) Modify
1367 an existing draft. In either case, the behavior of
1368 .Pn comp is
1369 deterministic. There is no more need to query the user. I consider this
1370 a major improvement. By making
1371 .Pn send
1372 simply operate on the current
1373 message in the draft folder by default, with message and folder both
1374 overridable by specifying them on the command line, it is now possible
1375 to send a draft anywhere within the storage by simply specifying its folder
1376 and name.
1377 .P
1378 All theses changes converted special cases to regular cases, thus
1379 simplifying the tools and increasing the flexibility.
1382 .H2 "Trash Folder
1383 .P
1384 Similar to the situation for drafts is the situation for removed messages.
1385 Historically, a message was deleted by renaming. A specific
1386 \fIbackup prefix\fP, often comma (\c
1387 .Fn , )
1388 or hash (\c
1389 .Fn # ),
1390 being prepended to the file name. Thus, MH wouldn't recognize the file
1391 as a message anymore, as only files whose name consists of digits only
1392 are treated as messages. The removed messages remained as files in the
1393 same directory and needed some maintenance job to truly delete them after
1394 some grace time. Usually, by running a command similar to
1395 .VS
1396 find /home/user/Mail -ctime +7 -name ',*' | xargs rm
1397 VE
1398 in a cron job. Within the grace time interval
1399 the original message could be restored by stripping the
1400 the backup prefix from the file name. If however, the last message of
1401 a folder is been removed \(en say message
1402 .Fn 6
1403 becomes file
1404 .Fn ,6
1405 \(en and a new message enters the same folder, thus the same
1406 numbered being given again \(en in our case
1407 .Fn 6
1408 \(en, if that one
1409 is removed too, then the backup of the former message gets overwritten.
1410 Thus, the ability to restore removed messages does not only depend on
1411 the ``sweeping cron job'' but also on the removing of further messages.
1412 This is undesirable, because the real mechanism is hidden from the user
1413 and the consequences of further removals are not always obvious.
1414 Further more, the backup files are scattered within the whole mail
1415 storage, instead of being collected at one place.
1416 .P
1417 To improve the situation, the profile entry
1418 .Pe rmmproc
1419 (previously named
1420 .Pe Delete-Prog )
1421 was introduced, very early.
1422 It could be set to any command, which would care for the mail removal
1423 instead of taking the default action, described above.
1424 Refiling the to-be-removed files to some garbage folder was a common
1425 example. Nmh's man page
1426 .Mp rmm(1)
1427 proposes
1428 .Cl "refile +d
1429 to move messages to the garbage folder and
1430 .Cl "rm `mhpath +d all`
1431 the empty the garbage folder.
1432 Managing the message removal this way is a sane approach. It keeps
1433 the removed messages in one place, makes it easy to remove the backup
1434 files, and, most important, enables the user to use the tools of MH
1435 itself to operate on the removed messages. One can
1436 .Pn scan
1437 them,
1438 .Pn show
1439 them, and restore them with
1440 .Pn refile .
1441 There's no more
1442 need to use
1443 .Pn mhpath
1444 to switch over from MH tools to Unix tools \(en MH can do it all itself.
1445 .P
1446 This approach matches perfect with the concepts of MH, thus making
1447 it powerful. Hence, I made it the default. And even more, I also
1448 removed the old backup prefix approach, as it is clearly less powerful.
1449 Keeping unused alternative in the code is a bad choice as they likely
1450 gather bugs, by not being constantly tested. Also, the increased code
1451 size and more conditions crease the maintenance costs. By strictly
1452 converting to the trash folder approach, I simplified the code base.
1453 .Pn rmm
1454 calls
1455 .Pn refile
1456 internally to move the to-be-removed
1457 message to the trash folder (\c
1458 .Fn +trash
1459 by default). Messages
1460 there can be operated on like on any other message in the storage.
1461 The sweep clean, one can use
1462 .Cl "rmm -unlink +trash a" ,
1463 where the
1464 .Sw -unlink
1465 switch causes the files to be truly unliked instead
1466 of moved to the trash folder.
1469 .H2 "Path Notations
1470 .P
1471 foo
1474 .H2 "MIME Integration
1475 .P
1476 user-visible access to whole messages and MIME parts are inherently
1477 different
1480 .H2 "Of One Cast
1481 .P