docs/master
view ch03.roff @ 98:d894191d7a33
style: Changed the block quote approach. New QS and QE.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sat, 16 Jun 2012 17:43:11 +0200 |
| parents | 29a7454fcded |
| children | 6ae7dc4a3a02 |
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 specialized 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 homogeneous 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 email in the last years
71 demanded changes in this part of nmh too.
72 Encryption and authentication 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 significantly
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 use case 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 formatted.
422 With MIME, this approach wasn't sufficient anymore.
423 MIME messages can consist of multiple parts, some of which aren't
424 directly displayable, further more text content might be encoded in
425 foreign charsets.
426 .Pn show 's
427 understanding of messages and
428 .Pn mhl 's
429 display capabilities couldn't cope with the task any longer.
430 .P
431 Instead of extending these tools, additional tools were written from
432 scratch and added to the MH tool chest.
433 Doing so is encouraged by the tool chest approach.
434 Modular design is a great advantage for extending a system,
435 as new tools can be added without interfering with existing ones.
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 tools, which together covered the
445 multiple aspects of MIME.
446 One of them was
447 .Pn mhshow ,
448 which replaced
449 .Cl "mhn -show" .
450 It was capable of displaying MIME messages appropriately.
451 .P
452 From then on, two message display tools were part of nmh,
453 .Pn show
454 and
455 .Pn mhshow .
456 To ease the life of users,
457 .Pn show
458 was extended to automatically hand the job over to
459 .Pn mhshow
460 if displaying the message would be beyond
461 .Pn show 's
462 abilities.
463 In consequence, the user would simply invoke
464 .Pn show
465 (possibly through
466 .Pn next
467 or
468 .Pn prev )
469 and get the message printed with either
470 .Pn show
471 or
472 .Pn mhshow ,
473 whatever was more appropriate.
474 .P
475 Having two similar tools for essentially the same task is redundant.
476 Usually,
477 users wouldn't distinguish between
478 .Pn show
479 and
480 .Pn mhshow
481 in their daily mail reading.
482 Having two separate display programs was therefore mainly unnecessary
483 from a user's point of view.
484 Besides, 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, although it's the other way round.
491 As
492 .Pn mhshow
493 had already be able to display non-MIME messages, it appeared natural
494 to drop
495 .Pn show
496 in favor of using
497 .Pn mhshow
498 exclusively.
499 .Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
500 Removing
501 .Pn show
502 is no loss in function, because functionally
503 .Pn mhshow
504 covers it completely.
505 The old behavior of
506 .Pn show
507 can still be emulated with the simple command line:
508 .VS
509 mhl `mhpath c`
510 VE
511 .P
512 For convenience,
513 .Pn mhshow
514 was renamed to
515 .Pn show
516 after
517 .Pn show
518 was gone.
519 It is clear that such a rename may confuse future developers when
520 trying to understand the history.
521 Nevertheless, I consider the convenience on the user's side,
522 to call
523 .Pn show
524 when they want a message to be displayed, to outweigh the inconvenience
525 on the developer's side when understanding the project history.
526 .P
527 To prepare for the transition,
528 .Pn mhshow
529 was reworked to behave more like
530 .Pn show
531 first.
532 (cf. Sec. XXX)
533 Once the tools behaved more alike, the replacing appeared to be
534 even more natural.
535 Today, mmh's new
536 .Pn show
537 became the one single message display program again, with the difference
538 that today it handles MIME messages as well as non-MIME messages.
539 The outcome of the transition is one program less to maintain,
540 no second display program for users to deal with,
541 and less system complexity.
542 .P
543 Still, removing the old
544 .Pn show
545 hurts in one regard: It had been such a simple program.
546 Its lean elegance is missing to the new
547 .Pn show .
548 But there is no chance;
549 supporting MIME demands for higher essential complexity.
552 .H2 "Removal of Configure Options
553 .P
554 Customization is a double-edged sword.
555 It allows better suiting setups, but not for free.
556 There is the cost of code complexity to be able to customize.
557 There is the cost of less tested setups, because there are
558 more possible setups and especially corner-cases.
559 And, there is the cost of choice itself.
560 The code complexity directly affects the developers.
561 Less tested code affects both, users and developers.
562 The problem of choice affects the users, for once by having to
563 choose, but also by complexer interfaces that require more documentation.
564 Whenever options add little advantages, they should be considered for
565 removal.
566 I have reduced the number of project-specific configure options from
567 fifteen to three.
569 .U3 "Mail Transfer Facilities
570 .P
571 With the removal of the mail transfer facilities five configure
572 options vanished:
573 .P
574 The switches
575 .Sw --with-tls
576 and
577 .Sw --with-cyrus-sasl
578 had activated the support for transfer encryption and authentication.
579 This is not needed anymore.
580 .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
581 .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
582 .P
583 The configure switch
584 .Sw --enable-pop
585 activated the message retrieval facility.
586 The code area that would be conditionally compiled in for TLS and SASL
587 support had been small.
588 The conditionally compiled code area for POP support had been much larger.
589 Whereas the code base changes would only slightly change on toggling
590 TLS or SASL support, it changed much on toggling POP support.
591 The changes in the code base could hardly be overviewed.
592 By having POP support togglable a second code base had been created,
593 one that needed to be tested.
594 This situation is basically similar for the conditional TLS and SASL
595 code, but there the changes are minor and can yet be overviewed.
596 Still, conditional compilation of a code base creates variations
597 of the original program.
598 More variations require more testing and maintenance work.
599 .P
600 Two other options only specified default configuration values:
601 .Sw --with-mts=[smtp|sendmail]
602 defined the default transport service.
603 In mmh this fixed to
604 .Ar sendmail .
605 .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
606 With
607 .Sw --with-smtpservers=[server1...]
608 default SMTP servers for the
609 .Ar smtp
610 transport service could be specified.
611 .Ci 128545e06224233b7e91fc4c83f8830252fe16c9
612 Both of them became irrelevant.
614 .U3 "Backup Prefix
615 .P
616 The backup prefix is the string that was prepended to message
617 filenames to tag them as deleted.
618 By default it had been the comma character `\f(CW,\fP'.
619 In July 2000, Kimmo Suominen introduced
620 the configure option
621 .Sw --with-hash-backup
622 to change the default to the hash symbol `\f(CW#\fP'.
623 The choice was probably personal preference, because first, the
624 option was named
625 .Sw --with-backup-prefix.
626 and had the prefix symbol as argument.
627 Because giving the hash symbol as argument caused to many problems
628 for configure,
629 the option was limited to use the hash symbol as the default prefix.
630 This makes me believe, that the choice for the hash was personal preference.
631 Being it related or not, words that start with the hash symbol
632 introduce a comment in the Unix shell.
633 Thus, the command line
634 .Cl "rm #13 #15
635 calls
636 .Pn rm
637 without arguments because the first hash symbol starts the comment
638 that reaches until the end of the line.
639 To delete the backup files,
640 .Cl "rm ./#13 ./#15"
641 needs to be used.
642 Using the hash as backup prefix can be seen as a precaution agains
643 data loss.
644 .P
645 I removed the configure option but added the profile entry
646 .Pe backup-prefix ,
647 which allows to specify an arbitrary string as backup prefix.
648 .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
649 Profile entries are the common method to change mmh's behavior.
650 This change did not remove the choice but moved it to a location where
651 it suited better.
652 .P
653 Eventually, however, the new trash folder concept
654 .Cf "Sec. XXX
655 obsoleted the concept of the backup prefix completely.
656 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
657 (Well, there still are corner-cases to remove until the backup
658 prefix can be laid to rest, eventually.)
659 .\" FIXME: Do this work in the code!
661 .U3 "Editor and Pager
662 .P
663 The two configure options
664 .CW --with-editor=EDITOR
665 .CW --with-pager=PAGER
666 were used to specify the default editor and pager at configure time.
667 Doing so at configure time made sense in the Eighties,
668 when the set of available editors and pagers varied much across
669 different systems.
670 Today, the situation is more homogeneous.
671 The programs
672 .Pn vi
673 and
674 .Pn more
675 can be expected to be available on every Unix system,
676 as they are specified by POSIX since two decades.
677 (The specifications for
678 .Pn vi
679 and
680 .Pn more
681 appeared in
682 .[
683 posix 1987
684 .]
685 and,
686 .[
687 posix 1992
688 .]
689 respectively.)
690 As a first step, these two tools were hard-coded as defaults.
691 .Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f
692 Not changed were the
693 .Pe editor
694 and
695 .Pe moreproc
696 profile entries, which allowed the user to override the system defaults.
697 Later, the concept was reworked to respect the standard environment
698 variables
699 .Ev VISUAL
700 and
701 .Ev PAGER
702 if they are set.
703 Today, mmh determines the editor to use in the following order,
704 taking the first available and non-empty item:
705 .IP (1)
706 Environment variable
707 .Ev MMHEDITOR
708 .IP (2)
709 Profile entry
710 .Pe Editor
711 .IP (3)
712 Environment variable
713 .Ev VISUAL
714 .IP (4)
715 Environment variable
716 .Ev EDITOR
717 .IP (5)
718 Command
719 .Pn vi .
720 .P
721 .Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
722 .P
723 The pager to use is determined in a similar order,
724 also taking the first available and non-empty item:
725 .IP (1)
726 Environment variable
727 .Ev MMHPAGER
728 .IP (2)
729 Profile entry
730 .Pe Pager
731 (replaces
732 .Pe moreproc )
733 .IP (3)
734 Environment variable
735 .Ev PAGER
736 .IP (4)
737 Command
738 .Pn more .
739 .P
740 .Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e
741 .P
742 By respecting the
743 .Ev VISUAL /\c
744 .Ev EDITOR
745 and
746 .Ev PAGER
747 environment variables,
748 the new behavior confirms better to the common style on Unix systems.
749 Additionally, the new approach is more uniform and clearer to users.
751 .U3 "Locale
752 .P
753 The configure option
754 .Sw --disable-locale
755 was removed because POSIX provides locale support and there's
756 hardly any need to disable locale support.
757 .Ci ccf4f175ef4c4e7522f9510a4a1149c15d810dd9
759 .U3 "ndbm
760 .P
761 .Pn slocal
762 used to depend on
763 .I ndbm ,
764 a database library.
765 The database is used to store the `\fLMessage-ID\fP's of all
766 messages delivered.
767 This enables
768 .Pn slocal
769 to suppress delivering the same message to the same user twice.
770 (This features was enabled by the
771 .Sw -suppressdup
772 switch.)
773 .P
774 A variety of version of the database library exist.
775 .[
776 wolter unix incompat notes dbm
777 .]
778 Complicated autoconf code was needed to detect them correctly.
779 Further more, the configure switches
780 .Sw --with-ndbm=ARG
781 and
782 .Sw --with-ndbmheader=ARG
783 were added to help with difficult setups that would
784 not be detected automatically or correctly.
785 .P
786 By removing the suppress duplicates feature of
787 .Pn slocal ,
788 the dependency on
789 .I ndbm
790 vanished and 120 lines of complex autoconf code could be saved.
791 .Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
792 The change removed functionality too, but that is minor to the
793 improvement by dropping the dependency and the complex autoconf code.
795 .U3 "mh-e Support
796 .P
797 The configure option
798 .Sw --disable-mhe
799 was removed when the mh-e support was reworked.
800 Mh-e is the Emacs front-end to MH.
801 It requires MH to provide minor additional functions.
802 The
803 .Sw --disable-mhe
804 configure option could switch these extensions off.
805 After removing the support for old versions of mh-e,
806 only the
807 .Sw -build
808 switches of
809 .Pn forw
810 and
811 .Pn repl
812 are left to be mh-e extensions.
813 They are now always built in because they add little code and complexity.
814 In consequence, the
815 .Sw --disable-mhe
816 configure option was removed
817 .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
818 Removing the option removed a second code setup that would have
819 needed to be tested.
820 This change was first done in nmh and thereafter merged into mmh.
821 .P
822 The interface changes in mmh require mh-e to be adjusted in order
823 to be able to use mmh as back-end.
824 This will require minor changes to mh-e, but removing the
825 .Sw -build
826 switches would require more rework.
828 .U3 "Masquerading
829 .P
830 The configure option
831 .Sw --enable-masquerade
832 could take up to three arguments:
833 `draft_from', `mmailid', and `username_extension'.
834 They activated different types of address masquerading.
835 All of them were implemented in the SMTP-speaking
836 .Pn post
837 command, which provided an MSA.
838 Address masquerading is an MTA's task and mmh does not cover
839 this field anymore.
840 Hence, true masquerading needs to be implemented in the external MTA.
841 .P
842 The
843 .I mmailid
844 masquerading type is the oldest one of the three and the only one
845 available in the original MH.
846 It provided a
847 .I username
848 to
849 .I fakeusername
850 mapping, based on the password file's GECOS field.
851 The man page
852 .Mp mh-tailor(5)
853 described the use case as being the following:
854 .QS
855 This is useful if you want the messages you send to always
856 appear to come from the name of an MTA alias rather than your
857 actual account name. For instance, many organizations set up
858 `First.Last' sendmail aliases for all users. If this is
859 the case, the GECOS field for each user should look like:
860 ``First [Middle] Last <First.Last>''
861 .QE
862 .P
863 As mmh sends outgoing mail via the local MTA only,
864 the best location to do such global rewrites is there.
865 Besides, the MTA is conceptionally the right location because it
866 does the reverse mapping for incoming mail (aliasing), too.
867 Further more, masquerading set up there is readily available for all
868 mail software on the system.
869 Hence, mmailid masquerading was removed.
870 .Ci 0836c8000ccb34b59410ef1c15b1b7feac70ce5f
871 .P
872 The
873 .I username_extension
874 masquerading type did not replace the username but would append a suffix,
875 specified by the
876 .Ev USERNAME_EXTENSION
877 environment variable, to it.
878 This provided support for the
879 .I user-extension
880 feature of qmail and the similar
881 .I "plussed user
882 processing of sendmail.
883 The decision to remove this username_extension masquerading was
884 motivated by the fact that
885 .Pn spost
886 hadn't supported it already.
887 .Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
888 Username extensions are possible in mmh, but less convenient to use.
889 .\" XXX format file %(getenv USERNAME_EXTENSION)
890 .P
891 The
892 .I draft_from
893 masquerading type instructed
894 .Pn post
895 to use the value of the
896 .Hd From
897 header field as SMTP envelope sender.
898 Sender addresses could be replaced completely.
899 .Ci b14ea6073f77b4359aaf3fddd0e105989db9
900 Mmh offers a kind of masquerading similar in effect, but
901 with technical differences.
902 As mmh does not transfer messages itself, the local MTA has final control
903 over the sender's address. Any masquerading mmh introduces may be reverted
904 by the MTA.
905 In times of pedantic spam checking, an MTA will take care to use
906 sensible envelope sender addresses to keep its own reputation up.
907 Nonetheless, the MUA can set the
908 .Hd From
909 header field and thereby propose
910 a sender address to the MTA.
911 The MTA may then decide to take that one or generate the canonical sender
912 address for use as envelope sender address.
913 .P
914 In mmh, the MTA will always extract the recipient and sender from the
915 message header (\c
916 .Pn sendmail 's
917 .Sw -t
918 switch).
919 The
920 .Hd From
921 header field of the draft may be set arbitrary by the user.
922 If it is missing, the canonical sender address will be generated by the MTA.
924 .U3 "Remaining Options
925 .P
926 Two configure options remain in mmh.
927 One is the locking method to use:
928 .Sw --with-locking=[dot|fcntl|flock|lockf] .
929 The idea of removing all methods except the portable dot locking
930 and having that one as the default is appealing, but this change
931 requires deeper technical investigation into the topic.
932 The other option,
933 .Sw --enable-debug ,
934 compiles the programs with debugging symbols and does not strip them.
935 This option is likely to stay.
940 .H2 "Removal of Switches
941 .P
942 The command line switches of MH tools follow the X Window style.
943 They are words, introduced by a single dash.
944 For example:
945 .Cl "-truncate" .
946 Every program in mmh has two generic switches:
947 .Sw -help ,
948 to print a short message on how to use the program, and
949 .Sw -Version ,
950 to tell what version of mmh the program belongs to.
951 .P
952 Switches change the behavior of programs.
953 Programs that do one thing in one way require no switches.
954 In most cases, doing something in exactly one way is too limiting.
955 If there is basically one task to accomplish, but it should be done
956 in various ways, switches are a good approach to alter the behavior
957 of a program.
958 Changing the behavior of programs provides flexibility and customization
959 to users, but at the same time it complicates the code, documentation and
960 usage of the program.
961 .\" XXX: Ref
962 Therefore, the number of switches should be kept small.
963 A small set of well-chosen switches does no harm.
964 But usually, the number of switches increases over time.
965 Already in 1985, Rose and Romine have identified this as a major
966 problem of MH:
967 .[ [
968 rose romine real work
969 .], p. 12]
970 .QS
971 A complaint often heard about systems which undergo substantial development
972 by many people over a number of years, is that more and more options are
973 introduced which add little to the functionality but greatly increase the
974 amount of information a user needs to know in order to get useful work done.
975 This is usually referred to as creeping featurism.
976 .QP
977 Unfortunately MH, having undergone six years of off-and-on development by
978 ten or so well-meaning programmers (the present authors included),
979 suffers mightily from this.
980 .QE
981 .P
982 Being reluctant to adding new switches \(en or `options',
983 as Rose and Romine call them \(en is one part of a counter-action,
984 the other part is removing hardly used switches.
985 Nmh's tools had lots of switches already implemented,
986 hence, cleaning up by removing some of them was the more important part
987 of the counter-action.
988 Removing existing functionality is always difficult because it
989 breaks programs that use these functions.
990 Also, for every obsolete feature, there'll always be someone who still
991 uses it and thus opposes its removal.
992 This puts the developer into the position,
993 where sensible improvements to style are regarded as destructive acts.
994 Yet, living with the featurism is far worse, in my eyes, because
995 future needs will demand adding further features,
996 worsening the situation more and more.
997 Rose and Romine added in a footnote,
998 ``[...]
999 .Pn send
1000 will no doubt acquire an endless number of switches in the years to come.''
1001 Although clearly humorous, the comment points to the nature of the problem.
1002 Refusing to add any new switches would encounter the problem at its root,
1003 but this is not practical.
1004 New needs will require new switches and it would be unwise to block
1005 them strictly.
1006 Nevertheless, removing obsolete switches still is an effective approach
1007 to deal with the problem.
1008 Working on an experimental branch without an established user base,
1009 eased my work because I did not offend users when I removed existing
1010 funtions.
1011 .P
1012 Rose and Romine counted 24 visible and 9 more hidden switches for
1013 .Pn send .
1014 In nmh, they increased up to 32 visible and 12 hidden ones.
1015 At the time of writing, no more than 7 visible switches and 1 hidden switch
1016 have remained in mmh's
1017 .Pn send .
1018 (These numbers include two generic switches, help and version.)
1019 .P
1020 Fig. XXX
1021 .\" XXX Ref
1022 displays the number of switches for each of the tools that is available
1023 in both, nmh and mmh.
1024 Visible as well as hidden switches were counted,
1025 but not the generic help and version switches.
1026 Whereas in the beginning of the project, the average tool had 11 switches,
1027 now it has no more than 5 \(en only half as many.
1028 If the `no' switches and similar inverse variant are folded onto
1029 their counter-parts, the average tool has 8 switches in pre-mmh to 4 now.
1030 The total number of functional switches in mmh dropped from 465
1031 to 234.
1033 .KS
1034 .in 1c
1035 .so input/switches.grap
1036 .KE
1038 .P
1039 A part of the switches vanished after functions were removed.
1040 This was the case for network mail transfer, for instance.
1041 Sometimes, however, the work flow was the other way:
1042 I looked through the
1043 .Mp mh-chart (7)
1044 man page to identify the tools with apparently too many switches.
1045 Then considering the value of each of the switches by examining
1046 the tool's man page and source code, aided by recherche and testing.
1047 This way, the removal of functions was suggested by the aim to reduce
1048 the number of switches per command.
1051 .U3 "Draft Folder Facility
1052 .P
1053 A change early in the project was the completely transition from
1054 the single draft message to the draft folder facility.
1055 .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
1056 The draft folder facility was introduced in the mid-Eighties.
1057 (Rose and Romine called it a ``relatively new feature''
1058 .[
1059 rose romine real work
1060 .]
1061 in 1985.)
1062 Since then, the facility had existed but was deactivated by default.
1063 The default activation and the related rework of the tools made it
1064 possible to remove the
1065 .Sw -[no]draftfolder ,
1066 and
1067 .Sw -draftmessage
1068 switches from
1069 .Pn comp ,
1070 .Pn repl ,
1071 .Pn forw ,
1072 .Pn dist ,
1073 .Pn whatnow ,
1074 and
1075 .Pn send .
1076 .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
1077 The only flexibility removed with this change is having multiple
1078 draft folders within one profile.
1079 I consider this a theoretical problem only.
1080 In the same go, the
1081 .Sw -draft
1082 switch of
1083 .Pn anno ,
1084 .Pn refile ,
1085 and
1086 .Pn send
1087 was removed.
1088 The special-casing of `the' draft message became irrelevant after
1089 the rework of the draft system.
1090 (See Sec. XXX.)
1091 Equally,
1092 .Pn comp
1093 lost its
1094 .Sw -file
1095 switch.
1096 The draft folder facility, together with the
1097 .Sw -form
1098 switch, are sufficient.
1101 .U3 "Inplace Editing
1102 .P
1103 .Pn anno
1104 had the switches
1105 .Sw -[no]inplace
1106 to either annotate the message inplace and thus preserve hard links,
1107 or annotate a copy to replace the original message, breaking hard links.
1108 Following the assumption that linked messages should truly be the
1109 same message, and annotating it should not break the link, the
1110 .Sw -[no]inplace
1111 switches were removed and the previous default
1112 .Sw -inplace
1113 was made the only behavior.
1114 .Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0
1115 The
1116 .Sw -[no]inplace
1117 switches of
1118 .Pn repl ,
1119 .Pn forw ,
1120 and
1121 .Pn dist
1122 could be removed, too, as they were simply passed through to
1123 .Pn anno .
1124 .P
1125 .Pn burst
1126 also had
1127 .Sw -[no]inplace
1128 switches, but with different meaning.
1129 With
1130 .Sw -inplace ,
1131 the digest had been replaced by the table of contents (i.e. the
1132 introduction text) and the bursted messages were placed right
1133 after this message, renumbering all following messages.
1134 Also, any trailing text of the digest was lost, though,
1135 in practice, it usually consists of an end-of-digest marker only.
1136 Nontheless, this behavior appeared less elegant than the
1137 .Sw -noinplace
1138 behavior, which already had been the default.
1139 Nmh's
1140 .Mp burst (1)
1141 man page reads:
1142 .sp \n(PDu
1143 .QS
1144 If -noinplace is given, each digest is preserved, no table
1145 of contents is produced, and the messages contained within
1146 the digest are placed at the end of the folder. Other messages
1147 are not tampered with in any way.
1148 .QE
1149 .LP
1150 The decision to drop the
1151 .Sw -inplace
1152 behavior was supported by the code complexity and the possible data loss
1153 it caused.
1154 .Sw -noinplace
1155 was chosen to be the definitive behavior.
1156 .Ci 68a686adeb39223a5e1ad35e4a24890ec053679d
1159 .U3 "Forms and Format Strings
1160 .P
1161 Historically, the tools that had
1162 .Sw -form
1163 switches to supply a form file had
1164 .Sw -format
1165 switches as well to supply the contents of a form file as a string
1166 on the command line directly.
1167 In consequence, the following two lines equaled:
1168 .VS
1169 scan -form scan.mailx
1170 scan -format "`cat .../scan.mailx`"
1171 VE
1172 The
1173 .Sw -format
1174 switches were dropped in favor for extending the
1175 .Sw -form
1176 switches.
1177 .Ci f51956be123db66b00138f80464d06f030dbb88d
1178 If their argument starts with an equal sign (`='),
1179 then the rest of the argument is taken as a format string,
1180 otherwise the arguments is treated as the name of a format file.
1181 Thus, now the following two lines equal:
1182 .VS
1183 scan -form scan.mailx
1184 scan -form "=`cat .../scan.mailx`"
1185 VE
1186 This rework removed the prefix collision between
1187 .Sw -form
1188 and
1189 .Sw -format .
1190 Now, typing
1191 .Sw -fo
1192 suffices to specify form or format string.
1193 .P
1194 The different meaning of
1195 .Sw -format
1196 for
1197 .Pn repl
1198 and
1199 .Pn forw
1200 was removed in mmh.
1201 .Pn forw
1202 was completely switched to MIME-type forwarding, thus removing the
1203 .Sw -[no]format .
1204 .Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
1205 For
1206 .Pn repl ,
1207 the
1208 .Sw -[no]format
1209 switches were reworked to
1210 .Sw -[no]filter
1211 switches.
1212 .Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
1213 The
1214 .Sw -format
1215 switches of
1216 .Pn send
1217 and
1218 .Pn post ,
1219 which had a third meaning,
1220 were removed likewise.
1221 .Ci f3cb7cde0e6f10451b6848678d95860d512224b9
1222 Eventually, the ambiguity of the
1223 .Sw -format
1224 switches was resolved by not anymore having any such switch in mmh.
1227 .U3 "MIME Tools
1228 .P
1229 The MIME tools, which were once part of
1230 .Pn mhn ,
1231 had several switches that added little practical value to the programs.
1232 The
1233 .Sw -[no]realsize
1234 switches of
1235 .Pn mhbuild
1236 and
1237 .Pn mhlist
1238 were removed, doing real size calculations always now
1239 .Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c ,
1240 as
1241 ``This provides an accurate count at the expense of a small delay.''
1242 This small delay is not noticable on modern systems.
1243 .P
1244 The
1245 .Sw -[no]check
1246 switches were removed together with the support for
1247 .Hd Content-MD5
1248 header fields.
1249 .[
1250 rfc 1864
1251 .]
1252 .Ci 31dc797eb5178970d68962ca8939da3fd9a8efda
1253 (See Sec. XXX)
1254 .P
1255 The
1256 .Sw -[no]ebcdicsafe
1257 and
1258 .Sw -[no]rfc934mode
1259 switches of
1260 .Pn mhbuild
1261 were removed because they are considered obsolete.
1262 .Ci 01a3480928da485b4d6109d36d751dfa71799d58
1263 .Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88
1264 .P
1265 Content caching of external MIME parts, activated with the
1266 .Sw -rcache
1267 and
1268 .Sw -wcache
1269 switches was completely removed.
1270 .Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269
1271 External MIME parts are rare today, having a caching facility
1272 for them is appears to be unnecessary.
1273 .P
1274 In pre-MIME times,
1275 .Pn mhl
1276 had covered many tasks that are part of MIME handling today.
1277 Therefore,
1278 .Pn mhl
1279 could be simplified to a large extend, reducing the number of its
1280 switches from 21 to 6.
1281 .Ci 350ad6d3542a07639213cf2a4fe524e829c1e7b6
1282 .Ci 0e46503be3c855bddaeae3843e1b659279c35d70
1285 .U3 "Mail Transfer Switches
1286 .P
1287 With the removal of the mail transfer facilities, a lot of switches
1288 vanished automatically.
1289 .Pn inc
1290 lost 9 switches, namely
1291 .Sw -host ,
1292 .Sw -port ,
1293 .Sw -user ,
1294 .Sw -proxy ,
1295 .Sw -snoop ,
1296 .Sw -[no]pack ,
1297 as well as
1298 .Sw -sasl
1299 and
1300 .Sw -saslmech .
1301 .Pn send
1302 and
1303 .Pn post
1304 lost 11 switches each, namely
1305 .Sw -server ,
1306 .Sw -port ,
1307 .Sw -client ,
1308 .Sw -user ,
1309 .Sw -mail ,
1310 .Sw -saml ,
1311 .Sw -send ,
1312 .Sw -soml ,
1313 .Sw -snoop ,
1314 as well as
1315 .Sw -sasl ,
1316 .Sw -saslmech ,
1317 and
1318 .Sw -tls .
1319 .Pn send
1320 had the switches only to pass them further to
1321 .Pn post ,
1322 because the user would invoke
1323 .Pn post
1324 not directly, but through
1325 .Pn send .
1326 All these switches, except
1327 .Sw -snoop
1328 were usually defined as default switches in the user's profile,
1329 but hardly given in interactive usage.
1330 .P
1331 Of course, those switches did not really ``vanish'', but the configuration
1332 they did was handed over to external MSAs and MRAs.
1333 Instead of setting up the mail transfer in mmh, it is set up in
1334 external tools.
1335 Yet, this simplifies mmh.
1336 Specialized external tools will likely have simple configuration files.
1337 Hence, instead of having one complicated central configuration file,
1338 the configuration of each domain is separate.
1339 Although the user needs to learn to configure each of the tools,
1340 each configuration is likely much simpler.
1343 .U3 "Maildrop Formats
1344 .P
1345 With the removal of MMDF maildrop format support,
1346 .Pn packf
1347 and
1348 .Pn rcvpack
1349 no longer needed their
1350 .Sw -mbox
1351 and
1352 .Sw -mmdf
1353 switches.
1354 .Sw -mbox
1355 is the sole behavior now.
1356 .Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
1357 In the same go,
1358 .Pn packf
1359 and
1360 .Pn rcvpack
1361 were reworked (see Sec. XXX) and their
1362 .Sw -file
1363 switch became unnecessary.
1364 .Ci ca1023716d4c2ab890696f3e41fa0d94267a940e
1367 .U3 "Terminal Magic
1368 .P
1369 Mmh's tools will no longer clear the screen (\c
1370 .Pn scan 's
1371 and
1372 .Pn mhl 's
1373 .Sw -[no]clear
1374 switches
1375 .Ci e57b17343dcb3ff373ef4dd089fbe778f0c7c270
1376 .Ci 943765e7ac5693ae177fd8d2b5a2440e53ce816e ).
1377 Neither will
1378 .Pn mhl
1379 ring the bell (\c
1380 .Sw -[no]bell
1381 .Ci e11983f44e59d8de236affa5b0d0d3067c192e24 )
1382 nor page the output itself (\c
1383 .Sw -length
1384 .Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ).
1385 .P
1386 Generally, the pager to use is no longer specified with the
1387 .Sw -[no]moreproc
1388 command line switches for
1389 .Pn mhl
1390 and
1391 .Pn show /\c
1392 .Pn mhshow .
1393 .Ci 39e87a75b5c2d3572ec72e717720b44af291e88a
1394 .P
1395 .Pn prompter
1396 lost its
1397 .Sw -erase
1398 and
1399 .Sw -kill
1400 switches because today the terminal cares for the line editing keys.
1403 .U3 "Header Printing
1404 .P
1405 .Pn folder 's
1406 data output is self-explaining enough that
1407 displaying the header line makes few sense.
1408 Hence, the
1409 .Sw -[no]header
1410 switch was removed and headers are never printed.
1411 .Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7
1412 .P
1413 In
1414 .Pn mhlist ,
1415 the
1416 .Sw -[no]header
1417 switches were removed, too.
1418 .Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f
1419 But in this case headers are always printed,
1420 because the output is not self-explaining.
1421 .P
1422 .Pn scan
1423 also had
1424 .Sw -[no]header
1425 switches.
1426 Printing the header had been sensible until the introduction of
1427 format strings made it impossible to display the column headings.
1428 Only the folder name and the current date remained to be printed.
1429 As this information can be perfectly retrieved by
1430 .Pn folder
1431 and
1432 .Pn date ,
1433 consequently, the switches were removed.
1434 .Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e
1435 .P
1436 By removing all
1437 .Sw -header
1438 switches, the collision with
1439 .Sw -help
1440 on the first two letters was resolved.
1441 Currently,
1442 .Sw -h
1443 evaluates to
1444 .Sw -help
1445 for all tools of mmh.
1448 .U3 "Suppressing Edits or the WhatNow Shell
1449 .P
1450 The
1451 .Sw -noedit
1452 switches of
1453 .Pn comp ,
1454 .Pn repl ,
1455 .Pn forw ,
1456 .Pn dist ,
1457 and
1458 .Pn whatnow
1459 was removed, but it can now be replaced by specifying
1460 .Sw -editor
1461 with an empty argument.
1462 .Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9
1463 (Specifying
1464 .Cl "-editor true
1465 is nearly the same, only differing by the previous editor being set.)
1466 .P
1467 The more important change is the removal of the
1468 .Sw -nowhatnowproc
1469 switch.
1470 .Ci ee4f43cf2ef0084ec698e4e87159a94c01940622
1471 This switch had introduced an awkward behavior, as explained in nmh's
1472 man page for
1473 .Mp comp (1):
1474 .QS
1475 The \-editor editor switch indicates the editor to use for
1476 the initial edit. Upon exiting from the editor, comp will
1477 invoke the whatnow program. See whatnow(1) for a discussion
1478 of available options. The invocation of this program can be
1479 inhibited by using the \-nowhatnowproc switch. (In truth of
1480 fact, it is the whatnow program which starts the initial
1481 edit. Hence, \-nowhatnowproc will prevent any edit from
1482 occurring.)
1483 .QE
1484 .P
1485 Effectively, the
1486 .Sw -nowhatnowproc
1487 switch stored a copy of the form file into the draft folder.
1488 As
1489 .Cl "-whatnowproc true
1490 causes the same behavior, the
1491 .Sw -nowhatnowproc
1492 switch was removed for being redundant.
1493 Likely, however, the intention for specifying
1494 .Sw -nowhatnowproc
1495 is sending a fully prepared form file at once.
1496 This can be done with
1497 .Cl "-whatnowproc send" .
1500 .U3 "Compatibility Switches
1501 .BU
1502 The hidden
1503 .Sw -[no]total
1504 switches of
1505 .Pn flist .
1506 They were simply the inverse of the visible
1507 .Sw -[no]fast
1508 switches:
1509 .Sw -total
1510 was
1511 .Sw -nofast
1512 and
1513 .Sw -nototal
1514 was
1515 .Sw -fast .
1516 I removed the
1517 .Sw -[no]total
1518 legacy.
1519 .Ci ea21fe2c4bd23c639bef251398fae809875732ec
1520 .BU
1521 The
1522 .Sw -subject
1523 switch of
1524 .Pn sortm
1525 existed for compatibility only.
1526 It can be fully replaced by
1527 .Cl "-textfield subject
1528 thus it was removed.
1529 .Ci 00140a3c86e9def69d98ba2ffd4d6e50ef6326ea
1532 .U3 "Various
1533 .BU
1534 In order to avoid prefix collisions among switch names, the
1535 .Sw -version
1536 switch was renamed to
1537 .Sw -Version
1538 (with capital `V').
1539 .Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a
1540 Every program has the
1541 .Sw -version
1542 switch but its first three letters collided with the
1543 .Sw -verbose
1544 switch, present in many programs.
1545 The rename solved this problem once for all.
1546 Although this rename breaks a basic interface, having the
1547 .Sw -V
1548 abbreviation to display the version information, isn't all too bad.
1549 .BU
1550 .Sw -[no]preserve
1551 of
1552 .Pn refile
1553 was removed because what use was it anyway?
1554 .QS
1555 Normally when a message is refiled, for each destination
1556 folder it is assigned the number which is one above the current
1557 highest message number in that folder. Use of the
1558 \-preserv [sic!] switch will override this message renaming, and try
1559 to preserve the number of the message. If a conflict for a
1560 particular folder occurs when using the \-preserve switch,
1561 then refile will use the next available message number which
1562 is above the message number you wish to preserve.
1563 .QE
1564 .BU
1565 The removal of the
1566 .Sw -[no]reverse
1567 switches of
1568 .Pn scan
1569 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
1570 is a bug fix, supported by the comments
1571 ``\-[no]reverse under #ifdef BERK (I really HATE this)''
1572 by Rose and
1573 ``Lists messages in reverse order with the `\-reverse' switch.
1574 This should be considered a bug.'' by Romine in the documentation.
1575 The question remains why neither Rose and Romine had fixed this
1576 bug in the Eighties when they wrote these comments nor has anyone
1577 thereafter.
1580 .ig
1582 forw: [no]dashstuffing(mhl)
1584 mhshow: [no]pause [no]serialonly
1586 mhmail: resent queued
1587 inc: snoop, (pop)
1589 mhl: [no]faceproc folder sleep
1590 [no]dashstuffing(forw) digest list volume number issue number
1592 prompter: [no]doteof
1594 refile: [no]preserve [no]unlink [no]rmmproc
1596 send: [no]forward [no]mime [no]msgid
1597 [no]push split [no]unique (sasl) width snoop [no]dashstuffing
1598 attach attachformat
1599 whatnow: (noedit) attach
1601 slocal: [no]suppressdups
1603 spost: [no]filter [no]backup width [no]push idanno
1604 [no]check(whom) whom(whom)
1606 whom: ???
1608 ..
1611 .ig
1613 .P
1614 To ease typing, the switches can be abbreviated as much as the remaining
1615 prefix remains unambiguous.
1616 If in our example no other switch would start with the letter `t', then
1617 .Cl "-truncate" ,
1618 .Cl "-trunc" ,
1619 .Cl "-tr" ,
1620 and
1621 .Cl "-t
1622 would all be the same.
1623 As a result, switches can neither be grouped (as in
1624 .Cl "ls -ltr" )
1625 nor can switch arguments be appended directly to the switch (as in
1626 .Cl "sendmail -q30m" ).
1627 .P
1628 Many switches have negating counter-parts, which start with `no'.
1629 For example
1630 .Cl "-notruncate
1631 inverts the
1632 .Cl "-truncate
1633 switch.
1634 They exist to undo the effect of default switches in the profile.
1635 If the user has chosen to change the default behavior of some tool
1636 by adding a default switch to the profile,
1637 he can still undo this change in behavior by specifying the inverse
1638 switch on the command line.
1639 .P
1640 In the best case, all switches are unambiguous on the first character,
1641 or on the three-letter prefix for the `no' variants.
1642 Reducing switch prefix collisions, shortens the necessary prefix length
1643 the user must type.
1644 Having less switches helps best.
1646 ..
1651 .H1 "Modernizing
1654 .H2 "Removal of Code Relicts
1655 .P
1656 The code base of mmh originates from the late Seventies,
1657 had been extensively
1658 worked on in the mid Eighties, and had been partly reorganized and extended
1659 in the Nineties. Relicts of all those times had gathered in the code base.
1660 My goal was to remove any ancient code parts. One part of the task was
1661 converting obsolete code constructs to standard constructs, the other part
1662 was dropping obsolete functions.
1663 .P
1664 As I'm not even thirty years old and have no more than seven years of
1665 Unix experience, I needed to learn about the history in retrospective.
1666 Older people likely have used those ancient constructs themselves
1667 and have suffered from their incompatibilities and have longed for
1668 standardization. Unfortunately, I have only read that others had done so.
1669 This put me in a much more difficult positions when working on the old
1670 code. I needed to recherche what other would have known by heart from
1671 experience. All my programming experience comes from a time past ANSI C
1672 and past POSIX. Although I knew about the times before, I took the
1673 current state implicitly for granted most of the time.
1674 .P
1675 Being aware of
1676 these facts, I rather let people with more historic experience solve the
1677 task of converting the ancient code constructs to standardized ones.
1678 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
1679 He converted large parts of the code to POSIX constructs, removing
1680 the conditionals compilation for now standardized features.
1681 I'm thankful for this task being solved. I only pulled the changes into
1682 mmh.
1683 .P
1684 The other task \(en dropping ancient functionality to remove old code \(en
1685 I did myself, though. My position to strip mmh to the bare minimum of
1686 frequently used features is much more revolutional than the nmh community
1687 likes it. Without the need to justify my decisions, I was able to quickly
1688 remove functionality I considered ancient.
1689 The need to discuss my decisions with
1690 peers likely would have slowed this process down. Of course, I researched
1691 if a particular feature really should be dropped. Having not had any
1692 contact to this feature within my computer life was a first indicator to
1693 drop it, but I also asked others and searched the literature for modern
1694 usage of the feature. If it appeared to be truly ancient, I dropped it.
1695 The reason for dropping is always part of the commit message in the
1696 version control system. Thus, it is easy for others to check their
1697 view on the topic with mine and possibly to argue for reinclusion.
1699 .U2 "MMDF maildrop support
1700 .P
1701 I did drop any support for the MMDF maildrop format. This type of format
1702 is conceptionally similar to the mbox format, but uses four bytes with
1703 value 1 (\fL^A^A^A^A\fP) as message delimiter,
1704 instead of the string ``\fLFrom\ \fP''.
1705 Due to the similarity and mbox being the de-facto standard maildrop
1706 format on Unix, but also due to the larger influence of Sendmail than MMDF,
1707 the MMDF maildrop format had vanished.
1708 .P
1709 The simplifications within the code were only moderate. Switches could
1710 be removed from tools like
1711 .L packf ,
1712 which generate packed mailboxes. Only one packed mailbox format remained:
1713 mbox.
1714 The most important changes affect the equally named mail parsing routine in
1715 .L sbr/m_getfld.c .
1716 The direct MMDF code had been removed, but as now only one packed mailbox
1717 format is left, code structure simplifications are likely possible.
1718 The reason why they are still outstanding is the heavily optimized code
1719 of
1720 .Fu m_getfld() .
1721 Changes beyond a small local scope \(en
1722 which restructuring in its core is \(en cause a high risk of damaging
1723 the intricate workings of the optimized code. This problem is know
1724 to the developers of nmh, too. They also avoid touching this minefield
1725 if possible.
1727 .U2 "UUCP Bang Paths
1728 .P
1729 More questionably than the former topic is the removal of support for the
1730 UUCP bang path address style. However, the user may translate the bang
1731 paths on retrieval to Internet addresses and the other way on posting
1732 messages. The former can be done my an MDA like procmail; the latter
1733 by a sendmail wrapper. This would ensure that any address handling would
1734 work as expected. However, it might just work well without any
1735 such modifications, as mmh does not touch addresses much, in general.
1736 But I can't ensure as I have never used an environment with bang paths.
1737 Also, the behavior might break at any point in further development.
1739 .U2 "Hardcopy terminal support
1740 .P
1741 More of a funny anecdote is the remaining of a check for printing to a
1742 hardcopy terminal until Spring 2012, when I finally removed it.
1743 I surely would be very happy to see such a terminal in action, maybe
1744 actually being able to work on it, but I fear my chances are null.
1745 .P
1746 The check only prevented a pager to be placed between the outputting
1747 program (\c
1748 .Pn mhl )
1749 and the terminal. This could have been ensured with
1750 the
1751 .Sw -nomoreproc
1752 at the command line statically, too.
1754 .U2 "Removed support for header fields
1755 .P
1756 The
1757 .Hd Encrypted
1758 header field had been introduced by RFC\^822, but already
1759 marked legacy in RFC 2822. It was superseded by FIXME.
1760 Mmh does no more support this header field.
1761 .P
1762 Native support for
1763 .Hd Face
1764 header fields had been removed, as well.
1765 The feature is similar to the
1766 .Hd X-Face
1767 header field in its intent,
1768 but takes a different approach to store the image.
1769 Instead of encoding the image data directly into the header field,
1770 the it contains the hostname and UDP port where the image
1771 date could be retrieved.
1772 Neither
1773 .Hd X-Face
1774 nor the here described
1775 .Hd Face
1776 system
1777 \**
1778 .FS
1779 There is also a newer but different system, invented 2005,
1780 using
1781 .Hd Face
1782 headers.
1783 It is the successor of
1784 .Hd X-Face
1785 providing colored PNG images.
1786 .FE
1787 became well used in the large scale.
1788 It's still possible to use a Face systems,
1789 although mmh does not provide support for any of the different systems
1790 anymore. It's fairly easy to write a small shell script to
1791 extract the embedded or fetch the external Face data and display the image.
1792 Own
1793 .Hd Face
1794 header field can be added into the draft template files.
1795 .P
1796 .Hd Content-MD5
1797 header fields were introduced by RFC\^1864. They provide only
1798 a verification of data corruption during the transfer. By no means can
1799 they ensure verbatim end-to-end delivery of the contents. This is clearly
1800 stated in the RFC. The proper approach to provide verificationability
1801 of content in an end-to-end relationship is the use of digital cryptography
1802 (RFCs FIXME). On the other hand, transfer protocols should ensure the
1803 integrity of the transmission. In combinations these two approaches
1804 make the
1805 .Hd Content-MD5
1806 header field useless. In consequence, I removed
1807 the support for it. By this removal, MD5 computation is not needed
1808 anywhere in mmh. Hence, over 500 lines of code were removed by this one
1809 change. Even if the
1810 .Hd Content-MD5
1811 header field is useful sometimes,
1812 I value its usefulness less than the improvement in maintainability, caused
1813 by the removal.
1815 .U2 "Prompter's Control Keys
1816 .P
1817 The program
1818 .Pn prompter
1819 queries the user to fill in a message form. When used by
1820 .Pn comp
1821 as:
1822 .VS
1823 comp -editor prompter
1824 VE
1825 the resulting behavior is similar to
1826 .Pn mailx .
1827 Apparently,
1828 .Pn prompter
1829 hadn't been touched lately. Otherwise it's hardly explainable why it
1830 still offered the switches
1831 .Sw -erase
1832 .Ar chr
1833 and
1834 .Sw -kill
1835 .Ar chr
1836 to name the characters for command line editing.
1837 The times when this had been necessary are long time gone.
1838 Today these things work out-of-the-box, and if not, are configured
1839 with the standard tool
1840 .Pn stty .
1842 .U2 "Vfork and Retry Loops
1843 .P
1844 MH creates many processes, which is a consequence of the tool chest approach.
1845 In earlier times
1846 .Fu fork()
1847 had been an expensive system call, as the process's whole image needed
1848 to be duplicated. One common case is replacing the image with
1849 .Fu exec()
1850 right after having forked the child process.
1851 To speed up this case, the
1852 .Fu vfork()
1853 system call was invented at Berkeley. It completely omits copying the
1854 image. If the image gets replaced right afterwards then unnecessary
1855 work is omited. On old systems this results in large speed ups.
1856 MH uses
1857 .Fu vfork()
1858 whenever possible.
1859 .P
1860 Memory management units that support copy-on-write semantics make
1861 .Fu fork()
1862 almost as fast as
1863 .Fu vfork()
1864 in the cases when they can be exchanged.
1865 With
1866 .Fu vfork()
1867 being more error-prone and hardly faster, it's preferable to simply
1868 use
1869 .Fu fork()
1870 instead.
1871 .P
1872 Related to the costs of
1873 .Fu fork()
1874 is the probability of its success.
1875 Today on modern systems, the system call will succeed almost always.
1876 In the Eighties on heavy loaded systems, as they were common at
1877 universities, this had been different. Thus, many of the
1878 .Fu fork()
1879 calls were wrapped into loops to retry to fork several times in
1880 short intervals, in case of previous failure.
1881 In mmh, the program aborts at once if the fork failed.
1882 The user can reexecute the command then. This is expected to be a
1883 very rare case on modern systems, especially personal ones, which are
1884 common today.
1887 .H2 "Attachments
1888 .P
1889 MIME
1892 .H2 "Digital Cryptography
1893 .P
1894 Signing and encryption.
1897 .H2 "Good Defaults
1898 .P
1899 foo
1904 .H1 "Code style
1905 .P
1906 foo
1909 .H2 "Standard Code
1910 .P
1911 POSIX
1914 .H2 "Separation
1916 .U2 "MH Directory Split
1917 .P
1918 In MH and nmh, a personal setup had consisted of two parts:
1919 The MH profile, named
1920 .Fn \&.mh_profile
1921 and being located directly in the user's home directory.
1922 And the MH directory, where all his mail messages and also his personal
1923 forms, scan formats, other configuration files are stored. The location
1924 of this directory could be user-chosen. The default was to name it
1925 .Fn Mail
1926 and have it directly in the home directory.
1927 .P
1928 I've never liked the data storage and the configuration to be intermixed.
1929 They are different kinds of data. One part, are the messages,
1930 which are the data to operate on. The other part, are the personal
1931 configuration files, which are able to change the behavior of the operations.
1932 The actual operations are defined in the profile, however.
1933 .P
1934 When storing data, one should try to group data by its type.
1935 There's sense in the Unix file system hierarchy, where configuration
1936 file are stored separate (\c
1937 .Fn /etc )
1938 to the programs (\c
1939 .Fn /bin
1940 and
1941 .Fn /usr/bin )
1942 to their sources (\c
1943 .Fn /usr/src ).
1944 Such separation eases the backup management, for instance.
1945 .P
1946 In mmh, I've reorganized the file locations.
1947 Still there are two places:
1948 There's the mail storage directory, which, like in MH, contains all the
1949 messages, but, unlike in MH, nothing else.
1950 Its location still is user-chosen, with the default name
1951 .Fn Mail ,
1952 in the user's home directory. This is much similar to the case in nmh.
1953 The configuration files, however, are grouped together in the new directory
1954 .Fn \&.mmh
1955 in the user's home directory.
1956 The user's profile now is a file, named
1957 .Fn profile ,
1958 in this mmh directory.
1959 Consistently, the context file and all the personal forms, scan formats,
1960 and the like, are also there.
1961 .P
1962 The naming changed with the relocation.
1963 The directory where everything, except the profile, had been stored (\c
1964 .Fn $HOME/Mail ),
1965 used to be called \fIMH directory\fP. Now, this directory is called the
1966 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
1967 the new directory
1968 (\c
1969 .Fn $HOME/.mmh ),
1970 containing all the personal configuration files.
1971 .P
1972 The separation of the files by type of content is logical and convenient.
1973 There are no functional differences as any possible setup known to me
1974 can be implemented with both approaches, although likely a bit easier
1975 with the new approach. The main goal of the change had been to provide
1976 sensible storage locations for any type of personal mmh file.
1977 .P
1978 In order for one user to have multiple MH setups, he can use the
1979 environment variable
1980 .Ev MH
1981 the point to a different profile file.
1982 The MH directory (mail storage plus personal configuration files) is
1983 defined by the
1984 .Pe Path
1985 profile entry.
1986 The context file could be defined by the
1987 .Pe context
1988 profile entry or by the
1989 .Ev MHCONTEXT
1990 environment variable.
1991 The latter is useful to have a distinct context (e.g. current folders)
1992 in each terminal window, for instance.
1993 In mmh, there are three environment variables now.
1994 .Ev MMH
1995 may be used to change the location of the mmh directory.
1996 .Ev MMHP
1997 and
1998 .Ev MMHC
1999 change the profile and context files, respectively.
2000 Besides providing a more consistent feel (which simply is the result
2001 of being designed anew), the set of personal configuration files can
2002 be chosen independently from the profile (including mail storage location)
2003 and context, now. Being it relevant for practical use or not, it
2004 de-facto is an improvement. However, the main achievement is the
2005 split between mail storage and personal configuration files.
2008 .H2 "Modularization
2009 .P
2010 whatnowproc
2011 .P
2012 The \fIMH library\fP
2013 .Fn libmh.a
2014 collects a bunch of standard functions that many of the MH tools need,
2015 like reading the profile or context files.
2016 This doesn't hurt the separation.
2019 .H2 "Style
2020 .P
2021 Code layout, goto, ...
2026 .H1 "Concept Exploitation/Homogeneity
2029 .H2 "Draft Folder
2030 .P
2031 Historically, MH provided exactly one draft message, named
2032 .Fn draft
2033 and
2034 being located in the MH directory. When starting to compose another message
2035 before the former one was sent, the user had been questioned whether to use,
2036 refile or replace the old draft. Working on multiple drafts at the same time
2037 was impossible. One could only work on them in alteration by refiling the
2038 previous one to some directory and fetching some other one for reediting.
2039 This manual draft management needed to be done each time the user wanted
2040 to switch between editing one draft to editing another.
2041 .P
2042 To allow true parallel editing of drafts, in a straight forward way, the
2043 draft folder facility exists. It had been introduced already in July 1984
2044 by Marshall T. Rose. The facility was deactivated by default.
2045 Even in nmh, the draft folder facility remained deactivated by default.
2046 At least, Richard Coleman added the man page
2047 .Mp mh-draft(5)
2048 to document
2049 the feature well.
2050 .P
2051 The only advantage of not using the draft folder facility is the static
2052 name of the draft file. This could be an issue for MH front-ends like mh-e.
2053 But as they likely want to provide working on multiple drafts in parallel,
2054 the issue is only concerning compatibility. The aim of nmh to stay compatible
2055 prevented the default activation of the draft folder facility.
2056 .P
2057 On the other hand, a draft folder is the much more natural concept than
2058 a draft message. MH's mail storage consists of folders and messages,
2059 the messages named with ascending numbers. A draft message breaks with this
2060 concept by introducing a message in a file named
2061 .Fn draft .
2062 This draft
2063 message is special. It can not be simply listed with the available tools,
2064 but instead requires special switches. I.e. corner-cases were
2065 introduced. A draft folder, in contrast, does not introduce such
2066 corner-cases. The available tools can operate on the messages within that
2067 folder like on any messages within any mail folders. The only difference
2068 is the fact that the default folder for
2069 .Pn send
2070 is the draft folder,
2071 instead of the current folder, like for all other tools.
2072 .P
2073 The trivial part of the change was activating the draft folder facility
2074 by default and setting a default name for this folder. Obviously, I chose
2075 the name
2076 .Fn +drafts .
2077 This made the
2078 .Sw -draftfolder
2079 and
2080 .Sw -draftmessage
2081 switches useless, and I could remove them.
2082 The more difficult but also the part that showed the real improvement,
2083 was updating the tools to the new concept.
2084 .Sw -draft
2085 switches could
2086 be dropped, as operating on a draft message became indistinguishable to
2087 operating on any other message for the tools.
2088 .Pn comp
2089 still has its
2090 .Sw -use
2091 switch for switching between its two modes: (1) Compose a new
2092 draft, possibly by taking some existing message as a form. (2) Modify
2093 an existing draft. In either case, the behavior of
2094 .Pn comp is
2095 deterministic. There is no more need to query the user. I consider this
2096 a major improvement. By making
2097 .Pn send
2098 simply operate on the current
2099 message in the draft folder by default, with message and folder both
2100 overridable by specifying them on the command line, it is now possible
2101 to send a draft anywhere within the storage by simply specifying its folder
2102 and name.
2103 .P
2104 All theses changes converted special cases to regular cases, thus
2105 simplifying the tools and increasing the flexibility.
2108 .H2 "Trash Folder
2109 .P
2110 Similar to the situation for drafts is the situation for removed messages.
2111 Historically, a message was deleted by renaming. A specific
2112 \fIbackup prefix\fP, often comma (\c
2113 .Fn , )
2114 or hash (\c
2115 .Fn # ),
2116 being prepended to the file name. Thus, MH wouldn't recognize the file
2117 as a message anymore, as only files whose name consists of digits only
2118 are treated as messages. The removed messages remained as files in the
2119 same directory and needed some maintenance job to truly delete them after
2120 some grace time. Usually, by running a command similar to
2121 .VS
2122 find /home/user/Mail -ctime +7 -name ',*' | xargs rm
2123 VE
2124 in a cron job. Within the grace time interval
2125 the original message could be restored by stripping the
2126 the backup prefix from the file name. If however, the last message of
2127 a folder is been removed \(en say message
2128 .Fn 6
2129 becomes file
2130 .Fn ,6
2131 \(en and a new message enters the same folder, thus the same
2132 numbered being given again \(en in our case
2133 .Fn 6
2134 \(en, if that one
2135 is removed too, then the backup of the former message gets overwritten.
2136 Thus, the ability to restore removed messages does not only depend on
2137 the ``sweeping cron job'' but also on the removing of further messages.
2138 This is undesirable, because the real mechanism is hidden from the user
2139 and the consequences of further removals are not always obvious.
2140 Further more, the backup files are scattered within the whole mail
2141 storage, instead of being collected at one place.
2142 .P
2143 To improve the situation, the profile entry
2144 .Pe rmmproc
2145 (previously named
2146 .Pe Delete-Prog )
2147 was introduced, very early.
2148 It could be set to any command, which would care for the mail removal
2149 instead of taking the default action, described above.
2150 Refiling the to-be-removed files to some garbage folder was a common
2151 example. Nmh's man page
2152 .Mp rmm(1)
2153 proposes
2154 .Cl "refile +d
2155 to move messages to the garbage folder and
2156 .Cl "rm `mhpath +d all`
2157 the empty the garbage folder.
2158 Managing the message removal this way is a sane approach. It keeps
2159 the removed messages in one place, makes it easy to remove the backup
2160 files, and, most important, enables the user to use the tools of MH
2161 itself to operate on the removed messages. One can
2162 .Pn scan
2163 them,
2164 .Pn show
2165 them, and restore them with
2166 .Pn refile .
2167 There's no more
2168 need to use
2169 .Pn mhpath
2170 to switch over from MH tools to Unix tools \(en MH can do it all itself.
2171 .P
2172 This approach matches perfect with the concepts of MH, thus making
2173 it powerful. Hence, I made it the default. And even more, I also
2174 removed the old backup prefix approach, as it is clearly less powerful.
2175 Keeping unused alternative in the code is a bad choice as they likely
2176 gather bugs, by not being constantly tested. Also, the increased code
2177 size and more conditions crease the maintenance costs. By strictly
2178 converting to the trash folder approach, I simplified the code base.
2179 .Pn rmm
2180 calls
2181 .Pn refile
2182 internally to move the to-be-removed
2183 message to the trash folder (\c
2184 .Fn +trash
2185 by default). Messages
2186 there can be operated on like on any other message in the storage.
2187 The sweep clean, one can use
2188 .Cl "rmm -unlink +trash a" ,
2189 where the
2190 .Sw -unlink
2191 switch causes the files to be truly unliked instead
2192 of moved to the trash folder.
2195 .H2 "Path Notations
2196 .P
2197 foo
2200 .H2 "MIME Integration
2201 .P
2202 user-visible access to whole messages and MIME parts are inherently
2203 different
2206 .H2 "Of One Cast
2207 .P