docs/master
view ch03.roff @ 104:2818ca27d24c
Various text rework.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Thu, 21 Jun 2012 00:01:13 +0200 |
| parents | a782488c85f5 |
| children | 9ff356d84c57 |
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.
5 The concrete work done
6 is described in the examples of how the general goals were achieved.
7 The discussion compares the current version of mmh with the state of
8 nmh just before the mmh project started, i.e. Fall 2011.
9 Current changes of nmh will be mentioned only as side notes.
10 .\" XXX where do I discuss the parallel development of nmh?
14 .H1 "Stream-Lining
16 .P
17 MH had been considered an all-in-one system for mail handling.
18 The community around nmh has a similar understanding.
19 In fundamental difference, mmh shall be a MUA only.
20 I believe that the development of all-in-one mail systems is obsolete.
21 Today, email is too complex to be fully covered by single projects.
22 Such a project won't be able to excel in all aspects.
23 Instead, the aspects of email should be covered my multiple projects,
24 which then can be combined to form a complete system.
25 Excellent implementations for the various aspects of email exist already.
26 Just to name three examples: Postfix is a specialized MTA,
27 Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
28 I believe that it is best to use such specialized tools instead of
29 providing the same function again as a side-component in the project.
30 .P
31 Doing something well, requires to focus on a small set of specific aspects.
32 Under the assumption that focused development produces better results
33 in the particular area, specialized projects will be superior
34 in their field of focus.
35 Hence, all-in-one mail system projects \(en no matter if monolithic
36 or modular \(en will never be the best choice in any of the fields.
37 Even in providing the best consistent all-in-one system they are likely
38 to be beaten by projects that focus only on integrating existing mail
39 components to a homogeneous system.
40 .P
41 The limiting resource in Free Software community development
42 is usually man power.
43 If the development power is spread over a large development area,
44 it becomes even more difficult to compete with the specialists in the
45 various fields.
46 The concrete situation for MH-based mail systems is even tougher,
47 given the small and aged community, including both developers and users,
48 it has.
49 .P
50 In consequence, I believe that the available development resources
51 should focus on the point where MH is most unique.
52 This is clearly the user interface \(en the MUA.
53 Peripheral parts should be removed to stream-line mmh for the MUA task.
56 .H2 "Mail Transfer Facilities
57 .P
58 In contrast to nmh, which also provides mail submission and mail retrieval
59 agents, mmh is a MUA only.
60 This general difference 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 Mail Submission Agent (MSA) is called
65 \fIMessage Transfer Service\fP (MTS) in nmh.
66 The facility established network connections and spoke SMTP to submit
67 messages for relay to the outside world.
68 This part was implemented by the
69 .Pn post
70 command.
71 The changes in email in the last years
72 demanded changes in this part of nmh too.
73 Encryption and authentication for network connections
74 needed to be supported, hence TLS and SASL were introduced into nmh.
75 This added complexity to nmh without improving it in its core functions.
76 Also, keeping up with recent developments in the field of
77 mail transfer requires development power and specialists.
78 In mmh this whole facility was simply cut off.
79 .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
80 .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
81 .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
82 Instead, mmh depends on an external MSA.
83 The only outgoing interface available to mmh is the
84 .Pn sendmail
85 command, which almost any MSA provides.
86 If not, a wrapper program can be written.
87 It must read the message from the standard input, extract the
88 recipient addresses from the message header, and hand the message
89 over to the MSA.
90 For example, a wrapper script for qmail would be:
91 .VS
92 #!/bin/sh
93 # ignore command line arguments
94 exec qmail-inject
95 VE
96 The requirement to parse the recipient addresses out of the message header
97 is likely to be removed in the future.
98 Then mmh would give the recipient addresses as command line arguments.
99 This appears to be the better interface.
100 .\" XXX implement it
101 .P
102 To retrieve mail, the
103 .Pn inc
104 command acted as Mail Retrieval Agent (MRA).
105 It established network connections
106 and spoke POP3 to retrieve mail from remote servers.
107 As with mail submission, the network connections required encryption and
108 authentication, thus TLS and SASL were added.
109 Support for message retrieval through IMAP will become necessary
110 to be added soon, too, and likewise for any other changes in mail transfer.
111 Not so for mmh because it has dropped the support for retrieving mail
112 from remote locations.
113 .Ci ab7b48411962d26439f92f35ed084d3d6275459c
114 Instead, it depends on an external tool to cover this task.
115 In mmh exist two paths for messages to enter mmh's mail storage:
116 (1) Mail can be incorporated with
117 .Pn inc
118 from the system maildrop, or (2) with
119 .Pn rcvstore
120 by reading them, one at a time, from the standard input.
121 .P
122 With the removal of the MSA and MRA, mmh converted from an all-in-one
123 mail system to being a MUA only.
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 Of course, MSAs and MRAs are more complex than text pagers
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 as
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 At that time,
168 .Pn /bin/mail
169 had covered anything there was to email and still had been small
170 and simple.
171 Later, 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 the concept of mail agents to separate the
178 various tasks because they became more extensive and new tasks appeared.
179 As the mail systems grew even more, parts were split off.
180 In nmh, for instance, the POP server, which was included in the original
181 MH, was removed.
182 Now is the time to go one step further and split the MSA and MRA off, 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 is 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 Functionality 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 adds
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 "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 By 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 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 distinguish between old and new mail, but
316 this detail information can be retrieved with
317 .Pn stat (1),
318 too.
319 A small shell script could be written to print 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 Having less code \(en with equal readability, of course \(en
348 for the same functionality is an advantage.
349 Less code means less bugs and less maintenance work.
350 As
351 .Pn rcvtty
352 and
353 .Pn msgchk
354 are assumed to be rarely used and can be implemented in different ways,
355 why should one keep them?
356 Removing them stream-lines mmh.
357 .Pn viamail 's
358 use case is now partly obsolete and partly covered by
359 .Pn forw ,
360 hence there's no reason to still maintain it.
361 .Pn conflict
362 is not related to the mail client, and
363 .Pn msh
364 conflicts with the basic concept of MH.
365 Theses two tools might still be useful, but they should not be part of mmh.
366 .P
367 Finally, there's
368 .Pn slocal .
369 .Pn slocal
370 is an MDA and thus not directly MUA-related.
371 It should be removed from mmh, because including it conflicts with
372 the idea that mmh is a MUA only.
373 .Pn slocal
374 should rather 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), still,
383 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 Then
394 .Pn slocal
395 could be installed without the complete MH system.
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 appears to be conceptionally the best solution.
402 Yet,
403 .Pn slocal
404 is not split off.
405 I defer the decision over
406 .Pn slocal
407 in need for deeper investigation.
408 In the meanwhile, it remains part of mmh.
409 That does not hurt because
410 .Pn slocal
411 is unrelated to the rest of the project.
414 .H2 "\fLshow\fP and \fPmhshow\fP
415 .P
416 Since the very beginning \(en already in the first concept paper \(en
417 .Pn show
418 had been MH's message display program.
419 .Pn show
420 mapped message numbers and sequences to files and invoked
421 .Pn mhl
422 to have the files formatted.
423 With MIME, this approach wasn't sufficient anymore.
424 MIME messages can consist of multiple parts. Some parts are not
425 directly displayable and text content might be encoded in
426 foreign charsets.
427 .Pn show 's
428 understanding of messages and
429 .Pn mhl 's
430 display capabilities couldn't cope with the task any longer.
431 .P
432 Instead of extending these tools, additional tools were written from
433 scratch and added to the MH tool chest.
434 Doing so is encouraged by the tool chest approach.
435 Modular design is a great advantage for extending a system,
436 as new tools can be added without interfering with existing ones.
437 First, the new MIME features were added in form of the single program
438 .Pn mhn .
439 The command
440 .Cl "mhn -show 42
441 would show the MIME message numbered 42.
442 With the 1.0 release of nmh in February 1999, Richard Coleman finished
443 the split of
444 .Pn mhn
445 into a set of specialized tools, which together covered the
446 multiple aspects of MIME.
447 One of them was
448 .Pn mhshow ,
449 which replaced
450 .Cl "mhn -show" .
451 It was capable of displaying MIME messages appropriately.
452 .P
453 From then on, two message display tools were part of nmh,
454 .Pn show
455 and
456 .Pn mhshow .
457 To ease the life of users,
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 simply 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 .P
476 Having two similar tools for essentially the same task is redundant.
477 Usually,
478 users wouldn't distinguish between
479 .Pn show
480 and
481 .Pn mhshow
482 in their daily mail reading.
483 Having two separate display programs was therefore mainly unnecessary
484 from a user's point of view.
485 Besides, the development of both programs needed to be in sync,
486 to ensure that the programs behaved in a similar way,
487 because they were used like a single tool.
488 Different behavior would have surprised the user.
489 .P
490 Today, non-MIME messages are rather seen to be a special case of
491 MIME messages, although it is the other way round.
492 As
493 .Pn mhshow
494 had already be able to display non-MIME messages, it appeared natural
495 to drop
496 .Pn show
497 in favor of using
498 .Pn mhshow
499 exclusively.
500 .Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
501 Removing
502 .Pn show
503 is no loss in function, because functionally
504 .Pn mhshow
505 covers it completely.
506 The old behavior of
507 .Pn show
508 can still be emulated with the simple command line:
509 .VS
510 mhl `mhpath c`
511 VE
512 .P
513 For convenience,
514 .Pn mhshow
515 was renamed to
516 .Pn show
517 after
518 .Pn show
519 was gone.
520 It is clear that such a rename may confuse future developers when
521 trying to understand the history.
522 Nevertheless, I consider the convenience on the user's side,
523 to call
524 .Pn show
525 when they want a message to be displayed, to outweigh the inconvenience
526 on the developer's side when understanding the project history.
527 .P
528 To prepare for the transition,
529 .Pn mhshow
530 was reworked to behave more like
531 .Pn show
532 first.
533 (cf. Sec. XXX)
534 Once the tools behaved more alike, the replacing appeared to be
535 even more natural.
536 Today, mmh's new
537 .Pn show
538 became the one single message display program again, with the difference
539 that today it handles MIME messages as well as non-MIME messages.
540 The outcome of the transition is one program less to maintain,
541 no second display program for users to deal with,
542 and less system complexity.
543 .P
544 Still, removing the old
545 .Pn show
546 hurts in one regard: It had been such a simple program.
547 Its lean elegance is missing to the new
548 .Pn show .
549 But there is no chance;
550 supporting MIME demands for higher essential complexity.
553 .H2 "Configure Options
554 .P
555 Customization is a double-edged sword.
556 It allows better suiting setups, but not for free.
557 There is the cost of code complexity to be able to customize.
558 There is the cost of less tested setups, because there are
559 more possible setups and especially corner-cases.
560 And, there is the cost of choice itself.
561 The code complexity directly affects the developers.
562 Less tested code affects both, users and developers.
563 The problem of choice affects the users, for once by having to
564 choose, but also by more complex interfaces that require more documentation.
565 Whenever options add little advantages, they should be considered for
566 removal.
567 I have reduced the number of project-specific configure options from
568 fifteen to three.
570 .U3 "Mail Transfer Facilities
571 .P
572 With the removal of the mail transfer facilities five configure
573 options vanished:
574 .P
575 The switches
576 .Sw --with-tls
577 and
578 .Sw --with-cyrus-sasl
579 had activated the support for transfer encryption and authentication.
580 This is not needed anymore.
581 .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
582 .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
583 .P
584 The configure switch
585 .Sw --enable-pop
586 activated the message retrieval facility.
587 The code area that would be conditionally compiled in for TLS and SASL
588 support had been small.
589 The conditionally compiled code area for POP support had been much larger.
590 Whereas the code base changes would only slightly change on toggling
591 TLS or SASL support, it changed much on toggling POP support.
592 The changes in the code base could hardly be overviewed.
593 By having POP support togglable a second code base had been created,
594 one that needed to be tested.
595 This situation is basically similar for the conditional TLS and SASL
596 code, but there the changes are minor and can yet be overviewed.
597 Still, conditional compilation of a code base creates variations
598 of the original program.
599 More variations require more testing and maintenance work.
600 .P
601 Two other options only specified default configuration values:
602 .Sw --with-mts
603 defined the default transport service, either
604 .Ar smtp
605 or
606 .Ar sendmail .
607 In mmh this fixed to
608 .Ar sendmail .
609 .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
610 With
611 .Sw --with-smtpservers
612 default SMTP servers for the
613 .Ar smtp
614 transport service could be specified.
615 .Ci 128545e06224233b7e91fc4c83f8830252fe16c9
616 Both of them became irrelevant.
618 .U3 "Backup Prefix
619 .P
620 The backup prefix is the string that was prepended to message
621 filenames to tag them as deleted.
622 By default it had been the comma character `\f(CW,\fP'.
623 In July 2000, Kimmo Suominen introduced
624 the configure option
625 .Sw --with-hash-backup
626 to change the default to the hash symbol `\f(CW#\fP'.
627 The choice was probably personal preference, because first, the
628 option was named
629 .Sw --with-backup-prefix.
630 and had the prefix symbol as argument.
631 But giving the hash symbol as argument caused too many problems
632 for Autoconf,
633 thus the option was limited to use the hash symbol as the default prefix.
634 This supports the assumption, that the choice for the hash was
635 personal preference only.
636 Being related or not, words that start with the hash symbol
637 introduce a comment in the Unix shell.
638 Thus, the command line
639 .Cl "rm #13 #15
640 calls
641 .Pn rm
642 without arguments because the first hash symbol starts the comment
643 that reaches until the end of the line.
644 To delete the backup files,
645 .Cl "rm ./#13 ./#15"
646 needs to be used.
647 Using the hash as backup prefix can be seen as a precaution against
648 data loss.
649 .P
650 I removed the configure option but added the profile entry
651 .Pe backup-prefix ,
652 which allows to specify an arbitrary string as backup prefix.
653 .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
654 Profile entries are the common method to change mmh's behavior.
655 This change did not remove the choice but moved it to a location where
656 it suited better.
657 .P
658 Eventually, however, the new trash folder concept
659 .Cf "Sec. XXX
660 obsoleted the concept of the backup prefix completely.
661 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
662 .\" (Well, there still are corner-cases to remove until the backup
663 .\" prefix can be laid to rest, eventually.)
664 .\" FIXME: Do this work in the code!
666 .U3 "Editor and Pager
667 .P
668 The two configure options
669 .CW --with-editor=EDITOR
670 .CW --with-pager=PAGER
671 were used to specify the default editor and pager at configure time.
672 Doing so at configure time made sense in the Eighties,
673 when the set of available editors and pagers varied much across
674 different systems.
675 Today, the situation is more homogeneous.
676 The programs
677 .Pn vi
678 and
679 .Pn more
680 can be expected to be available on every Unix system,
681 as they are specified by POSIX since two decades.
682 (The specifications for
683 .Pn vi
684 and
685 .Pn more
686 appeared in
687 .[
688 posix 1987
689 .]
690 and,
691 .[
692 posix 1992
693 .]
694 respectively.)
695 As a first step, these two tools were hard-coded as defaults.
696 .Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f
697 Not changed were the
698 .Pe editor
699 and
700 .Pe moreproc
701 profile entries, which allowed the user to override the system defaults.
702 Later, the concept was reworked to respect the standard environment
703 variables
704 .Ev VISUAL
705 and
706 .Ev PAGER
707 if they are set.
708 Today, mmh determines the editor to use in the following order,
709 taking the first available and non-empty item:
710 .IP (1)
711 Environment variable
712 .Ev MMHEDITOR
713 .IP (2)
714 Profile entry
715 .Pe Editor
716 .IP (3)
717 Environment variable
718 .Ev VISUAL
719 .IP (4)
720 Environment variable
721 .Ev EDITOR
722 .IP (5)
723 Command
724 .Pn vi .
725 .P
726 .Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
727 .P
728 The pager to use is determined in a similar order,
729 also taking the first available and non-empty item:
730 .IP (1)
731 Environment variable
732 .Ev MMHPAGER
733 .IP (2)
734 Profile entry
735 .Pe Pager
736 (replaces
737 .Pe moreproc )
738 .IP (3)
739 Environment variable
740 .Ev PAGER
741 .IP (4)
742 Command
743 .Pn more .
744 .P
745 .Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e
746 .P
747 By respecting the
748 .Ev VISUAL /\c
749 .Ev EDITOR
750 and
751 .Ev PAGER
752 environment variables,
753 the new behavior confirms better to the common style on Unix systems.
754 Additionally, the new approach is more uniform and clearer to users.
757 .U3 "ndbm
758 .P
759 .Pn slocal
760 used to depend on
761 .I ndbm ,
762 a database library.
763 The database is used to store the `\fLMessage-ID\fP's of all
764 messages delivered.
765 This enables
766 .Pn slocal
767 to suppress delivering the same message to the same user twice.
768 (This features was enabled by the
769 .Sw -suppressdup
770 switch.)
771 .P
772 A variety of versions of the database library exist.
773 .[
774 wolter unix incompat notes dbm
775 .]
776 Complicated autoconf code was needed to detect them correctly.
777 Further more, the configure switches
778 .Sw --with-ndbm=ARG
779 and
780 .Sw --with-ndbmheader=ARG
781 were added to help with difficult setups that would
782 not be detected automatically or correctly.
783 .P
784 By removing the suppress duplicates feature of
785 .Pn slocal ,
786 the dependency on
787 .I ndbm
788 vanished and 120 lines of complex autoconf code could be saved.
789 .Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
790 The change removed functionality too, but that is minor to the
791 improvement by dropping the dependency and the complex autoconf code.
793 .U3 "mh-e Support
794 .P
795 The configure option
796 .Sw --disable-mhe
797 was removed when the mh-e support was reworked.
798 Mh-e is the Emacs front-end to MH.
799 It requires MH to provide minor additional functions.
800 The
801 .Sw --disable-mhe
802 configure option could switch these extensions off.
803 After removing the support for old versions of mh-e,
804 only the
805 .Sw -build
806 switches of
807 .Pn forw
808 and
809 .Pn repl
810 are left to be mh-e extensions.
811 They are now always built in because they add little code and complexity.
812 In consequence, the
813 .Sw --disable-mhe
814 configure option was removed
815 .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
816 Removing the option removed a second code setup that would have
817 needed to be tested.
818 This change was first done in nmh and thereafter merged into mmh.
819 .P
820 The interface changes in mmh require mh-e to be adjusted in order
821 to be able to use mmh as back-end.
822 This will require minor changes to mh-e, but removing the
823 .Sw -build
824 switches would require more rework.
826 .U3 "Masquerading
827 .P
828 The configure option
829 .Sw --enable-masquerade
830 could take up to three arguments:
831 `draft_from', `mmailid', and `username_extension'.
832 They activated different types of address masquerading.
833 All of them were implemented in the SMTP-speaking
834 .Pn post
835 command, which provided an MSA.
836 Address masquerading is an MTA's task and mmh does not cover
837 this field anymore.
838 Hence, true masquerading needs to be implemented in the external MTA.
839 .P
840 The
841 .I mmailid
842 masquerading type is the oldest one of the three and the only one
843 available in the original MH.
844 It provided a
845 .I username
846 to
847 .I fakeusername
848 mapping, based on the password file's GECOS field.
849 The man page
850 .Mp mh-tailor(5)
851 described the use case as being the following:
852 .QS
853 This is useful if you want the messages you send to always
854 appear to come from the name of an MTA alias rather than your
855 actual account name. For instance, many organizations set up
856 `First.Last' sendmail aliases for all users. If this is
857 the case, the GECOS field for each user should look like:
858 ``First [Middle] Last <First.Last>''
859 .QE
860 .P
861 As mmh sends outgoing mail via the local MTA only,
862 the best location to do such global rewrites is there.
863 Besides, the MTA is conceptionally the right location because it
864 does the reverse mapping for incoming mail (aliasing), too.
865 Further more, masquerading set up there is readily available for all
866 mail software on the system.
867 Hence, mmailid masquerading was removed.
868 .Ci 0836c8000ccb34b59410ef1c15b1b7feac70ce5f
869 .P
870 The
871 .I username_extension
872 masquerading type did not replace the username but would append a suffix,
873 specified by the
874 .Ev USERNAME_EXTENSION
875 environment variable, to it.
876 This provided support for the
877 .I user-extension
878 feature of qmail and the similar
879 .I "plussed user
880 processing of sendmail.
881 The decision to remove this username_extension masquerading was
882 motivated by the fact that
883 .Pn spost
884 hadn't supported it already.
885 .Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
886 Username extensions are possible in mmh, but less convenient to use.
887 .\" XXX format file %(getenv USERNAME_EXTENSION)
888 .P
889 The
890 .I draft_from
891 masquerading type instructed
892 .Pn post
893 to use the value of the
894 .Hd From
895 header field as SMTP envelope sender.
896 Sender addresses could be replaced completely.
897 .Ci b14ea6073f77b4359aaf3fddd0e105989db9
898 Mmh offers a kind of masquerading similar in effect, but
899 with technical differences.
900 As mmh does not transfer messages itself, the local MTA has final control
901 over the sender's address. Any masquerading mmh introduces may be reverted
902 by the MTA.
903 In times of pedantic spam checking, an MTA will take care to use
904 sensible envelope sender addresses to keep its own reputation up.
905 Nonetheless, the MUA can set the
906 .Hd From
907 header field and thereby propose
908 a sender address to the MTA.
909 The MTA may then decide to take that one or generate the canonical sender
910 address for use as envelope sender address.
911 .P
912 In mmh, the MTA will always extract the recipient and sender from the
913 message header (\c
914 .Pn sendmail 's
915 .Sw -t
916 switch).
917 The
918 .Hd From
919 header field of the draft may be set arbitrary by the user.
920 If it is missing, the canonical sender address will be generated by the MTA.
922 .U3 "Remaining Options
923 .P
924 Two configure options remain in mmh.
925 One is the locking method to use:
926 .Sw --with-locking=[dot|fcntl|flock|lockf] .
927 The idea of removing all methods except the portable dot locking
928 and having that one as the default is appealing, but this change
929 requires deeper technical investigation into the topic.
930 The other option,
931 .Sw --enable-debug ,
932 compiles the programs with debugging symbols and does not strip them.
933 This option is likely to stay.
938 .H2 "Command Line Switches
939 .P
940 The command line switches of MH tools follow the X Window style.
941 They are words, introduced by a single dash.
942 For example:
943 .Cl "-truncate" .
944 Every program in mmh has two generic switches:
945 .Sw -help ,
946 to print a short message on how to use the program, and
947 .Sw -Version ,
948 to tell what version of mmh the program belongs to.
949 .P
950 Switches change the behavior of programs.
951 Programs that do one thing in one way require no switches.
952 In most cases, doing something in exactly one way is too limiting.
953 If there is basically one task to accomplish, but it should be done
954 in various ways, switches are a good approach to alter the behavior
955 of a program.
956 Changing the behavior of programs provides flexibility and customization
957 to users, but at the same time it complicates the code, documentation and
958 usage of the program.
959 .\" XXX: Ref
960 Therefore, the number of switches should be kept small.
961 A small set of well-chosen switches does no harm.
962 But usually, the number of switches increases over time.
963 Already in 1985, Rose and Romine have identified this as a major
964 problem of MH:
965 .[ [
966 rose romine real work
967 .], p. 12]
968 .QS
969 A complaint often heard about systems which undergo substantial development
970 by many people over a number of years, is that more and more options are
971 introduced which add little to the functionality but greatly increase the
972 amount of information a user needs to know in order to get useful work done.
973 This is usually referred to as creeping featurism.
974 .QP
975 Unfortunately MH, having undergone six years of off-and-on development by
976 ten or so well-meaning programmers (the present authors included),
977 suffers mightily from this.
978 .QE
979 .P
980 Being reluctant to adding new switches \(en or `options',
981 as Rose and Romine call them \(en is one part of a counter-action,
982 the other part is removing hardly used switches.
983 Nmh's tools had lots of switches already implemented,
984 hence, cleaning up by removing some of them was the more important part
985 of the counter-action.
986 Removing existing functionality is always difficult because it
987 breaks programs that use these functions.
988 Also, for every obsolete feature, there'll always be someone who still
989 uses it and thus opposes its removal.
990 This puts the developer into the position,
991 where sensible improvements to style are regarded as destructive acts.
992 Yet, living with the featurism is far worse, in my eyes, because
993 future needs will demand adding further features,
994 worsening the situation more and more.
995 Rose and Romine added in a footnote,
996 ``[...]
997 .Pn send
998 will no doubt acquire an endless number of switches in the years to come.''
999 Although clearly humorous, the comment points to the nature of the problem.
1000 Refusing to add any new switches would encounter the problem at its root,
1001 but this is not practical.
1002 New needs will require new switches and it would be unwise to block
1003 them strictly.
1004 Nevertheless, removing obsolete switches still is an effective approach
1005 to deal with the problem.
1006 Working on an experimental branch without an established user base,
1007 eased my work because I did not offend users when I removed existing
1008 funtions.
1009 .P
1010 Rose and Romine counted 24 visible and 9 more hidden switches for
1011 .Pn send .
1012 In nmh, they increased up to 32 visible and 12 hidden ones.
1013 At the time of writing, no more than 7 visible switches and 1 hidden switch
1014 have remained in mmh's
1015 .Pn send .
1016 (These numbers include two generic switches, help and version.)
1017 .P
1018 Fig. XXX
1019 .\" XXX Ref
1020 displays the number of switches for each of the tools that is available
1021 in both, nmh and mmh.
1022 The tools are sorted by the number of switches they had in nmh.
1023 Visible and hidden switches were counted,
1024 but not the generic help and version switches.
1025 Whereas in the beginning of the project, the average tool had 11 switches,
1026 now it has no more than 5 \(en only half as many.
1027 If the `no' switches and similar inverse variant are folded onto
1028 their counter-parts, the average tool had 8 switches in pre-mmh times and
1029 has 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 complete 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, when
1057 Rose and Romine called it a ``relatively new feature''.
1058 .[
1059 rose romine real work
1060 .]
1061 Since then, the facility had existed but was deactivated by default.
1062 The default activation and the related rework of the tools made it
1063 possible to remove the
1064 .Sw -[no]draftfolder ,
1065 and
1066 .Sw -draftmessage
1067 switches from
1068 .Pn comp ,
1069 .Pn repl ,
1070 .Pn forw ,
1071 .Pn dist ,
1072 .Pn whatnow ,
1073 and
1074 .Pn send .
1075 .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
1076 The only flexibility removed with this change is having multiple
1077 draft folders within one profile.
1078 I consider this a theoretical problem only.
1079 In the same go, the
1080 .Sw -draft
1081 switch of
1082 .Pn anno ,
1083 .Pn refile ,
1084 and
1085 .Pn send
1086 was removed.
1087 The special-casing of `the' draft message became irrelevant after
1088 the rework of the draft system.
1089 (See Sec. XXX.)
1090 Equally,
1091 .Pn comp
1092 lost its
1093 .Sw -file
1094 switch.
1095 The draft folder facility, together with the
1096 .Sw -form
1097 switch, are sufficient.
1100 .U3 "In Place Editing
1101 .P
1102 .Pn anno
1103 had the switches
1104 .Sw -[no]inplace
1105 to either annotate the message in place and thus preserve hard links,
1106 or annotate a copy to replace the original message, breaking hard links.
1107 Following the assumption that linked messages should truly be the
1108 same message, and annotating it should not break the link, the
1109 .Sw -[no]inplace
1110 switches were removed and the previous default
1111 .Sw -inplace
1112 was made the only behavior.
1113 .Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0
1114 The
1115 .Sw -[no]inplace
1116 switches of
1117 .Pn repl ,
1118 .Pn forw ,
1119 and
1120 .Pn dist
1121 could be removed, too, as they were simply passed through to
1122 .Pn anno .
1123 .P
1124 .Pn burst
1125 also had
1126 .Sw -[no]inplace
1127 switches, but with different meaning.
1128 With
1129 .Sw -inplace ,
1130 the digest had been replaced by the table of contents (i.e. the
1131 introduction text) and the bursted messages were placed right
1132 after this message, renumbering all following messages.
1133 Also, any trailing text of the digest was lost, though,
1134 in practice, it usually consists of an end-of-digest marker only.
1135 Nontheless, this behavior appeared less elegant than the
1136 .Sw -noinplace
1137 behavior, which already had been the default.
1138 Nmh's
1139 .Mp burst (1)
1140 man page reads:
1141 .sp \n(PDu
1142 .QS
1143 If -noinplace is given, each digest is preserved, no table
1144 of contents is produced, and the messages contained within
1145 the digest are placed at the end of the folder. Other messages
1146 are not tampered with in any way.
1147 .QE
1148 .LP
1149 The decision to drop the
1150 .Sw -inplace
1151 behavior was supported by the code complexity and the possible data loss
1152 it caused.
1153 .Sw -noinplace
1154 was chosen to be the definitive behavior.
1155 .Ci 68a686adeb39223a5e1ad35e4a24890ec053679d
1158 .U3 "Forms and Format Strings
1159 .P
1160 Historically, the tools that had
1161 .Sw -form
1162 switches to supply a form file had
1163 .Sw -format
1164 switches as well to supply the contents of a form file as a string
1165 on the command line directly.
1166 In consequence, the following two lines equaled:
1167 .VS
1168 scan -form scan.mailx
1169 scan -format "`cat .../scan.mailx`"
1170 VE
1171 The
1172 .Sw -format
1173 switches were dropped in favor for extending the
1174 .Sw -form
1175 switches.
1176 .Ci f51956be123db66b00138f80464d06f030dbb88d
1177 If their argument starts with an equal sign (`='),
1178 then the rest of the argument is taken as a format string,
1179 otherwise the arguments is treated as the name of a format file.
1180 Thus, now the following two lines equal:
1181 .VS
1182 scan -form scan.mailx
1183 scan -form "=`cat .../scan.mailx`"
1184 VE
1185 This rework removed the prefix collision between
1186 .Sw -form
1187 and
1188 .Sw -format .
1189 Now, typing
1190 .Sw -fo
1191 suffices to specify form or format string.
1192 .P
1193 The different meaning of
1194 .Sw -format
1195 for
1196 .Pn repl
1197 and
1198 .Pn forw
1199 was removed in mmh.
1200 .Pn forw
1201 was completely switched to MIME-type forwarding, thus removing the
1202 .Sw -[no]format .
1203 .Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
1204 For
1205 .Pn repl ,
1206 the
1207 .Sw -[no]format
1208 switches were reworked to
1209 .Sw -[no]filter
1210 switches.
1211 .Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
1212 The
1213 .Sw -format
1214 switches of
1215 .Pn send
1216 and
1217 .Pn post ,
1218 which had a third meaning,
1219 were removed likewise.
1220 .Ci f3cb7cde0e6f10451b6848678d95860d512224b9
1221 Eventually, the ambiguity of the
1222 .Sw -format
1223 switches was resolved by not anymore having any such switch in mmh.
1226 .U3 "MIME Tools
1227 .P
1228 The MIME tools, which were once part of
1229 .Pn mhn
1230 [sic!],
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 switch 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 creates only a draft message.
1488 As
1489 .Cl "-whatnowproc true
1490 causes the same behavior, the
1491 .Sw -nowhatnowproc
1492 switch was removed for being redundant.
1493 Likely, the
1494 .Sw -nowhatnowproc
1495 switch was intended to be used by front-ends.
1498 .U3 "Compatibility Switches
1499 .BU
1500 The hidden
1501 .Sw -[no]total
1502 switches of
1503 .Pn flist .
1504 They were simply the inverse of the visible
1505 .Sw -[no]fast
1506 switches:
1507 .Sw -total
1508 was
1509 .Sw -nofast
1510 and
1511 .Sw -nototal
1512 was
1513 .Sw -fast .
1514 I removed the
1515 .Sw -[no]total
1516 legacy.
1517 .Ci ea21fe2c4bd23c639bef251398fae809875732ec
1518 .BU
1519 The
1520 .Sw -subject
1521 switch of
1522 .Pn sortm
1523 existed for compatibility only.
1524 It can be fully replaced by
1525 .Cl "-textfield subject
1526 thus it was removed.
1527 .Ci 00140a3c86e9def69d98ba2ffd4d6e50ef6326ea
1530 .U3 "Various
1531 .BU
1532 In order to avoid prefix collisions among switch names, the
1533 .Sw -version
1534 switch was renamed to
1535 .Sw -Version
1536 (with capital `V').
1537 .Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a
1538 Every program has the
1539 .Sw -version
1540 switch but its first three letters collided with the
1541 .Sw -verbose
1542 switch, present in many programs.
1543 The rename solved this problem once for all.
1544 Although this rename breaks a basic interface, having the
1545 .Sw -V
1546 abbreviation to display the version information, isn't all too bad.
1547 .BU
1548 .Sw -[no]preserve
1549 of
1550 .Pn refile
1551 was removed because what use was it anyway?
1552 .QS
1553 Normally when a message is refiled, for each destination
1554 folder it is assigned the number which is one above the current
1555 highest message number in that folder. Use of the
1556 \-preserv [sic!] switch will override this message renaming, and try
1557 to preserve the number of the message. If a conflict for a
1558 particular folder occurs when using the \-preserve switch,
1559 then refile will use the next available message number which
1560 is above the message number you wish to preserve.
1561 .QE
1562 .BU
1563 The removal of the
1564 .Sw -[no]reverse
1565 switches of
1566 .Pn scan
1567 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
1568 is a bug fix, supported by the comments
1569 ``\-[no]reverse under #ifdef BERK (I really HATE this)''
1570 by Rose and
1571 ``Lists messages in reverse order with the `\-reverse' switch.
1572 This should be considered a bug.'' by Romine in the documentation.
1573 The question remains why neither Rose and Romine had fixed this
1574 bug in the Eighties when they wrote these comments nor has anyone
1575 thereafter.
1578 .ig
1580 forw: [no]dashstuffing(mhl)
1582 mhshow: [no]pause [no]serialonly
1584 mhmail: resent queued
1585 inc: snoop, (pop)
1587 mhl: [no]faceproc folder sleep
1588 [no]dashstuffing(forw) digest list volume number issue number
1590 prompter: [no]doteof
1592 refile: [no]preserve [no]unlink [no]rmmproc
1594 send: [no]forward [no]mime [no]msgid
1595 [no]push split [no]unique (sasl) width snoop [no]dashstuffing
1596 attach attachformat
1597 whatnow: (noedit) attach
1599 slocal: [no]suppressdups
1601 spost: [no]filter [no]backup width [no]push idanno
1602 [no]check(whom) whom(whom)
1604 whom: ???
1606 ..
1609 .ig
1611 .P
1612 In the best case, all switches are unambiguous on the first character,
1613 or on the three-letter prefix for the `no' variants.
1614 Reducing switch prefix collisions, shortens the necessary prefix length
1615 the user must type.
1616 Having less switches helps best.
1618 ..
1621 .\" XXX: whatnow prompt commands
1626 .H1 "Modernizing
1627 .P
1628 The code base of mmh originates from the late Seventies.
1629 Through the Eighties, extensive work had been done on it.
1630 In the Nineties, it had been partly reorganized and extended.
1631 Relicts from each decade have gathered in the code base.
1632 My goal was to modernize the code base.
1634 .P
1635 FIXME functional aspect only here
1636 .P
1637 FIXME ref to `code style' for non-functional aspects.
1640 .H2 "Code Relicts
1641 .P
1642 My position to drop obsolete functionality of mmh to remove old code
1643 is much more revolutional than the nmh community likes to have it.
1644 Working on an experimental version, I was able to quickly drop
1645 functionality I considered ancient.
1646 The need for consensus with peers would have slowed this process down.
1647 Without the need to justify my decisions, I was able to rush forward.
1648 In Dezember 2011, Paul Vixie motivated the nmh developers to just
1649 do the work:
1650 .[
1651 paul vixie edginess nmh-workers
1652 .]
1653 .QS
1654 let's stop walking on egg shells with this code base. there's no need to
1655 discuss whether to keep using vfork, just note in [sic!] passing, [...]
1656 we don't need a separate branch for removing vmh
1657 or ridding ourselves of #ifdef's or removing posix replacement functions
1658 or depending on pure ansi/posix "libc".
1659 .QP
1660 these things should each be a day or two of work and the "main branch"
1661 should just be modern. [...]
1662 let's push forward, aggressively.
1663 .QE
1664 .LP
1665 I did so already in the months before.
1666 I pushed forward.
1667 I simply dropped the cruft.
1668 .P
1669 The decision to drop a feature was based on literature research and
1670 careful thinking, but whether having had contact to this particular
1671 feature within my own computer life served as a rule of thumb.
1672 My reasons are always made clean in the commit message for the
1673 version control system.
1674 Hence, others can comprehend my view and argue for undoing the change
1675 if I have missed an important aspect.
1678 .U3 "Forking
1679 .P
1680 In being a tool chest, MH creates many processes.
1681 In earlier times
1682 .Fu fork()
1683 had been an expensive system call, because the process's image needed
1684 to be duplicated completely at once.
1685 This was especially painfull in the common case when the image gets
1686 replaced by a call to
1687 .Fu exec()
1688 right after having forked the child process.
1689 The
1690 .Fu vfork()
1691 system call was invented to speed up this particular case.
1692 It completely omits the duplication of the image.
1693 On old systems this resulted in significant speed ups.
1694 Therefore MH used
1695 .Fu vfork()
1696 whenever possible.
1697 .P
1698 Modern memory management units support copy-on-write semantics, which make
1699 .Fu fork()
1700 almost as fast as
1701 .Fu vfork() .
1702 The man page of
1703 .Mp vfork (2)
1704 in FreeBSD 8.0 states:
1705 .QS
1706 This system call will be eliminated when proper system sharing mechanisms
1707 are implemented. Users should not depend on the memory sharing semantics
1708 of vfork() as it will, in that case, be made synonymous to fork(2).
1709 .QE
1710 .LP
1711 Vixie supports the removal with the note that ``the last
1712 system on which fork was so slow that an mh user would notice it, was
1713 Eunice. that was 1987''.
1714 .[
1715 nmh-workers vixie edginess
1716 .]
1717 I replaced all calls to
1718 .Fu vfork()
1719 with calls to
1720 .Fu fork() .
1721 .P
1722 Related to the costs of
1723 .Fu fork()
1724 is the probability of its success.
1725 In the Eighties on heavy loaded systems, calls to
1726 .Fu fork()
1727 were prone to failure.
1728 Hence, many of the
1729 .Fu fork()
1730 calls in the code were wrapped into loops to retry the
1731 .Fu fork()
1732 several times, for higher changes to succeed, eventually.
1733 On modern systems, failing calls to
1734 .Fu fork()
1735 are unusual.
1736 Hence, in the rare case when
1737 .Fu fork()
1738 fails, mmh programs simply abort.
1741 .U3 "Obsolete Header Fields
1742 .BU
1743 The
1744 .Hd Encrypted
1745 header field was introduced by RFC\|822,
1746 but already marked legacy in RFC\|2822.
1747 OpenPGP provides the basis for standardized exchange of encrypted
1748 messages [RFC\|4880, RFC\|3156].
1749 The support for
1750 .Hd Encrypted
1751 header fields is removed in mmh.
1752 .BU
1753 Native support for
1754 .Hd Face
1755 header fields has been removed, as well.
1756 This feature is similar to the
1757 .Hd X-Face
1758 header field in its intent,
1759 but takes a different approach to store the image.
1760 Instead of encoding the image data directly into the header field,
1761 the it contains the hostname and UDP port where the image
1762 date could be retrieved.
1763 There is even a third system, invented in 2005.
1764 Although it re-uses the
1765 .Hd Face
1766 header field, it is the successor of
1767 .Hd X-Face
1768 with support for colored PNG images.
1769 None of the Face systems described here is popular today.
1770 Hence, mmh has no direct support for them.
1771 .BU
1772 The
1773 .Hd Content-MD5
1774 header field was introduced by RFC\|1864.
1775 It provides detection of data corruption during the transfer.
1776 But it can not ensure verbatim end-to-end delivery of the contents
1777 [RFC\|1864].
1778 The proper approach to verify content integrity in an
1779 end-to-end relationship is the use of digital cryptography.
1780 .\" XXX (RFCs FIXME).
1781 On the other hand, transfer protocols should detect corruption during
1782 each transmission. The TCP includes a checksum field therefore.
1783 These two approaches in combinations render the
1784 .Hd Content-MD5
1785 header field superfluous.
1786 The nmh-workers mailing list archive contains about 4\|200 messages,
1787 ranging from 1992 until today.
1788 Not a single one had a
1789 .Hd Content-MD5
1790 header field.
1791 Neither did any of the 60\|000 messages in my personal mail storage.
1792 Removing the support for this header field,
1793 removed the last place where MD5 computation was needed.
1794 Hence, the MD5 code could be removed as well.
1795 Over 500 lines of code vanished by this one change.
1798 .U3 "MMDF maildrop support
1799 .P
1800 This type of format is conceptionally similar to the mbox format,
1801 but uses a different message delimiter (`\fL^A^A^A^A\fP' instead of
1802 `\fLFrom\0\fP').
1803 Mbox is the de-facto standard maildrop format on Unix,
1804 whereas the MMDF maildrop format is hardly still known today.
1805 I did drop MMDF maildrop format support.
1806 .P
1807 The simplifications within the code were only moderate.
1808 Switches could be removed from
1809 .L packf
1810 and
1811 .L rcvpack ,
1812 which generate packed mailboxes.
1813 Only one packed mailbox format remained: mbox.
1814 The more important changes affected the equally named mail parsing
1815 routine in
1816 .Fn sbr/m_getfld.c .
1817 The MMDF code had been removed there, but as now only one packed mailbox
1818 format is left, further code structure simplifications may be possible.
1819 I have not worked on them yet because
1820 .Fu m_getfld()
1821 is heavily optimized and thus dangerous to touch.
1822 The risk of damaging the intricate workings of the optimized code is
1823 too high.
1824 .\" XXX: move somewhere else
1825 This problem is know to the developers of nmh, too.
1826 They also avoid touching this minefield if possible.
1829 .U3 "Prompter's Control Keys
1830 .P
1831 The program
1832 .Pn prompter
1833 queries the user to fill in a message form.
1834 When used by
1835 .Pn comp
1836 as
1837 .Cl "comp -editor prompter" ,
1838 the resulting behavior is similar to
1839 .Pn mailx .
1840 Apparently,
1841 .Pn prompter
1842 hadn't been touched lately.
1843 Otherwise it's hardly explainable why it
1844 still offered the switches
1845 .Sw -erase
1846 .Ar chr
1847 and
1848 .Sw -kill
1849 .Ar chr
1850 to name the characters for command line editing.
1851 The times when this had been necessary are long time gone.
1852 Today these things work out-of-the-box, and if not, are configured
1853 with the standard tool
1854 .Pn stty .
1855 The switches are removed now
1856 .Ci 0bd9750710cdbab80cfb4036dd87af20afe1552f .
1859 .U3 "Hardcopy terminal support
1860 .P
1861 More of a funny anecdote is a check for printing to a
1862 hardcopy terminal that remained in the code until Spring 2012,
1863 when I finally removed it
1864 .Ci b7764c4a6b71d37918a97594d866258f154017ca .
1865 I surely would be very happy to see such a terminal in action,
1866 maybe actually being able to work on it, but I fear my chances are null.
1867 .P
1868 The check only prevented a pager to be placed between the outputting
1869 program (\c
1870 .Pn mhl )
1871 and the terminal.
1872 In nmh, this could have been ensured with the
1873 .Sw -nomoreproc
1874 at the command line statically, too.
1875 In mmh, set the profile entry
1876 .Pe Pager
1877 or the environment variable
1878 .Ev PAGER
1879 to
1880 .Pn cat .
1885 .H2 "Attachments
1886 .P
1887 The mind model of email attachments is unrelated to MIME.
1888 Although the MIME RFCs (2045 through 2049) define the technical
1889 requirements for having attachments, they do not mention the the word
1890 ``attachment''.
1891 Instead of attachments, MIME talks about ``multi-part message bodies''
1892 [RFC\|2045], a more general concept.
1893 Multi-part messages are messages
1894 ``in which one or more different
1895 sets of data are combined in a single body''
1896 [RFC\|2046].
1897 MIME keeps its descriptions generic;
1898 it does not imply specific usage models.
1899 In email one usage model became prevalent: attachments.
1900 The idea is having a main text document with files of arbitrary kind
1901 attached to it.
1902 In MIME terms, this is a multi-part message having a text part first
1903 and parts of arbitray type following.
1904 .P
1905 MH's MIME support is a direct implementation of the RFCs.
1906 The perception of the topic described in the RFCs is clearly visible
1907 in MH's implementation.
1908 Thus, MH had all the MIME features but no idea of attachments.
1909 Today, however, users don't need all the MIME features but they want
1910 convenient attachment handling.
1912 .U3 "Composing MIME Messages
1913 .P
1914 In order to improve the situation on the message composing side,
1915 Jon Steinhart had added an attachment system to nmh in 2002.
1916 .Ci 7480dbc14bc90f2d872d434205c0784704213252
1917 In the file
1918 .Fn docs/README-ATTACHMENTS ,
1919 he described his motivation to do so as such:
1920 .QS
1921 Although nmh contains the necessary functionality for MIME message handing,
1922 the interface to this functionality is pretty obtuse.
1923 There's no way that I'm ever going to convince my partner to write
1924 .Pn mhbuild
1925 composition files!
1926 .QE
1927 .LP
1928 With this change, the mind model of attachments entered nmh.
1929 In the same document:
1930 .QS
1931 These changes simplify the task of managing attachments on draft files.
1932 They allow attachments to be added, listed, and deleted.
1933 MIME messages are automatically created when drafts with attachments
1934 are sent.
1935 .QE
1936 .LP
1937 Unfortunately, the attachment system,
1938 like any new facilities in nmh,
1939 was deactive by default.
1940 .P
1941 During my work in Argentina, I tried to improve the attachment system.
1942 But, because of great opposition in the nmh community,
1943 my patch died as a proposal on the mailing list, after long discussions.
1944 .[
1945 nmh-workers attachment proposal
1946 .]
1947 In Januar 2012, I extended the patch and applied it to mmh.
1948 .Ci 8ff284ff9167eff8f5349481529332d59ed913b1
1949 In mmh, the attachment system is active by default.
1950 Instead of command line switches, the
1951 .Pe Attachment-Header
1952 profile entry is used to specify
1953 the name of the attachment header field.
1954 It is pre-defined to
1955 .Hd Attach .
1956 .P
1957 To add an attachment to a draft, simply add an attachment header:
1958 .VS
1959 To: bob
1960 Subject: The file you wanted
1961 Attach: /path/to/the/file-bob-wanted
1962 --------
1963 Here it is.
1964 VE
1965 The header field can be added to the draft manually in the editor,
1966 or by using the `attach' command at the WhatNow prompt, or
1967 non-interactively with
1968 .Pn anno :
1969 .VS
1970 anno -append -nodate -component Attach -text /path/to/attachment
1971 VE
1972 Drafts with attachment headers are converted to MIME automatically by
1973 .Pn send .
1974 The conversion to MIME is invisible to the user.
1975 The draft stored in the draft folder is always in source form, with
1976 attachment headers.
1977 If the MIMEification fails, for instance because the file to attach
1978 is not accessible, the original draft is not changed.
1979 .P
1980 The attachment system handles the forwarding of messages, too.
1981 If the attachment header value starts with a plus character (`+'),
1982 like in
1983 .Cl "Attach: +bob 30 42" ,
1984 The given messages in the specified folder will be attached.
1985 This allowed to simplify
1986 .Pn forw .
1987 .Ci f41f04cf4ceca7355232cf7413e59afafccc9550
1988 .P
1989 Closely related to attachments is non-ASCII text content,
1990 because it requires MIME too.
1991 In nmh, the user needed to call `mime' at the WhatNow prompt
1992 to have the draft converted to MIME.
1993 This was necessary whenever the draft contained non-ASCII characters.
1994 If the user did not call `mime', a broken message would be sent.
1995 Therefore, the
1996 .Pe automimeproc
1997 profile entry could be specified to have the `mime' command invoked
1998 automatically each time.
1999 Unfortunately, this approach conflicted with with attachment system
2000 because the draft would already be in MIME format at the time
2001 when the attachment system wanted to MIMEify it.
2002 To use nmh's attachment system, `mime' must not be called at the
2003 WhatNow prompt and
2004 .Pe automimeproc
2005 must not be set in the profile.
2006 But then the case of non-ASCII text without attachment headers was
2007 not caught.
2008 All in all, the solution was complex and irritating.
2009 My patch from December 2010 would have simplified the situation.
2010 .P
2011 Mmh's current solution is even more elaborate.
2012 Any necessary MIMEification is done automatically.
2013 There is no `mime' command at the WhatNow prompt anymore.
2014 The draft will be converted automatically to MIME when either an
2015 attachment header or non-ASCII text is present.
2016 Further more, the special meaning of the hash character (`#')
2017 at line beginnings in the draft message is removed.
2018 Users need not at all deal with the whole topic.
2019 .P
2020 Although the new approach does not anymore support arbitrary MIME
2021 compositions directly, the full power of
2022 .Pn mhbuild
2023 can still be accessed.
2024 Given no attachment headers are included, the user can create
2025 .Pn mhbuild
2026 composition drafts like in nmh.
2027 Then, at the WhatNow prompt, he needs to invoke
2028 .Cl "edit mhbuild
2029 to convert it to MIME.
2030 Because the resulting draft does neither contain non-aASCII characters
2031 nor has it attachment headers, the attachment system will not touch it.
2032 .P
2033 The approach taken in mmh is taylored towards todays most common case:
2034 a text part with possibly attachments.
2035 This case is simplified a lot for users.
2037 .U3 "MIME Type Guessing
2038 .P
2039 The use of
2040 .Pn mhbuild
2041 composition drafts had one notable advantage over attachment headers
2042 from the programmer's point of view: The user provides the appropriate
2043 MIME types for files to include.
2044 The attachment system needs to find out the correct MIME type itself.
2045 This is a difficult task, yet it spares the user irritating work.
2046 Determining the correct MIME type of content is partly mechanical,
2047 partly intelligent work.
2048 Forcing the user to find out the correct MIME type,
2049 forces him to do partly mechanical work.
2050 Letting the computer do the work, can lead to bad choices for difficult
2051 content.
2052 For mmh, the latter option was chosen.
2053 .P
2054 Determining the MIME type by the suffix of the file name is a dumb
2055 approach, yet it is simple to implement and provides good results
2056 for the common cases.
2057 Mmh implements this approach in the
2058 .Pn print-mimetype
2059 script.
2060 Using it is the default choice.
2061 .P
2062 A far better but less portable approach is the use of
2063 .Pn file .
2064 This standard tool tries to determine the type of files.
2065 Unfortunately, its capabilities and accuracy varies from system to system.
2066 Additionally, its output was only intended for human beings,
2067 but not to be used by programs.
2068 It varies much.
2069 Nevertheless, modern versions of GNU
2070 .Pn file ,
2071 which is prevalent on the popular GNU/Linux systems,
2072 provides MIME type output in machine-readable form.
2073 Although this solution is highly system-dependent,
2074 it solves the difficult problem well.
2075 On systems where GNU
2076 .Pn file ,
2077 version 5.04 or higher, is available it should be used.
2078 One needs to specify the following profile entry to do so:
2079 .VS
2080 Mime-Type-Query: file -b --mime
2081 VE
2082 .LP
2083 Other versions of
2084 .Pn file
2085 might possibly be usable with wrapper scripts to reformat the output.
2086 The diversity among
2087 .Pn file
2088 implementations is great; one needs to check the local variant.
2089 .P
2090 If no MIME type can be determined, text content gets sent as
2091 `text/plain' and anything else under the generic fall-back type
2092 `application/octet-stream'.
2093 It is not possible in mmh to override the automatic MIME type guessing
2094 for a specific file.
2095 To do so, the user would need to know in advance for which file
2096 the automatic guessing does fail, or the system would require interaction.
2097 I consider both cases impractical.
2098 The existing solution should be sufficient.
2099 If not, the user may always fall back to
2100 .Pn mhbuild
2101 composition drafts and ignore the attachment system.
2104 .U3 "Storing Attachments
2105 .P
2106 FIXME
2109 .U3 "Showing MIME Messages
2110 .P
2111 FIXME
2115 .H2 "Digital Cryptography
2116 .P
2117 Signing and encryption.
2121 .H2 "Modern Defaults
2122 .P
2123 Just to give one example, for me it took one year of using nmh
2124 before I became aware of the existence of the attachment system.
2125 One could argue that this fact disqualifies my reading of the
2126 documentation.
2127 If I would have installed nmh from source back then, I could agree.
2128 Yet I had used a prepackaged version and had expected that it would
2129 just work.
2133 .H1 "Code Style
2134 .P
2135 foo
2138 .H2 "Standard Code
2139 .P
2140 POSIX
2142 .U3 "Converting to Standard Code
2143 .P
2144 One part of this task was converting obsolete code constructs
2145 to standard constructs.
2146 As I'm not even thirty years old and have no more than seven years of
2147 Unix experience, I needed to learn about the history in retrospective.
2148 Older people likely have used those ancient constructs themselves
2149 and have suffered from their incompatibilities and have longed for
2150 standardization.
2151 Unfortunately, I have only read that others had done so.
2152 This put me in a much more difficult positions when working on the old
2153 code.
2154 I needed to recherche what other would have known by heart from
2155 experience.
2156 All my programming experience comes from a time past ANSI C
2157 and past POSIX.
2158 Although I knew about the times before, I took the
2159 current state implicitly for granted most of the time.
2160 .P
2161 Being aware of
2162 these facts, I rather let people with more historic experience solve the
2163 task of converting the ancient code constructs to standardized ones.
2164 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
2165 He converted large parts of the code to POSIX constructs, removing
2166 the conditionals compilation for now standardized features.
2167 I'm thankful for this task being solved.
2168 I only pulled the changes into
2169 mmh.
2174 .H2 "Separation
2176 .U2 "MH Directory Split
2177 .P
2178 In MH and nmh, a personal setup had consisted of two parts:
2179 The MH profile, named
2180 .Fn \&.mh_profile
2181 and being located directly in the user's home directory.
2182 And the MH directory, where all his mail messages and also his personal
2183 forms, scan formats, other configuration files are stored.
2184 The location
2185 of this directory could be user-chosen.
2186 The default was to name it
2187 .Fn Mail
2188 and have it directly in the home directory.
2189 .P
2190 I've never liked the data storage and the configuration to be intermixed.
2191 They are different kinds of data.
2192 One part, are the messages,
2193 which are the data to operate on.
2194 The other part, are the personal
2195 configuration files, which are able to change the behavior of the operations.
2196 The actual operations are defined in the profile, however.
2197 .P
2198 When storing data, one should try to group data by its type.
2199 There's sense in the Unix file system hierarchy, where configuration
2200 file are stored separate (\c
2201 .Fn /etc )
2202 to the programs (\c
2203 .Fn /bin
2204 and
2205 .Fn /usr/bin )
2206 to their sources (\c
2207 .Fn /usr/src ).
2208 Such separation eases the backup management, for instance.
2209 .P
2210 In mmh, I've reorganized the file locations.
2211 Still there are two places:
2212 There's the mail storage directory, which, like in MH, contains all the
2213 messages, but, unlike in MH, nothing else.
2214 Its location still is user-chosen, with the default name
2215 .Fn Mail ,
2216 in the user's home directory.
2217 This is much similar to the case in nmh.
2218 The configuration files, however, are grouped together in the new directory
2219 .Fn \&.mmh
2220 in the user's home directory.
2221 The user's profile now is a file, named
2222 .Fn profile ,
2223 in this mmh directory.
2224 Consistently, the context file and all the personal forms, scan formats,
2225 and the like, are also there.
2226 .P
2227 The naming changed with the relocation.
2228 The directory where everything, except the profile, had been stored (\c
2229 .Fn $HOME/Mail ),
2230 used to be called \fIMH directory\fP.
2231 Now, this directory is called the
2232 user's \fImail storage\fP.
2233 The name \fImmh directory\fP is now given to
2234 the new directory
2235 (\c
2236 .Fn $HOME/.mmh ),
2237 containing all the personal configuration files.
2238 .P
2239 The separation of the files by type of content is logical and convenient.
2240 There are no functional differences as any possible setup known to me
2241 can be implemented with both approaches, although likely a bit easier
2242 with the new approach.
2243 The main goal of the change had been to provide
2244 sensible storage locations for any type of personal mmh file.
2245 .P
2246 In order for one user to have multiple MH setups, he can use the
2247 environment variable
2248 .Ev MH
2249 the point to a different profile file.
2250 The MH directory (mail storage plus personal configuration files) is
2251 defined by the
2252 .Pe Path
2253 profile entry.
2254 The context file could be defined by the
2255 .Pe context
2256 profile entry or by the
2257 .Ev MHCONTEXT
2258 environment variable.
2259 The latter is useful to have a distinct context (e.g. current folders)
2260 in each terminal window, for instance.
2261 In mmh, there are three environment variables now.
2262 .Ev MMH
2263 may be used to change the location of the mmh directory.
2264 .Ev MMHP
2265 and
2266 .Ev MMHC
2267 change the profile and context files, respectively.
2268 Besides providing a more consistent feel (which simply is the result
2269 of being designed anew), the set of personal configuration files can
2270 be chosen independently from the profile (including mail storage location)
2271 and context, now.
2272 Being it relevant for practical use or not, it
2273 de-facto is an improvement.
2274 However, the main achievement is the
2275 split between mail storage and personal configuration files.
2278 .H2 "Modularization
2279 .P
2280 whatnowproc
2281 .P
2282 The \fIMH library\fP
2283 .Fn libmh.a
2284 collects a bunch of standard functions that many of the MH tools need,
2285 like reading the profile or context files.
2286 This doesn't hurt the separation.
2289 .H2 "Style
2290 .P
2291 Code layout, goto, ...
2293 .P
2294 anno rework
2299 .H1 "Concept Exploitation/Homogeneity
2302 .H2 "Draft Folder
2303 .P
2304 Historically, MH provided exactly one draft message, named
2305 .Fn draft
2306 and
2307 being located in the MH directory.
2308 When starting to compose another message
2309 before the former one was sent, the user had been questioned whether to use,
2310 refile or replace the old draft.
2311 Working on multiple drafts at the same time
2312 was impossible.
2313 One could only work on them in alteration by refiling the
2314 previous one to some directory and fetching some other one for reediting.
2315 This manual draft management needed to be done each time the user wanted
2316 to switch between editing one draft to editing another.
2317 .P
2318 To allow true parallel editing of drafts, in a straight forward way, the
2319 draft folder facility exists.
2320 It had been introduced already in July 1984
2321 by Marshall T. Rose.
2322 The facility was deactivated by default.
2323 Even in nmh, the draft folder facility remained deactivated by default.
2324 At least, Richard Coleman added the man page
2325 .Mp mh-draft(5)
2326 to document
2327 the feature well.
2328 .P
2329 The only advantage of not using the draft folder facility is the static
2330 name of the draft file.
2331 This could be an issue for MH front-ends like mh-e.
2332 But as they likely want to provide working on multiple drafts in parallel,
2333 the issue is only concerning compatibility.
2334 The aim of nmh to stay compatible
2335 prevented the default activation of the draft folder facility.
2336 .P
2337 On the other hand, a draft folder is the much more natural concept than
2338 a draft message.
2339 MH's mail storage consists of folders and messages,
2340 the messages named with ascending numbers.
2341 A draft message breaks with this
2342 concept by introducing a message in a file named
2343 .Fn draft .
2344 This draft
2345 message is special.
2346 It can not be simply listed with the available tools,
2347 but instead requires special switches.
2348 I.e. corner-cases were
2349 introduced.
2350 A draft folder, in contrast, does not introduce such
2351 corner-cases.
2352 The available tools can operate on the messages within that
2353 folder like on any messages within any mail folders.
2354 The only difference
2355 is the fact that the default folder for
2356 .Pn send
2357 is the draft folder,
2358 instead of the current folder, like for all other tools.
2359 .P
2360 The trivial part of the change was activating the draft folder facility
2361 by default and setting a default name for this folder.
2362 Obviously, I chose
2363 the name
2364 .Fn +drafts .
2365 This made the
2366 .Sw -draftfolder
2367 and
2368 .Sw -draftmessage
2369 switches useless, and I could remove them.
2370 The more difficult but also the part that showed the real improvement,
2371 was updating the tools to the new concept.
2372 .Sw -draft
2373 switches could
2374 be dropped, as operating on a draft message became indistinguishable to
2375 operating on any other message for the tools.
2376 .Pn comp
2377 still has its
2378 .Sw -use
2379 switch for switching between its two modes: (1) Compose a new
2380 draft, possibly by taking some existing message as a form.
2381 (2) Modify
2382 an existing draft.
2383 In either case, the behavior of
2384 .Pn comp is
2385 deterministic.
2386 There is no more need to query the user.
2387 I consider this
2388 a major improvement.
2389 By making
2390 .Pn send
2391 simply operate on the current
2392 message in the draft folder by default, with message and folder both
2393 overridable by specifying them on the command line, it is now possible
2394 to send a draft anywhere within the storage by simply specifying its folder
2395 and name.
2396 .P
2397 All theses changes converted special cases to regular cases, thus
2398 simplifying the tools and increasing the flexibility.
2401 .H2 "Trash Folder
2402 .P
2403 Similar to the situation for drafts is the situation for removed messages.
2404 Historically, a message was deleted by renaming.
2405 A specific
2406 \fIbackup prefix\fP, often comma (\c
2407 .Fn , )
2408 or hash (\c
2409 .Fn # ),
2410 being prepended to the file name.
2411 Thus, MH wouldn't recognize the file
2412 as a message anymore, as only files whose name consists of digits only
2413 are treated as messages.
2414 The removed messages remained as files in the
2415 same directory and needed some maintenance job to truly delete them after
2416 some grace time.
2417 Usually, by running a command similar to
2418 .VS
2419 find /home/user/Mail -ctime +7 -name ',*' | xargs rm
2420 VE
2421 in a cron job.
2422 Within the grace time interval
2423 the original message could be restored by stripping the
2424 the backup prefix from the file name.
2425 If however, the last message of
2426 a folder is been removed \(en say message
2427 .Fn 6
2428 becomes file
2429 .Fn ,6
2430 \(en and a new message enters the same folder, thus the same
2431 numbered being given again \(en in our case
2432 .Fn 6
2433 \(en, if that one
2434 is removed too, then the backup of the former message gets overwritten.
2435 Thus, the ability to restore removed messages does not only depend on
2436 the ``sweeping cron job'' but also on the removing of further messages.
2437 This is undesirable, because the real mechanism is hidden from the user
2438 and the consequences of further removals are not always obvious.
2439 Further more, the backup files are scattered within the whole mail
2440 storage, instead of being collected at one place.
2441 .P
2442 To improve the situation, the profile entry
2443 .Pe rmmproc
2444 (previously named
2445 .Pe Delete-Prog )
2446 was introduced, very early.
2447 It could be set to any command, which would care for the mail removal
2448 instead of taking the default action, described above.
2449 Refiling the to-be-removed files to some garbage folder was a common
2450 example.
2451 Nmh's man page
2452 .Mp rmm(1)
2453 proposes
2454 .Cl "refile +d
2455 to move messages to the garbage folder and
2456 .Cl "rm `mhpath +d all`
2457 the empty the garbage folder.
2458 Managing the message removal this way is a sane approach.
2459 It keeps
2460 the removed messages in one place, makes it easy to remove the backup
2461 files, and, most important, enables the user to use the tools of MH
2462 itself to operate on the removed messages.
2463 One can
2464 .Pn scan
2465 them,
2466 .Pn show
2467 them, and restore them with
2468 .Pn refile .
2469 There's no more
2470 need to use
2471 .Pn mhpath
2472 to switch over from MH tools to Unix tools \(en MH can do it all itself.
2473 .P
2474 This approach matches perfect with the concepts of MH, thus making
2475 it powerful.
2476 Hence, I made it the default.
2477 And even more, I also
2478 removed the old backup prefix approach, as it is clearly less powerful.
2479 Keeping unused alternative in the code is a bad choice as they likely
2480 gather bugs, by not being constantly tested.
2481 Also, the increased code
2482 size and more conditions crease the maintenance costs.
2483 By strictly
2484 converting to the trash folder approach, I simplified the code base.
2485 .Pn rmm
2486 calls
2487 .Pn refile
2488 internally to move the to-be-removed
2489 message to the trash folder (\c
2490 .Fn +trash
2491 by default).
2492 Messages
2493 there can be operated on like on any other message in the storage.
2494 The sweep clean, one can use
2495 .Cl "rmm -unlink +trash a" ,
2496 where the
2497 .Sw -unlink
2498 switch causes the files to be truly unliked instead
2499 of moved to the trash folder.
2502 .H2 "Path Notations
2503 .P
2504 foo
2507 .H2 "MIME Integration
2508 .P
2509 user-visible access to whole messages and MIME parts are inherently
2510 different
2513 .H2 "Of One Cast
2514 .P