docs/master
view ch03.roff @ 102:a782488c85f5
More text about attachments mainly, plus some rearrangements.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Wed, 20 Jun 2012 17:57:37 +0200 |
| parents | e8e6adb14beb |
| children | 2818ca27d24c |
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 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 focus 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 "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 initiated the development of mmh.
60 Removing the mail transfer facilities had been the first work task
61 in the mmh project.
62 .P
63 The Mail Submission Agent (MSA) is called
64 \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 appears to be the better interface.
99 .\" XXX implement it
100 .P
101 To retrieve mail, the
102 .Pn inc
103 command acted as Mail Retrieval Agent (MRA).
104 It established network connections
105 and spoke POP3 to retrieve mail from remote servers.
106 As with mail submission, the network connections required encryption and
107 authentication, thus TLS and SASL were added.
108 Support for message retrieval through IMAP will become necessary
109 to be added soon, too, and likewise for any other changes in mail transfer.
110 Not so for mmh because it has dropped the support for retrieving mail
111 from remote locations.
112 .Ci ab7b48411962d26439f92f35ed084d3d6275459c
113 Instead, it depends on an external tool to cover this task.
114 In mmh exist two paths for messages to enter mmh's mail storage:
115 (1) Mail can be incorporated with
116 .Pn inc
117 from the system maildrop, or (2) with
118 .Pn rcvstore
119 by reading them, one at a time, from the standard input.
120 .P
121 With the removal of the MSA and MRA, mmh converted from an all-in-one
122 mail system to being a MUA only.
123 Now, of course, mmh depends on third-party software.
124 An external MSA is required to transfer mail to the outside world;
125 an external MRA is required to retrieve mail from remote machines.
126 There exist excellent implementations of such software,
127 which do this specific task likely better than the internal
128 versions had done it.
129 Also, the best suiting programs can be freely chosen.
130 .P
131 As it had already been possible to use an external MSA or MRA,
132 why not keep the internal version for convenience?
133 The question whether there is sense in having a fall-back pager in all
134 the command line tools, for the cases when
135 .Pn more
136 or
137 .Pn less
138 aren't available, appears to be ridiculous.
139 Of course, MSAs and MRAs are more complex than text pagers
140 and not necessarily available but still the concept of orthogonal
141 design holds: ``Write programs that do one thing and do it well.''
142 .[
143 mcilroy unix phil
144 p. 53
145 .]
146 .[
147 mcilroy bstj foreword
148 .]
149 Here, this part of the Unix philosophy was applied not only
150 to the programs but to the project itself.
151 In other words:
152 ``Develop projects that focus on one thing and do it well.''
153 Projects grown complex should be split for the same reasons programs grown
154 complex should be split.
155 If it is conceptionally more elegant to have the MSA and MRA as
156 separate projects then they should be separated.
157 This is the case here, in my opinion.
158 The RFCs propose this separation by clearly distinguishing the different
159 mail handling tasks.
160 .[
161 rfc 821
162 .]
163 The small interfaces between the mail agents support the separation.
164 .P
165 In the beginning, email had been small and simple.
166 At that time,
167 .Pn /bin/mail
168 had covered anything there was to email and still had been small
169 and simple.
170 Later, the essential complexity of email increased.
171 (Essential complexity is the complexity defined by the problem itself.\0
172 .[[
173 brooks no silver bullet
174 .]])
175 Email systems reacted to this change: They grew.
176 RFCs started to introduce the concept of mail agents to separate the
177 various tasks because they became more extensive and new tasks appeared.
178 As the mail systems grew even more, parts were split off.
179 In nmh, for instance, the POP server, which was included in the original
180 MH, was removed.
181 Now is the time to go one step further and split the MSA and MRA off, too.
182 Not only does this decrease the code size of the project,
183 but, more important, it unburdens mmh of the whole field of
184 message transfer with all its implications for the project.
185 There is no more need to concern with changes in network transfer.
186 This independence is received by depending on an external program
187 that covers the field.
188 Today, this is a reasonable exchange.
189 .P
190 Functionality can be added in three different ways:
191 .BU
192 Implementing the function originally in the project.
193 .BU
194 Depending on a library that provides the function.
195 .BU
196 Depending on a program that provides the function.
197 .P
198 Whereas adding the function originally to the project increases the
199 code size most and requires most maintenance and development work,
200 it makes the project most independent of other software.
201 Using libraries or external programs require less maintenance work
202 but introduces dependencies on external software.
203 Programs have the smallest interfaces and provide the best separation
204 but possibly limit the information exchange.
205 External libraries are stronger connected than external programs,
206 thus information can be exchanged more flexible.
207 Adding code to a project increases maintenance work.
208 .\" XXX ref
209 Implementing complex functions originally in the project adds
210 a lot of code.
211 This should be avoided if possible.
212 Hence, the dependencies only change in kind, not in their existence.
213 In mmh, library dependencies on
214 .Pn libsasl2
215 and
216 .Pn libcrypto /\c
217 .Pn libssl
218 were treated against program dependencies on an MSA and an MRA.
219 This also meant treating build-time dependencies against run-time
220 dependencies.
221 Besides program dependencies providing the stronger separation
222 and being more flexible, they also allowed
223 over 6\|000 lines of code to be removed from mmh.
224 This made mmh's code base about 12\|% smaller.
225 Reducing the project's code size by such an amount without actually
226 losing functionality is a convincing argument.
227 Actually, as external MSAs and MRAs are likely superior to the
228 project's internal versions, the common user even gains functionality.
229 .P
230 Users of MH should not have problems to set up an external MSA and MRA.
231 Also, the popular MSAs and MRAs have large communities and a lot
232 of documentation available.
233 Choices for MSAs range from full-featured MTAs like
234 .I Postfix
235 over mid-size MTAs like
236 .I masqmail
237 and
238 .I dma
239 to small forwarders like
240 .I ssmtp
241 and
242 .I nullmailer .
243 Choices for MRAs include
244 .I fetchmail ,
245 .I getmail ,
246 .I mpop
247 and
248 .I fdm .
251 .H2 "Non-MUA Tools
252 .P
253 One goal of mmh is to remove the tools that are not part of the MUA's task.
254 Further more, any tools that don't improve the MUA's job significantly
255 should be removed.
256 Loosely related and rarely used tools distract from the lean appearance.
257 They require maintenance work without adding much to the core task.
258 By removing these tools, the project shall become more stream-lined
259 and focused.
260 In mmh the following tools are not available anymore:
261 .BU
262 .Pn conflict
263 was removed
264 .Ci 8b235097cbd11d728c07b966cf131aa7133ce5a9
265 because it is a mail system maintenance tool that is not MUA-related.
266 It even checked
267 .Fn /etc/passwd
268 and
269 .Fn /etc/group
270 for consistency, which is completely unrelated to email.
271 A tool like
272 .Pn conflict
273 is surely useful, but it should not be shipped with mmh.
274 .\" XXX historic reasons?
275 .BU
276 .Pn rcvtty
277 was removed
278 .Ci 14767c94b3827be7c867196467ed7aea5f6f49b0
279 because its use case of writing to the user's terminal
280 on receiving of mail is obsolete.
281 If users like to be informed of new mail, the shell's
282 .Ev MAILPATH
283 variable or graphical notifications are technically more appealing.
284 Writing directly to terminals is hardly ever wanted today.
285 If though one wants to have it this way, the standard tool
286 .Pn write
287 can be used in a way similar to:
288 .VS
289 scan -file - | write `id -un`
290 VE
291 .BU
292 .Pn viamail
293 was removed
294 .Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932
295 when the new attachment system was activated, because
296 .Pn forw
297 could then cover the task itself.
298 The program
299 .Pn sendfiles
300 was rewritten as a shell script wrapper around
301 .Pn forw .
302 .Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6
303 .BU
304 .Pn msgchk
305 was removed
306 .Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe ,
307 because it lost its use case when POP support was removed.
308 A call to
309 .Pn msgchk
310 provided hardly more information than:
311 .VS
312 ls -l /var/mail/meillo
313 VE
314 It did distinguish between old and new mail, but
315 this detail information can be retrieved with
316 .Pn stat (1),
317 too.
318 A small shell script could be written to print the information
319 in a similar way, if truly necessary.
320 As mmh's
321 .Pn inc
322 only incorporates mail from the user's local maildrop,
323 and thus no data transfers over slow networks are involved,
324 there's hardly any need to check for new mail before incorporating it.
325 .BU
326 .Pn msh
327 was removed
328 .Ci 916690191222433a6923a4be54b0d8f6ac01bd02
329 because the tool was in conflict with the philosophy of MH.
330 It provided an interactive shell to access the features of MH,
331 but it wasn't just a shell, tailored to the needs of mail handling.
332 Instead it was one large program that had several MH tools built in.
333 This conflicts with the major feature of MH of being a tool chest.
334 .Pn msh 's
335 main use case had been accessing Bulletin Boards, which have seized to
336 be popular.
337 .P
338 Removing
339 .Pn msh ,
340 together with the truly archaic code relicts
341 .Pn vmh
342 and
343 .Pn wmh ,
344 saved more than 7\|000 lines of C code \(en
345 about 15\|% of the project's original source code amount.
346 Having less code \(en with equal readability, of course \(en
347 for the same functionality is an advantage.
348 Less code means less bugs and less maintenance work.
349 As
350 .Pn rcvtty
351 and
352 .Pn msgchk
353 are assumed to be rarely used and can be implemented in different ways,
354 why should one keep them?
355 Removing them stream-lines mmh.
356 .Pn viamail 's
357 use case is now partly obsolete and partly covered by
358 .Pn forw ,
359 hence there's no reason to still maintain it.
360 .Pn conflict
361 is not related to the mail client, and
362 .Pn msh
363 conflicts with the basic concept of MH.
364 Theses two tools might still be useful, but they should not be part of mmh.
365 .P
366 Finally, there's
367 .Pn slocal .
368 .Pn slocal
369 is an MDA and thus not directly MUA-related.
370 It should be removed from mmh, because including it conflicts with
371 the idea that mmh is a MUA only.
372 .Pn slocal
373 should rather become a separate project.
374 However,
375 .Pn slocal
376 provides rule-based processing of messages, like filing them into
377 different folders, which is otherwise not available in mmh.
378 Although
379 .Pn slocal
380 does neither pull in dependencies nor does it include a separate
381 technical area (cf. Sec. XXX), still,
382 it accounts for about 1\|000 lines of code that need to be maintained.
383 As
384 .Pn slocal
385 is almost self-standing, it should be split off into a separate project.
386 This would cut the strong connection between the MUA mmh and the MDA
387 .Pn slocal .
388 For anyone not using MH,
389 .Pn slocal
390 would become yet another independent MDA, like
391 .I procmail .
392 Then
393 .Pn slocal
394 could be installed without the complete MH system.
395 Likewise, mmh users could decide to use
396 .I procmail
397 without having a second, unused MDA,
398 .Pn slocal ,
399 installed.
400 That appears to be conceptionally the best solution.
401 Yet,
402 .Pn slocal
403 is not split off.
404 I defer the decision over
405 .Pn slocal
406 in need for deeper investigation.
407 In the meanwhile, it remains part of mmh.
408 That does not hurt because
409 .Pn slocal
410 is unrelated to the rest of the project.
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 parts are not
424 directly displayable and text content might be encoded in
425 foreign charsets.
426 .Pn show 's
427 understanding of messages and
428 .Pn mhl 's
429 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 is 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 "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 more complex 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
602 defined the default transport service, either
603 .Ar smtp
604 or
605 .Ar sendmail .
606 In mmh this fixed to
607 .Ar sendmail .
608 .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
609 With
610 .Sw --with-smtpservers
611 default SMTP servers for the
612 .Ar smtp
613 transport service could be specified.
614 .Ci 128545e06224233b7e91fc4c83f8830252fe16c9
615 Both of them became irrelevant.
617 .U3 "Backup Prefix
618 .P
619 The backup prefix is the string that was prepended to message
620 filenames to tag them as deleted.
621 By default it had been the comma character `\f(CW,\fP'.
622 In July 2000, Kimmo Suominen introduced
623 the configure option
624 .Sw --with-hash-backup
625 to change the default to the hash symbol `\f(CW#\fP'.
626 The choice was probably personal preference, because first, the
627 option was named
628 .Sw --with-backup-prefix.
629 and had the prefix symbol as argument.
630 But giving the hash symbol as argument caused too many problems
631 for Autoconf,
632 thus the option was limited to use the hash symbol as the default prefix.
633 This supports the assumption, that the choice for the hash was
634 personal preference only.
635 Being related or not, words that start with the hash symbol
636 introduce a comment in the Unix shell.
637 Thus, the command line
638 .Cl "rm #13 #15
639 calls
640 .Pn rm
641 without arguments because the first hash symbol starts the comment
642 that reaches until the end of the line.
643 To delete the backup files,
644 .Cl "rm ./#13 ./#15"
645 needs to be used.
646 Using the hash as backup prefix can be seen as a precaution against
647 data loss.
648 .P
649 I removed the configure option but added the profile entry
650 .Pe backup-prefix ,
651 which allows to specify an arbitrary string as backup prefix.
652 .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
653 Profile entries are the common method to change mmh's behavior.
654 This change did not remove the choice but moved it to a location where
655 it suited better.
656 .P
657 Eventually, however, the new trash folder concept
658 .Cf "Sec. XXX
659 obsoleted the concept of the backup prefix completely.
660 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
661 .\" (Well, there still are corner-cases to remove until the backup
662 .\" prefix can be laid to rest, eventually.)
663 .\" FIXME: Do this work in the code!
665 .U3 "Editor and Pager
666 .P
667 The two configure options
668 .CW --with-editor=EDITOR
669 .CW --with-pager=PAGER
670 were used to specify the default editor and pager at configure time.
671 Doing so at configure time made sense in the Eighties,
672 when the set of available editors and pagers varied much across
673 different systems.
674 Today, the situation is more homogeneous.
675 The programs
676 .Pn vi
677 and
678 .Pn more
679 can be expected to be available on every Unix system,
680 as they are specified by POSIX since two decades.
681 (The specifications for
682 .Pn vi
683 and
684 .Pn more
685 appeared in
686 .[
687 posix 1987
688 .]
689 and,
690 .[
691 posix 1992
692 .]
693 respectively.)
694 As a first step, these two tools were hard-coded as defaults.
695 .Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f
696 Not changed were the
697 .Pe editor
698 and
699 .Pe moreproc
700 profile entries, which allowed the user to override the system defaults.
701 Later, the concept was reworked to respect the standard environment
702 variables
703 .Ev VISUAL
704 and
705 .Ev PAGER
706 if they are set.
707 Today, mmh determines the editor to use in the following order,
708 taking the first available and non-empty item:
709 .IP (1)
710 Environment variable
711 .Ev MMHEDITOR
712 .IP (2)
713 Profile entry
714 .Pe Editor
715 .IP (3)
716 Environment variable
717 .Ev VISUAL
718 .IP (4)
719 Environment variable
720 .Ev EDITOR
721 .IP (5)
722 Command
723 .Pn vi .
724 .P
725 .Ci f85f4b7ae62e3d05a945dcd46ead51f0a2a89a9b
726 .P
727 The pager to use is determined in a similar order,
728 also taking the first available and non-empty item:
729 .IP (1)
730 Environment variable
731 .Ev MMHPAGER
732 .IP (2)
733 Profile entry
734 .Pe Pager
735 (replaces
736 .Pe moreproc )
737 .IP (3)
738 Environment variable
739 .Ev PAGER
740 .IP (4)
741 Command
742 .Pn more .
743 .P
744 .Ci 0c4214ea2aec6497d0d67b436bbee9bc1d225f1e
745 .P
746 By respecting the
747 .Ev VISUAL /\c
748 .Ev EDITOR
749 and
750 .Ev PAGER
751 environment variables,
752 the new behavior confirms better to the common style on Unix systems.
753 Additionally, the new approach is more uniform and clearer to users.
756 .U3 "ndbm
757 .P
758 .Pn slocal
759 used to depend on
760 .I ndbm ,
761 a database library.
762 The database is used to store the `\fLMessage-ID\fP's of all
763 messages delivered.
764 This enables
765 .Pn slocal
766 to suppress delivering the same message to the same user twice.
767 (This features was enabled by the
768 .Sw -suppressdup
769 switch.)
770 .P
771 A variety of versions of the database library exist.
772 .[
773 wolter unix incompat notes dbm
774 .]
775 Complicated autoconf code was needed to detect them correctly.
776 Further more, the configure switches
777 .Sw --with-ndbm=ARG
778 and
779 .Sw --with-ndbmheader=ARG
780 were added to help with difficult setups that would
781 not be detected automatically or correctly.
782 .P
783 By removing the suppress duplicates feature of
784 .Pn slocal ,
785 the dependency on
786 .I ndbm
787 vanished and 120 lines of complex autoconf code could be saved.
788 .Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
789 The change removed functionality too, but that is minor to the
790 improvement by dropping the dependency and the complex autoconf code.
792 .U3 "mh-e Support
793 .P
794 The configure option
795 .Sw --disable-mhe
796 was removed when the mh-e support was reworked.
797 Mh-e is the Emacs front-end to MH.
798 It requires MH to provide minor additional functions.
799 The
800 .Sw --disable-mhe
801 configure option could switch these extensions off.
802 After removing the support for old versions of mh-e,
803 only the
804 .Sw -build
805 switches of
806 .Pn forw
807 and
808 .Pn repl
809 are left to be mh-e extensions.
810 They are now always built in because they add little code and complexity.
811 In consequence, the
812 .Sw --disable-mhe
813 configure option was removed
814 .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
815 Removing the option removed a second code setup that would have
816 needed to be tested.
817 This change was first done in nmh and thereafter merged into mmh.
818 .P
819 The interface changes in mmh require mh-e to be adjusted in order
820 to be able to use mmh as back-end.
821 This will require minor changes to mh-e, but removing the
822 .Sw -build
823 switches would require more rework.
825 .U3 "Masquerading
826 .P
827 The configure option
828 .Sw --enable-masquerade
829 could take up to three arguments:
830 `draft_from', `mmailid', and `username_extension'.
831 They activated different types of address masquerading.
832 All of them were implemented in the SMTP-speaking
833 .Pn post
834 command, which provided an MSA.
835 Address masquerading is an MTA's task and mmh does not cover
836 this field anymore.
837 Hence, true masquerading needs to be implemented in the external MTA.
838 .P
839 The
840 .I mmailid
841 masquerading type is the oldest one of the three and the only one
842 available in the original MH.
843 It provided a
844 .I username
845 to
846 .I fakeusername
847 mapping, based on the password file's GECOS field.
848 The man page
849 .Mp mh-tailor(5)
850 described the use case as being the following:
851 .QS
852 This is useful if you want the messages you send to always
853 appear to come from the name of an MTA alias rather than your
854 actual account name. For instance, many organizations set up
855 `First.Last' sendmail aliases for all users. If this is
856 the case, the GECOS field for each user should look like:
857 ``First [Middle] Last <First.Last>''
858 .QE
859 .P
860 As mmh sends outgoing mail via the local MTA only,
861 the best location to do such global rewrites is there.
862 Besides, the MTA is conceptionally the right location because it
863 does the reverse mapping for incoming mail (aliasing), too.
864 Further more, masquerading set up there is readily available for all
865 mail software on the system.
866 Hence, mmailid masquerading was removed.
867 .Ci 0836c8000ccb34b59410ef1c15b1b7feac70ce5f
868 .P
869 The
870 .I username_extension
871 masquerading type did not replace the username but would append a suffix,
872 specified by the
873 .Ev USERNAME_EXTENSION
874 environment variable, to it.
875 This provided support for the
876 .I user-extension
877 feature of qmail and the similar
878 .I "plussed user
879 processing of sendmail.
880 The decision to remove this username_extension masquerading was
881 motivated by the fact that
882 .Pn spost
883 hadn't supported it already.
884 .Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
885 Username extensions are possible in mmh, but less convenient to use.
886 .\" XXX format file %(getenv USERNAME_EXTENSION)
887 .P
888 The
889 .I draft_from
890 masquerading type instructed
891 .Pn post
892 to use the value of the
893 .Hd From
894 header field as SMTP envelope sender.
895 Sender addresses could be replaced completely.
896 .Ci b14ea6073f77b4359aaf3fddd0e105989db9
897 Mmh offers a kind of masquerading similar in effect, but
898 with technical differences.
899 As mmh does not transfer messages itself, the local MTA has final control
900 over the sender's address. Any masquerading mmh introduces may be reverted
901 by the MTA.
902 In times of pedantic spam checking, an MTA will take care to use
903 sensible envelope sender addresses to keep its own reputation up.
904 Nonetheless, the MUA can set the
905 .Hd From
906 header field and thereby propose
907 a sender address to the MTA.
908 The MTA may then decide to take that one or generate the canonical sender
909 address for use as envelope sender address.
910 .P
911 In mmh, the MTA will always extract the recipient and sender from the
912 message header (\c
913 .Pn sendmail 's
914 .Sw -t
915 switch).
916 The
917 .Hd From
918 header field of the draft may be set arbitrary by the user.
919 If it is missing, the canonical sender address will be generated by the MTA.
921 .U3 "Remaining Options
922 .P
923 Two configure options remain in mmh.
924 One is the locking method to use:
925 .Sw --with-locking=[dot|fcntl|flock|lockf] .
926 The idea of removing all methods except the portable dot locking
927 and having that one as the default is appealing, but this change
928 requires deeper technical investigation into the topic.
929 The other option,
930 .Sw --enable-debug ,
931 compiles the programs with debugging symbols and does not strip them.
932 This option is likely to stay.
937 .H2 "Command Line Switches
938 .P
939 The command line switches of MH tools follow the X Window style.
940 They are words, introduced by a single dash.
941 For example:
942 .Cl "-truncate" .
943 Every program in mmh has two generic switches:
944 .Sw -help ,
945 to print a short message on how to use the program, and
946 .Sw -Version ,
947 to tell what version of mmh the program belongs to.
948 .P
949 Switches change the behavior of programs.
950 Programs that do one thing in one way require no switches.
951 In most cases, doing something in exactly one way is too limiting.
952 If there is basically one task to accomplish, but it should be done
953 in various ways, switches are a good approach to alter the behavior
954 of a program.
955 Changing the behavior of programs provides flexibility and customization
956 to users, but at the same time it complicates the code, documentation and
957 usage of the program.
958 .\" XXX: Ref
959 Therefore, the number of switches should be kept small.
960 A small set of well-chosen switches does no harm.
961 But usually, the number of switches increases over time.
962 Already in 1985, Rose and Romine have identified this as a major
963 problem of MH:
964 .[ [
965 rose romine real work
966 .], p. 12]
967 .QS
968 A complaint often heard about systems which undergo substantial development
969 by many people over a number of years, is that more and more options are
970 introduced which add little to the functionality but greatly increase the
971 amount of information a user needs to know in order to get useful work done.
972 This is usually referred to as creeping featurism.
973 .QP
974 Unfortunately MH, having undergone six years of off-and-on development by
975 ten or so well-meaning programmers (the present authors included),
976 suffers mightily from this.
977 .QE
978 .P
979 Being reluctant to adding new switches \(en or `options',
980 as Rose and Romine call them \(en is one part of a counter-action,
981 the other part is removing hardly used switches.
982 Nmh's tools had lots of switches already implemented,
983 hence, cleaning up by removing some of them was the more important part
984 of the counter-action.
985 Removing existing functionality is always difficult because it
986 breaks programs that use these functions.
987 Also, for every obsolete feature, there'll always be someone who still
988 uses it and thus opposes its removal.
989 This puts the developer into the position,
990 where sensible improvements to style are regarded as destructive acts.
991 Yet, living with the featurism is far worse, in my eyes, because
992 future needs will demand adding further features,
993 worsening the situation more and more.
994 Rose and Romine added in a footnote,
995 ``[...]
996 .Pn send
997 will no doubt acquire an endless number of switches in the years to come.''
998 Although clearly humorous, the comment points to the nature of the problem.
999 Refusing to add any new switches would encounter the problem at its root,
1000 but this is not practical.
1001 New needs will require new switches and it would be unwise to block
1002 them strictly.
1003 Nevertheless, removing obsolete switches still is an effective approach
1004 to deal with the problem.
1005 Working on an experimental branch without an established user base,
1006 eased my work because I did not offend users when I removed existing
1007 funtions.
1008 .P
1009 Rose and Romine counted 24 visible and 9 more hidden switches for
1010 .Pn send .
1011 In nmh, they increased up to 32 visible and 12 hidden ones.
1012 At the time of writing, no more than 7 visible switches and 1 hidden switch
1013 have remained in mmh's
1014 .Pn send .
1015 (These numbers include two generic switches, help and version.)
1016 .P
1017 Fig. XXX
1018 .\" XXX Ref
1019 displays the number of switches for each of the tools that is available
1020 in both, nmh and mmh.
1021 The tools are sorted by the number of switches they had in nmh.
1022 Visible and hidden switches were counted,
1023 but not the generic help and version switches.
1024 Whereas in the beginning of the project, the average tool had 11 switches,
1025 now it has no more than 5 \(en only half as many.
1026 If the `no' switches and similar inverse variant are folded onto
1027 their counter-parts, the average tool had 8 switches in pre-mmh times and
1028 has 4 now.
1029 The total number of functional switches in mmh dropped from 465
1030 to 234.
1032 .KS
1033 .in 1c
1034 .so input/switches.grap
1035 .KE
1037 .P
1038 A part of the switches vanished after functions were removed.
1039 This was the case for network mail transfer, for instance.
1040 Sometimes, however, the work flow was the other way:
1041 I looked through the
1042 .Mp mh-chart (7)
1043 man page to identify the tools with apparently too many switches.
1044 Then considering the value of each of the switches by examining
1045 the tool's man page and source code, aided by recherche and testing.
1046 This way, the removal of functions was suggested by the aim to reduce
1047 the number of switches per command.
1050 .U3 "Draft Folder Facility
1051 .P
1052 A change early in the project was the complete transition from
1053 the single draft message to the draft folder facility.
1054 .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
1055 The draft folder facility was introduced in the mid-Eighties, when
1056 Rose and Romine called it a ``relatively new feature''.
1057 .[
1058 rose romine real work
1059 .]
1060 Since then, the facility had existed but was deactivated by default.
1061 The default activation and the related rework of the tools made it
1062 possible to remove the
1063 .Sw -[no]draftfolder ,
1064 and
1065 .Sw -draftmessage
1066 switches from
1067 .Pn comp ,
1068 .Pn repl ,
1069 .Pn forw ,
1070 .Pn dist ,
1071 .Pn whatnow ,
1072 and
1073 .Pn send .
1074 .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
1075 The only flexibility removed with this change is having multiple
1076 draft folders within one profile.
1077 I consider this a theoretical problem only.
1078 In the same go, the
1079 .Sw -draft
1080 switch of
1081 .Pn anno ,
1082 .Pn refile ,
1083 and
1084 .Pn send
1085 was removed.
1086 The special-casing of `the' draft message became irrelevant after
1087 the rework of the draft system.
1088 (See Sec. XXX.)
1089 Equally,
1090 .Pn comp
1091 lost its
1092 .Sw -file
1093 switch.
1094 The draft folder facility, together with the
1095 .Sw -form
1096 switch, are sufficient.
1099 .U3 "In Place Editing
1100 .P
1101 .Pn anno
1102 had the switches
1103 .Sw -[no]inplace
1104 to either annotate the message in place and thus preserve hard links,
1105 or annotate a copy to replace the original message, breaking hard links.
1106 Following the assumption that linked messages should truly be the
1107 same message, and annotating it should not break the link, the
1108 .Sw -[no]inplace
1109 switches were removed and the previous default
1110 .Sw -inplace
1111 was made the only behavior.
1112 .Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0
1113 The
1114 .Sw -[no]inplace
1115 switches of
1116 .Pn repl ,
1117 .Pn forw ,
1118 and
1119 .Pn dist
1120 could be removed, too, as they were simply passed through to
1121 .Pn anno .
1122 .P
1123 .Pn burst
1124 also had
1125 .Sw -[no]inplace
1126 switches, but with different meaning.
1127 With
1128 .Sw -inplace ,
1129 the digest had been replaced by the table of contents (i.e. the
1130 introduction text) and the bursted messages were placed right
1131 after this message, renumbering all following messages.
1132 Also, any trailing text of the digest was lost, though,
1133 in practice, it usually consists of an end-of-digest marker only.
1134 Nontheless, this behavior appeared less elegant than the
1135 .Sw -noinplace
1136 behavior, which already had been the default.
1137 Nmh's
1138 .Mp burst (1)
1139 man page reads:
1140 .sp \n(PDu
1141 .QS
1142 If -noinplace is given, each digest is preserved, no table
1143 of contents is produced, and the messages contained within
1144 the digest are placed at the end of the folder. Other messages
1145 are not tampered with in any way.
1146 .QE
1147 .LP
1148 The decision to drop the
1149 .Sw -inplace
1150 behavior was supported by the code complexity and the possible data loss
1151 it caused.
1152 .Sw -noinplace
1153 was chosen to be the definitive behavior.
1154 .Ci 68a686adeb39223a5e1ad35e4a24890ec053679d
1157 .U3 "Forms and Format Strings
1158 .P
1159 Historically, the tools that had
1160 .Sw -form
1161 switches to supply a form file had
1162 .Sw -format
1163 switches as well to supply the contents of a form file as a string
1164 on the command line directly.
1165 In consequence, the following two lines equaled:
1166 .VS
1167 scan -form scan.mailx
1168 scan -format "`cat .../scan.mailx`"
1169 VE
1170 The
1171 .Sw -format
1172 switches were dropped in favor for extending the
1173 .Sw -form
1174 switches.
1175 .Ci f51956be123db66b00138f80464d06f030dbb88d
1176 If their argument starts with an equal sign (`='),
1177 then the rest of the argument is taken as a format string,
1178 otherwise the arguments is treated as the name of a format file.
1179 Thus, now the following two lines equal:
1180 .VS
1181 scan -form scan.mailx
1182 scan -form "=`cat .../scan.mailx`"
1183 VE
1184 This rework removed the prefix collision between
1185 .Sw -form
1186 and
1187 .Sw -format .
1188 Now, typing
1189 .Sw -fo
1190 suffices to specify form or format string.
1191 .P
1192 The different meaning of
1193 .Sw -format
1194 for
1195 .Pn repl
1196 and
1197 .Pn forw
1198 was removed in mmh.
1199 .Pn forw
1200 was completely switched to MIME-type forwarding, thus removing the
1201 .Sw -[no]format .
1202 .Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
1203 For
1204 .Pn repl ,
1205 the
1206 .Sw -[no]format
1207 switches were reworked to
1208 .Sw -[no]filter
1209 switches.
1210 .Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
1211 The
1212 .Sw -format
1213 switches of
1214 .Pn send
1215 and
1216 .Pn post ,
1217 which had a third meaning,
1218 were removed likewise.
1219 .Ci f3cb7cde0e6f10451b6848678d95860d512224b9
1220 Eventually, the ambiguity of the
1221 .Sw -format
1222 switches was resolved by not anymore having any such switch in mmh.
1225 .U3 "MIME Tools
1226 .P
1227 The MIME tools, which were once part of
1228 .Pn mhn
1229 [sic!],
1230 had several switches that added little practical value to the programs.
1231 The
1232 .Sw -[no]realsize
1233 switches of
1234 .Pn mhbuild
1235 and
1236 .Pn mhlist
1237 were removed, doing real size calculations always now
1238 .Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c ,
1239 as
1240 ``This provides an accurate count at the expense of a small delay.''
1241 This small delay is not noticable on modern systems.
1242 .P
1243 The
1244 .Sw -[no]check
1245 switches were removed together with the support for
1246 .Hd Content-MD5
1247 header fields.
1248 .[
1249 rfc 1864
1250 .]
1251 .Ci 31dc797eb5178970d68962ca8939da3fd9a8efda
1252 (See Sec. XXX)
1253 .P
1254 The
1255 .Sw -[no]ebcdicsafe
1256 and
1257 .Sw -[no]rfc934mode
1258 switches of
1259 .Pn mhbuild
1260 were removed because they are considered obsolete.
1261 .Ci 01a3480928da485b4d6109d36d751dfa71799d58
1262 .Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88
1263 .P
1264 Content caching of external MIME parts, activated with the
1265 .Sw -rcache
1266 and
1267 .Sw -wcache
1268 switches was completely removed.
1269 .Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269
1270 External MIME parts are rare today, having a caching facility
1271 for them is appears to be unnecessary.
1272 .P
1273 In pre-MIME times,
1274 .Pn mhl
1275 had covered many tasks that are part of MIME handling today.
1276 Therefore,
1277 .Pn mhl
1278 could be simplified to a large extend, reducing the number of its
1279 switches from 21 to 6.
1280 .Ci 350ad6d3542a07639213cf2a4fe524e829c1e7b6
1281 .Ci 0e46503be3c855bddaeae3843e1b659279c35d70
1284 .U3 "Mail Transfer Switches
1285 .P
1286 With the removal of the mail transfer facilities, a lot of switches
1287 vanished automatically.
1288 .Pn inc
1289 lost 9 switches, namely
1290 .Sw -host ,
1291 .Sw -port ,
1292 .Sw -user ,
1293 .Sw -proxy ,
1294 .Sw -snoop ,
1295 .Sw -[no]pack ,
1296 as well as
1297 .Sw -sasl
1298 and
1299 .Sw -saslmech .
1300 .Pn send
1301 and
1302 .Pn post
1303 lost 11 switches each, namely
1304 .Sw -server ,
1305 .Sw -port ,
1306 .Sw -client ,
1307 .Sw -user ,
1308 .Sw -mail ,
1309 .Sw -saml ,
1310 .Sw -send ,
1311 .Sw -soml ,
1312 .Sw -snoop ,
1313 as well as
1314 .Sw -sasl ,
1315 .Sw -saslmech ,
1316 and
1317 .Sw -tls .
1318 .Pn send
1319 had the switches only to pass them further to
1320 .Pn post ,
1321 because the user would invoke
1322 .Pn post
1323 not directly, but through
1324 .Pn send .
1325 All these switches, except
1326 .Sw -snoop
1327 were usually defined as default switches in the user's profile,
1328 but hardly given in interactive usage.
1329 .P
1330 Of course, those switches did not really ``vanish'', but the configuration
1331 they did was handed over to external MSAs and MRAs.
1332 Instead of setting up the mail transfer in mmh, it is set up in
1333 external tools.
1334 Yet, this simplifies mmh.
1335 Specialized external tools will likely have simple configuration files.
1336 Hence, instead of having one complicated central configuration file,
1337 the configuration of each domain is separate.
1338 Although the user needs to learn to configure each of the tools,
1339 each configuration is likely much simpler.
1342 .U3 "Maildrop Formats
1343 .P
1344 With the removal of MMDF maildrop format support,
1345 .Pn packf
1346 and
1347 .Pn rcvpack
1348 no longer needed their
1349 .Sw -mbox
1350 and
1351 .Sw -mmdf
1352 switches.
1353 .Sw -mbox
1354 is the sole behavior now.
1355 .Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
1356 In the same go,
1357 .Pn packf
1358 and
1359 .Pn rcvpack
1360 were reworked (see Sec. XXX) and their
1361 .Sw -file
1362 switch became unnecessary.
1363 .Ci ca1023716d4c2ab890696f3e41fa0d94267a940e
1366 .U3 "Terminal Magic
1367 .P
1368 Mmh's tools will no longer clear the screen (\c
1369 .Pn scan 's
1370 and
1371 .Pn mhl 's
1372 .Sw -[no]clear
1373 switches
1374 .Ci e57b17343dcb3ff373ef4dd089fbe778f0c7c270
1375 .Ci 943765e7ac5693ae177fd8d2b5a2440e53ce816e ).
1376 Neither will
1377 .Pn mhl
1378 ring the bell (\c
1379 .Sw -[no]bell
1380 .Ci e11983f44e59d8de236affa5b0d0d3067c192e24 )
1381 nor page the output itself (\c
1382 .Sw -length
1383 .Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ).
1384 .P
1385 Generally, the pager to use is no longer specified with the
1386 .Sw -[no]moreproc
1387 command line switches for
1388 .Pn mhl
1389 and
1390 .Pn show /\c
1391 .Pn mhshow .
1392 .Ci 39e87a75b5c2d3572ec72e717720b44af291e88a
1393 .P
1394 .Pn prompter
1395 lost its
1396 .Sw -erase
1397 and
1398 .Sw -kill
1399 switches because today the terminal cares for the line editing keys.
1402 .U3 "Header Printing
1403 .P
1404 .Pn folder 's
1405 data output is self-explaining enough that
1406 displaying the header line makes few sense.
1407 Hence, the
1408 .Sw -[no]header
1409 switch was removed and headers are never printed.
1410 .Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7
1411 .P
1412 In
1413 .Pn mhlist ,
1414 the
1415 .Sw -[no]header
1416 switches were removed, too.
1417 .Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f
1418 But in this case headers are always printed,
1419 because the output is not self-explaining.
1420 .P
1421 .Pn scan
1422 also had
1423 .Sw -[no]header
1424 switches.
1425 Printing the header had been sensible until the introduction of
1426 format strings made it impossible to display the column headings.
1427 Only the folder name and the current date remained to be printed.
1428 As this information can be perfectly retrieved by
1429 .Pn folder
1430 and
1431 .Pn date ,
1432 consequently, the switches were removed.
1433 .Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e
1434 .P
1435 By removing all
1436 .Sw -header
1437 switches, the collision with
1438 .Sw -help
1439 on the first two letters was resolved.
1440 Currently,
1441 .Sw -h
1442 evaluates to
1443 .Sw -help
1444 for all tools of mmh.
1447 .U3 "Suppressing Edits or the WhatNow Shell
1448 .P
1449 The
1450 .Sw -noedit
1451 switch of
1452 .Pn comp ,
1453 .Pn repl ,
1454 .Pn forw ,
1455 .Pn dist ,
1456 and
1457 .Pn whatnow
1458 was removed, but it can now be replaced by specifying
1459 .Sw -editor
1460 with an empty argument.
1461 .Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9
1462 (Specifying
1463 .Cl "-editor true
1464 is nearly the same, only differing by the previous editor being set.)
1465 .P
1466 The more important change is the removal of the
1467 .Sw -nowhatnowproc
1468 switch.
1469 .Ci ee4f43cf2ef0084ec698e4e87159a94c01940622
1470 This switch had introduced an awkward behavior, as explained in nmh's
1471 man page for
1472 .Mp comp (1):
1473 .QS
1474 The \-editor editor switch indicates the editor to use for
1475 the initial edit. Upon exiting from the editor, comp will
1476 invoke the whatnow program. See whatnow(1) for a discussion
1477 of available options. The invocation of this program can be
1478 inhibited by using the \-nowhatnowproc switch. (In truth of
1479 fact, it is the whatnow program which starts the initial
1480 edit. Hence, \-nowhatnowproc will prevent any edit from
1481 occurring.)
1482 .QE
1483 .P
1484 Effectively, the
1485 .Sw -nowhatnowproc
1486 switch creates only a draft message.
1487 As
1488 .Cl "-whatnowproc true
1489 causes the same behavior, the
1490 .Sw -nowhatnowproc
1491 switch was removed for being redundant.
1492 Likely, the
1493 .Sw -nowhatnowproc
1494 switch was intended to be used by front-ends.
1497 .U3 "Compatibility Switches
1498 .BU
1499 The hidden
1500 .Sw -[no]total
1501 switches of
1502 .Pn flist .
1503 They were simply the inverse of the visible
1504 .Sw -[no]fast
1505 switches:
1506 .Sw -total
1507 was
1508 .Sw -nofast
1509 and
1510 .Sw -nototal
1511 was
1512 .Sw -fast .
1513 I removed the
1514 .Sw -[no]total
1515 legacy.
1516 .Ci ea21fe2c4bd23c639bef251398fae809875732ec
1517 .BU
1518 The
1519 .Sw -subject
1520 switch of
1521 .Pn sortm
1522 existed for compatibility only.
1523 It can be fully replaced by
1524 .Cl "-textfield subject
1525 thus it was removed.
1526 .Ci 00140a3c86e9def69d98ba2ffd4d6e50ef6326ea
1529 .U3 "Various
1530 .BU
1531 In order to avoid prefix collisions among switch names, the
1532 .Sw -version
1533 switch was renamed to
1534 .Sw -Version
1535 (with capital `V').
1536 .Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a
1537 Every program has the
1538 .Sw -version
1539 switch but its first three letters collided with the
1540 .Sw -verbose
1541 switch, present in many programs.
1542 The rename solved this problem once for all.
1543 Although this rename breaks a basic interface, having the
1544 .Sw -V
1545 abbreviation to display the version information, isn't all too bad.
1546 .BU
1547 .Sw -[no]preserve
1548 of
1549 .Pn refile
1550 was removed because what use was it anyway?
1551 .QS
1552 Normally when a message is refiled, for each destination
1553 folder it is assigned the number which is one above the current
1554 highest message number in that folder. Use of the
1555 \-preserv [sic!] switch will override this message renaming, and try
1556 to preserve the number of the message. If a conflict for a
1557 particular folder occurs when using the \-preserve switch,
1558 then refile will use the next available message number which
1559 is above the message number you wish to preserve.
1560 .QE
1561 .BU
1562 The removal of the
1563 .Sw -[no]reverse
1564 switches of
1565 .Pn scan
1566 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
1567 is a bug fix, supported by the comments
1568 ``\-[no]reverse under #ifdef BERK (I really HATE this)''
1569 by Rose and
1570 ``Lists messages in reverse order with the `\-reverse' switch.
1571 This should be considered a bug.'' by Romine in the documentation.
1572 The question remains why neither Rose and Romine had fixed this
1573 bug in the Eighties when they wrote these comments nor has anyone
1574 thereafter.
1577 .ig
1579 forw: [no]dashstuffing(mhl)
1581 mhshow: [no]pause [no]serialonly
1583 mhmail: resent queued
1584 inc: snoop, (pop)
1586 mhl: [no]faceproc folder sleep
1587 [no]dashstuffing(forw) digest list volume number issue number
1589 prompter: [no]doteof
1591 refile: [no]preserve [no]unlink [no]rmmproc
1593 send: [no]forward [no]mime [no]msgid
1594 [no]push split [no]unique (sasl) width snoop [no]dashstuffing
1595 attach attachformat
1596 whatnow: (noedit) attach
1598 slocal: [no]suppressdups
1600 spost: [no]filter [no]backup width [no]push idanno
1601 [no]check(whom) whom(whom)
1603 whom: ???
1605 ..
1608 .ig
1610 .P
1611 In the best case, all switches are unambiguous on the first character,
1612 or on the three-letter prefix for the `no' variants.
1613 Reducing switch prefix collisions, shortens the necessary prefix length
1614 the user must type.
1615 Having less switches helps best.
1617 ..
1620 .\" XXX: whatnow prompt commands
1625 .H1 "Modernizing
1626 .P
1627 The code base of mmh originates from the late Seventies.
1628 Through the Eighties, extensive work had been done on it.
1629 In the Nineties, it had been partly reorganized and extended.
1630 Relicts from each decade have gathered in the code base.
1631 My goal was to modernize the code base.
1633 .P
1634 FIXME functional aspect only here
1635 .P
1636 FIXME ref to `code style' for non-functional aspects.
1639 .H2 "Code Relicts
1640 .P
1641 My position to drop obsolete functionality of mmh to remove old code
1642 is much more revolutional than the nmh community likes it.
1643 Without the need to justify my decisions, I was able to quickly
1644 remove functionality I considered ancient.
1645 The need to discuss my decisions with
1646 peers likely would have slowed this process down.
1647 Of course, I researched if a particular feature really should be dropped.
1648 Having not had any
1649 contact to this feature within my computer life was a first indicator to
1650 drop it, but I also asked others and searched the literature for modern
1651 usage of the feature.
1652 If it appeared to be truly ancient, I dropped it.
1653 The reason for dropping is always part of the commit message in the
1654 version control system.
1655 Thus, it is easy for others to check their
1656 view on the topic with mine and possibly to argue for reinclusion.
1659 .U3 "MMDF maildrop support
1660 .P
1661 I did drop any support for the MMDF maildrop format.
1662 This type of format
1663 is conceptionally similar to the mbox format, but uses four bytes with
1664 value 1 (\fL^A^A^A^A\fP) as message delimiter,
1665 instead of the string ``\fLFrom\ \fP''.
1666 Due to the similarity and mbox being the de-facto standard maildrop
1667 format on Unix, but also due to the larger influence of Sendmail than MMDF,
1668 the MMDF maildrop format had vanished.
1669 .P
1670 The simplifications within the code were only moderate.
1671 Switches could be removed from tools like
1672 .L packf ,
1673 which generate packed mailboxes.
1674 Only one packed mailbox format remained: mbox.
1675 The most important changes affect the equally named mail parsing routine in
1676 .L sbr/m_getfld.c .
1677 The direct MMDF code had been removed, but as now only one packed mailbox
1678 format is left, code structure simplifications are likely possible.
1679 The reason why they are still outstanding is the heavily optimized code
1680 of
1681 .Fu m_getfld() .
1682 Changes beyond a small local scope \(en
1683 which restructuring in its core is \(en cause a high risk of damaging
1684 the intricate workings of the optimized code.
1685 This problem is know to the developers of nmh, too.
1686 They also avoid touching this minefield if possible.
1688 .U3 "UUCP Bang Paths
1689 .P
1690 More questionably than the former topic is the removal of support for the
1691 UUCP bang path address style.
1692 However, the user may translate the bang
1693 paths on retrieval to Internet addresses and the other way on posting
1694 messages.
1695 The former can be done my an MDA like procmail; the latter
1696 by a sendmail wrapper.
1697 This would ensure that any address handling would work as expected.
1698 However, it might just work well without any
1699 such modifications, as mmh does not touch addresses much, in general.
1700 But I can't ensure as I have never used an environment with bang paths.
1701 Also, the behavior might break at any point in further development.
1703 .U3 "Hardcopy terminal support
1704 .P
1705 More of a funny anecdote is the remaining of a check for printing to a
1706 hardcopy terminal until Spring 2012, when I finally removed it.
1707 I surely would be very happy to see such a terminal in action, maybe
1708 actually being able to work on it, but I fear my chances are null.
1709 .P
1710 The check only prevented a pager to be placed between the outputting
1711 program (\c
1712 .Pn mhl )
1713 and the terminal.
1714 This could have been ensured with the
1715 .Sw -nomoreproc
1716 at the command line statically, too.
1718 .U3 "Removed support for header fields
1719 .P
1720 The
1721 .Hd Encrypted
1722 header field had been introduced by RFC\^822, but already
1723 marked legacy in RFC 2822.
1724 It was superseded by FIXME.
1725 Mmh does no more support this header field.
1726 .P
1727 Native support for
1728 .Hd Face
1729 header fields had been removed, as well.
1730 The feature is similar to the
1731 .Hd X-Face
1732 header field in its intent,
1733 but takes a different approach to store the image.
1734 Instead of encoding the image data directly into the header field,
1735 the it contains the hostname and UDP port where the image
1736 date could be retrieved.
1737 Neither
1738 .Hd X-Face
1739 nor the here described
1740 .Hd Face
1741 system
1742 \**
1743 .FS
1744 There is also a newer but different system, invented 2005,
1745 using
1746 .Hd Face
1747 headers.
1748 It is the successor of
1749 .Hd X-Face
1750 providing colored PNG images.
1751 .FE
1752 became well used in the large scale.
1753 It's still possible to use a Face systems,
1754 although mmh does not provide support for any of the different systems
1755 anymore. It's fairly easy to write a small shell script to
1756 extract the embedded or fetch the external Face data and display the image.
1757 Own
1758 .Hd Face
1759 header field can be added into the draft template files.
1760 .P
1761 .Hd Content-MD5
1762 header fields were introduced by RFC\^1864. They provide only
1763 a verification of data corruption during the transfer. By no means can
1764 they ensure verbatim end-to-end delivery of the contents. This is clearly
1765 stated in the RFC. The proper approach to provide verificationability
1766 of content in an end-to-end relationship is the use of digital cryptography
1767 (RFCs FIXME). On the other hand, transfer protocols should ensure the
1768 integrity of the transmission. In combinations these two approaches
1769 make the
1770 .Hd Content-MD5
1771 header field useless. In consequence, I removed
1772 the support for it. By this removal, MD5 computation is not needed
1773 anywhere in mmh. Hence, over 500 lines of code were removed by this one
1774 change. Even if the
1775 .Hd Content-MD5
1776 header field is useful sometimes,
1777 I value its usefulness less than the improvement in maintainability, caused
1778 by the removal.
1780 .U3 "Prompter's Control Keys
1781 .P
1782 The program
1783 .Pn prompter
1784 queries the user to fill in a message form. When used by
1785 .Pn comp
1786 as:
1787 .VS
1788 comp -editor prompter
1789 VE
1790 the resulting behavior is similar to
1791 .Pn mailx .
1792 Apparently,
1793 .Pn prompter
1794 hadn't been touched lately. Otherwise it's hardly explainable why it
1795 still offered the switches
1796 .Sw -erase
1797 .Ar chr
1798 and
1799 .Sw -kill
1800 .Ar chr
1801 to name the characters for command line editing.
1802 The times when this had been necessary are long time gone.
1803 Today these things work out-of-the-box, and if not, are configured
1804 with the standard tool
1805 .Pn stty .
1807 .U3 "Vfork and Retry Loops
1808 .P
1809 MH creates many processes, which is a consequence of the tool chest approach.
1810 In earlier times
1811 .Fu fork()
1812 had been an expensive system call, as the process's whole image needed
1813 to be duplicated. One common case is replacing the image with
1814 .Fu exec()
1815 right after having forked the child process.
1816 To speed up this case, the
1817 .Fu vfork()
1818 system call was invented at Berkeley. It completely omits copying the
1819 image. If the image gets replaced right afterwards then unnecessary
1820 work is omited. On old systems this results in large speed ups.
1821 MH uses
1822 .Fu vfork()
1823 whenever possible.
1824 .P
1825 Memory management units that support copy-on-write semantics make
1826 .Fu fork()
1827 almost as fast as
1828 .Fu vfork()
1829 in the cases when they can be exchanged.
1830 With
1831 .Fu vfork()
1832 being more error-prone and hardly faster, it's preferable to simply
1833 use
1834 .Fu fork()
1835 instead.
1836 .P
1837 Related to the costs of
1838 .Fu fork()
1839 is the probability of its success.
1840 Today on modern systems, the system call will succeed almost always.
1841 In the Eighties on heavy loaded systems, as they were common at
1842 universities, this had been different. Thus, many of the
1843 .Fu fork()
1844 calls were wrapped into loops to retry to fork several times in
1845 short intervals, in case of previous failure.
1846 In mmh, the program aborts at once if the fork failed.
1847 The user can reexecute the command then. This is expected to be a
1848 very rare case on modern systems, especially personal ones, which are
1849 common today.
1852 .H2 "Attachments
1853 .P
1854 The mind model of email attachments is unrelated to MIME.
1855 Although the MIME RFCs (2045 through 2049) define the technical
1856 requirements for having attachments, they do not mention the the word
1857 ``attachment''.
1858 Instead of attachments, MIME talks about ``multi-part message bodies''
1859 [RFC\|2045], a more general concept.
1860 Multi-part messages are messages
1861 ``in which one or more different
1862 sets of data are combined in a single body''
1863 [RFC\|2046].
1864 MIME keeps its descriptions generic;
1865 it does not imply specific usage models.
1866 In email one usage model became prevalent: attachments.
1867 The idea is having a main text document with files of arbitrary kind
1868 attached to it.
1869 In MIME terms, this is a multi-part message having a text part first
1870 and parts of arbitray type following.
1871 .P
1872 MH's MIME support is a direct implementation of the RFCs.
1873 The perception of the topic described in the RFCs is clearly visible
1874 in MH's implementation.
1875 Thus, MH had all the MIME features but no idea of attachments.
1876 Today, however, users don't need all the MIME features but they want
1877 convenient attachment handling.
1879 .U3 "Composing MIME Messages
1880 .P
1881 In order to improve the situation on the message composing side,
1882 Jon Steinhart had added an attachment system to nmh in 2002.
1883 .Ci 7480dbc14bc90f2d872d434205c0784704213252
1884 In the file
1885 .Fn docs/README-ATTACHMENTS ,
1886 he described his motivation to do so as such:
1887 .QS
1888 Although nmh contains the necessary functionality for MIME message handing,
1889 the interface to this functionality is pretty obtuse.
1890 There's no way that I'm ever going to convince my partner to write
1891 .Pn mhbuild
1892 composition files!
1893 .QE
1894 .LP
1895 With this change, the mind model of attachments entered nmh.
1896 In the same document:
1897 .QS
1898 These changes simplify the task of managing attachments on draft files.
1899 They allow attachments to be added, listed, and deleted.
1900 MIME messages are automatically created when drafts with attachments
1901 are sent.
1902 .QE
1903 .LP
1904 Unfortunately, the attachment system,
1905 like any new facilities in nmh,
1906 was deactive by default.
1907 .P
1908 During my work in Argentina, I tried to improve the attachment system.
1909 But, because of great opposition in the nmh community,
1910 my patch died as a proposal on the mailing list, after long discussions.
1911 .[
1912 nmh-workers attachment proposal
1913 .]
1914 In Januar 2012, I extended the patch and applied it to mmh.
1915 .Ci 8ff284ff9167eff8f5349481529332d59ed913b1
1916 In mmh, the attachment system is active by default.
1917 Instead of command line switches, the
1918 .Pe Attachment-Header
1919 profile entry is used to specify
1920 the name of the attachment header field.
1921 It is pre-defined to
1922 .Hd Attach .
1923 .P
1924 To add an attachment to a draft, simply add an attachment header:
1925 .VS
1926 To: bob
1927 Subject: The file you wanted
1928 Attach: /path/to/the/file-bob-wanted
1929 --------
1930 Here it is.
1931 VE
1932 The header field can be added to the draft manually in the editor,
1933 or by using the `attach' command at the WhatNow prompt, or
1934 non-interactively with
1935 .Pn anno :
1936 .VS
1937 anno -append -nodate -component Attach -text /path/to/attachment
1938 VE
1939 Drafts with attachment headers are converted to MIME automatically by
1940 .Pn send .
1941 The conversion to MIME is invisible to the user.
1942 The draft stored in the draft folder is always in source form, with
1943 attachment headers.
1944 If the MIMEification fails, for instance because the file to attach
1945 is not accessible, the original draft is not changed.
1946 .P
1947 The attachment system handles the forwarding of messages, too.
1948 If the attachment header value starts with a plus character (`+'),
1949 like in
1950 .Cl "Attach: +bob 30 42" ,
1951 The given messages in the specified folder will be attached.
1952 This allowed to simplify
1953 .Pn forw .
1954 .Ci f41f04cf4ceca7355232cf7413e59afafccc9550
1955 .P
1956 Closely related to attachments is non-ASCII text content,
1957 because it requires MIME too.
1958 In nmh, the user needed to call `mime' at the WhatNow prompt
1959 to have the draft converted to MIME.
1960 This was necessary whenever the draft contained non-ASCII characters.
1961 If the user did not call `mime', a broken message would be sent.
1962 Therefore, the
1963 .Pe automimeproc
1964 profile entry could be specified to have the `mime' command invoked
1965 automatically each time.
1966 Unfortunately, this approach conflicted with with attachment system
1967 because the draft would already be in MIME format at the time
1968 when the attachment system wanted to MIMEify it.
1969 To use nmh's attachment system, `mime' must not be called at the
1970 WhatNow prompt and
1971 .Pe automimeproc
1972 must not be set in the profile.
1973 But then the case of non-ASCII text without attachment headers was
1974 not caught.
1975 All in all, the solution was complex and irritating.
1976 My patch from December 2010 would have simplified the situation.
1977 .P
1978 Mmh's current solution is even more elaborate.
1979 Any necessary MIMEification is done automatically.
1980 There is no `mime' command at the WhatNow prompt anymore.
1981 The draft will be converted automatically to MIME when either an
1982 attachment header or non-ASCII text is present.
1983 Further more, the special meaning of the hash character (`#')
1984 at line beginnings in the draft message is removed.
1985 Users need not at all deal with the whole topic.
1986 .P
1987 Although the new approach does not anymore support arbitrary MIME
1988 compositions directly, the full power of
1989 .Pn mhbuild
1990 can still be accessed.
1991 Given no attachment headers are included, the user can create
1992 .Pn mhbuild
1993 composition drafts like in nmh.
1994 Then, at the WhatNow prompt, he needs to invoke
1995 .Cl "edit mhbuild
1996 to convert it to MIME.
1997 Because the resulting draft does neither contain non-aASCII characters
1998 nor has it attachment headers, the attachment system will not touch it.
1999 .P
2000 The approach taken in mmh is taylored towards todays most common case:
2001 a text part with possibly attachments.
2002 This case is simplified a lot for users.
2004 .U3 "MIME Type Guessing
2005 .P
2006 The use of
2007 .Pn mhbuild
2008 composition drafts had one notable advantage over attachment headers
2009 from the programmer's point of view: The user provides the appropriate
2010 MIME types for files to include.
2011 The attachment system needs to find out the correct MIME type itself.
2012 This is a difficult task, yet it spares the user irritating work.
2013 Determining the correct MIME type of content is partly mechanical,
2014 partly intelligent work.
2015 Forcing the user to find out the correct MIME type,
2016 forces him to do partly mechanical work.
2017 Letting the computer do the work, can lead to bad choices for difficult
2018 content.
2019 For mmh, the latter option was chosen.
2020 .P
2021 Determining the MIME type by the suffix of the file name is a dumb
2022 approach, yet it is simple to implement and provides good results
2023 for the common cases.
2024 Mmh implements this approach in the
2025 .Pn print-mimetype
2026 script.
2027 Using it is the default choice.
2028 .P
2029 A far better but less portable approach is the use of
2030 .Pn file .
2031 This standard tool tries to determine the type of files.
2032 Unfortunately, its capabilities and accuracy varies from system to system.
2033 Additionally, its output was only intended for human beings,
2034 but not to be used by programs.
2035 It varies much.
2036 Nevertheless, modern versions of GNU
2037 .Pn file ,
2038 which is prevalent on the popular GNU/Linux systems,
2039 provides MIME type output in machine-readable form.
2040 Although this solution is highly system-dependent,
2041 it solves the difficult problem well.
2042 On systems where GNU
2043 .Pn file ,
2044 version 5.04 or higher, is available it should be used.
2045 One needs to specify the following profile entry to do so:
2046 .VS
2047 Mime-Type-Query: file -b --mime
2048 VE
2049 .LP
2050 Other versions of
2051 .Pn file
2052 might possibly be usable with wrapper scripts to reformat the output.
2053 The diversity among
2054 .Pn file
2055 implementations is great; one needs to check the local variant.
2056 .P
2057 If no MIME type can be determined, text content gets sent as
2058 `text/plain' and anything else under the generic fall-back type
2059 `application/octet-stream'.
2060 It is not possible in mmh to override the automatic MIME type guessing
2061 for a specific file.
2062 To do so, the user would need to know in advance for which file
2063 the automatic guessing does fail, or the system would require interaction.
2064 I consider both cases impractical.
2065 The existing solution should be sufficient.
2066 If not, the user may always fall back to
2067 .Pn mhbuild
2068 composition drafts and ignore the attachment system.
2071 .U3 "Storing Attachments
2072 .P
2073 FIXME
2076 .U3 "Showing MIME Messages
2077 .P
2078 FIXME
2082 .H2 "Digital Cryptography
2083 .P
2084 Signing and encryption.
2088 .H2 "Modern Defaults
2089 .P
2090 Just to give one example, for me it took one year of using nmh
2091 before I became aware of the existence of the attachment system.
2092 One could argue that this fact disqualifies my reading of the
2093 documentation.
2094 If I would have installed nmh from source back then, I could agree.
2095 Yet I had used a prepackaged version and had expected that it would
2096 just work.
2100 .H1 "Code Style
2101 .P
2102 foo
2105 .H2 "Standard Code
2106 .P
2107 POSIX
2109 .U3 "Converting to Standard Code
2110 .P
2111 One part of this task was converting obsolete code constructs
2112 to standard constructs.
2113 As I'm not even thirty years old and have no more than seven years of
2114 Unix experience, I needed to learn about the history in retrospective.
2115 Older people likely have used those ancient constructs themselves
2116 and have suffered from their incompatibilities and have longed for
2117 standardization.
2118 Unfortunately, I have only read that others had done so.
2119 This put me in a much more difficult positions when working on the old
2120 code.
2121 I needed to recherche what other would have known by heart from
2122 experience.
2123 All my programming experience comes from a time past ANSI C
2124 and past POSIX.
2125 Although I knew about the times before, I took the
2126 current state implicitly for granted most of the time.
2127 .P
2128 Being aware of
2129 these facts, I rather let people with more historic experience solve the
2130 task of converting the ancient code constructs to standardized ones.
2131 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
2132 He converted large parts of the code to POSIX constructs, removing
2133 the conditionals compilation for now standardized features.
2134 I'm thankful for this task being solved. I only pulled the changes into
2135 mmh.
2140 .H2 "Separation
2142 .U2 "MH Directory Split
2143 .P
2144 In MH and nmh, a personal setup had consisted of two parts:
2145 The MH profile, named
2146 .Fn \&.mh_profile
2147 and being located directly in the user's home directory.
2148 And the MH directory, where all his mail messages and also his personal
2149 forms, scan formats, other configuration files are stored. The location
2150 of this directory could be user-chosen. The default was to name it
2151 .Fn Mail
2152 and have it directly in the home directory.
2153 .P
2154 I've never liked the data storage and the configuration to be intermixed.
2155 They are different kinds of data. One part, are the messages,
2156 which are the data to operate on. The other part, are the personal
2157 configuration files, which are able to change the behavior of the operations.
2158 The actual operations are defined in the profile, however.
2159 .P
2160 When storing data, one should try to group data by its type.
2161 There's sense in the Unix file system hierarchy, where configuration
2162 file are stored separate (\c
2163 .Fn /etc )
2164 to the programs (\c
2165 .Fn /bin
2166 and
2167 .Fn /usr/bin )
2168 to their sources (\c
2169 .Fn /usr/src ).
2170 Such separation eases the backup management, for instance.
2171 .P
2172 In mmh, I've reorganized the file locations.
2173 Still there are two places:
2174 There's the mail storage directory, which, like in MH, contains all the
2175 messages, but, unlike in MH, nothing else.
2176 Its location still is user-chosen, with the default name
2177 .Fn Mail ,
2178 in the user's home directory. This is much similar to the case in nmh.
2179 The configuration files, however, are grouped together in the new directory
2180 .Fn \&.mmh
2181 in the user's home directory.
2182 The user's profile now is a file, named
2183 .Fn profile ,
2184 in this mmh directory.
2185 Consistently, the context file and all the personal forms, scan formats,
2186 and the like, are also there.
2187 .P
2188 The naming changed with the relocation.
2189 The directory where everything, except the profile, had been stored (\c
2190 .Fn $HOME/Mail ),
2191 used to be called \fIMH directory\fP. Now, this directory is called the
2192 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
2193 the new directory
2194 (\c
2195 .Fn $HOME/.mmh ),
2196 containing all the personal configuration files.
2197 .P
2198 The separation of the files by type of content is logical and convenient.
2199 There are no functional differences as any possible setup known to me
2200 can be implemented with both approaches, although likely a bit easier
2201 with the new approach. The main goal of the change had been to provide
2202 sensible storage locations for any type of personal mmh file.
2203 .P
2204 In order for one user to have multiple MH setups, he can use the
2205 environment variable
2206 .Ev MH
2207 the point to a different profile file.
2208 The MH directory (mail storage plus personal configuration files) is
2209 defined by the
2210 .Pe Path
2211 profile entry.
2212 The context file could be defined by the
2213 .Pe context
2214 profile entry or by the
2215 .Ev MHCONTEXT
2216 environment variable.
2217 The latter is useful to have a distinct context (e.g. current folders)
2218 in each terminal window, for instance.
2219 In mmh, there are three environment variables now.
2220 .Ev MMH
2221 may be used to change the location of the mmh directory.
2222 .Ev MMHP
2223 and
2224 .Ev MMHC
2225 change the profile and context files, respectively.
2226 Besides providing a more consistent feel (which simply is the result
2227 of being designed anew), the set of personal configuration files can
2228 be chosen independently from the profile (including mail storage location)
2229 and context, now. Being it relevant for practical use or not, it
2230 de-facto is an improvement. However, the main achievement is the
2231 split between mail storage and personal configuration files.
2234 .H2 "Modularization
2235 .P
2236 whatnowproc
2237 .P
2238 The \fIMH library\fP
2239 .Fn libmh.a
2240 collects a bunch of standard functions that many of the MH tools need,
2241 like reading the profile or context files.
2242 This doesn't hurt the separation.
2245 .H2 "Style
2246 .P
2247 Code layout, goto, ...
2249 .P
2250 anno rework
2255 .H1 "Concept Exploitation/Homogeneity
2258 .H2 "Draft Folder
2259 .P
2260 Historically, MH provided exactly one draft message, named
2261 .Fn draft
2262 and
2263 being located in the MH directory. When starting to compose another message
2264 before the former one was sent, the user had been questioned whether to use,
2265 refile or replace the old draft. Working on multiple drafts at the same time
2266 was impossible. One could only work on them in alteration by refiling the
2267 previous one to some directory and fetching some other one for reediting.
2268 This manual draft management needed to be done each time the user wanted
2269 to switch between editing one draft to editing another.
2270 .P
2271 To allow true parallel editing of drafts, in a straight forward way, the
2272 draft folder facility exists. It had been introduced already in July 1984
2273 by Marshall T. Rose. The facility was deactivated by default.
2274 Even in nmh, the draft folder facility remained deactivated by default.
2275 At least, Richard Coleman added the man page
2276 .Mp mh-draft(5)
2277 to document
2278 the feature well.
2279 .P
2280 The only advantage of not using the draft folder facility is the static
2281 name of the draft file. This could be an issue for MH front-ends like mh-e.
2282 But as they likely want to provide working on multiple drafts in parallel,
2283 the issue is only concerning compatibility. The aim of nmh to stay compatible
2284 prevented the default activation of the draft folder facility.
2285 .P
2286 On the other hand, a draft folder is the much more natural concept than
2287 a draft message. MH's mail storage consists of folders and messages,
2288 the messages named with ascending numbers. A draft message breaks with this
2289 concept by introducing a message in a file named
2290 .Fn draft .
2291 This draft
2292 message is special. It can not be simply listed with the available tools,
2293 but instead requires special switches. I.e. corner-cases were
2294 introduced. A draft folder, in contrast, does not introduce such
2295 corner-cases. The available tools can operate on the messages within that
2296 folder like on any messages within any mail folders. The only difference
2297 is the fact that the default folder for
2298 .Pn send
2299 is the draft folder,
2300 instead of the current folder, like for all other tools.
2301 .P
2302 The trivial part of the change was activating the draft folder facility
2303 by default and setting a default name for this folder. Obviously, I chose
2304 the name
2305 .Fn +drafts .
2306 This made the
2307 .Sw -draftfolder
2308 and
2309 .Sw -draftmessage
2310 switches useless, and I could remove them.
2311 The more difficult but also the part that showed the real improvement,
2312 was updating the tools to the new concept.
2313 .Sw -draft
2314 switches could
2315 be dropped, as operating on a draft message became indistinguishable to
2316 operating on any other message for the tools.
2317 .Pn comp
2318 still has its
2319 .Sw -use
2320 switch for switching between its two modes: (1) Compose a new
2321 draft, possibly by taking some existing message as a form. (2) Modify
2322 an existing draft. In either case, the behavior of
2323 .Pn comp is
2324 deterministic. There is no more need to query the user. I consider this
2325 a major improvement. By making
2326 .Pn send
2327 simply operate on the current
2328 message in the draft folder by default, with message and folder both
2329 overridable by specifying them on the command line, it is now possible
2330 to send a draft anywhere within the storage by simply specifying its folder
2331 and name.
2332 .P
2333 All theses changes converted special cases to regular cases, thus
2334 simplifying the tools and increasing the flexibility.
2337 .H2 "Trash Folder
2338 .P
2339 Similar to the situation for drafts is the situation for removed messages.
2340 Historically, a message was deleted by renaming. A specific
2341 \fIbackup prefix\fP, often comma (\c
2342 .Fn , )
2343 or hash (\c
2344 .Fn # ),
2345 being prepended to the file name. Thus, MH wouldn't recognize the file
2346 as a message anymore, as only files whose name consists of digits only
2347 are treated as messages. The removed messages remained as files in the
2348 same directory and needed some maintenance job to truly delete them after
2349 some grace time. Usually, by running a command similar to
2350 .VS
2351 find /home/user/Mail -ctime +7 -name ',*' | xargs rm
2352 VE
2353 in a cron job. Within the grace time interval
2354 the original message could be restored by stripping the
2355 the backup prefix from the file name. If however, the last message of
2356 a folder is been removed \(en say message
2357 .Fn 6
2358 becomes file
2359 .Fn ,6
2360 \(en and a new message enters the same folder, thus the same
2361 numbered being given again \(en in our case
2362 .Fn 6
2363 \(en, if that one
2364 is removed too, then the backup of the former message gets overwritten.
2365 Thus, the ability to restore removed messages does not only depend on
2366 the ``sweeping cron job'' but also on the removing of further messages.
2367 This is undesirable, because the real mechanism is hidden from the user
2368 and the consequences of further removals are not always obvious.
2369 Further more, the backup files are scattered within the whole mail
2370 storage, instead of being collected at one place.
2371 .P
2372 To improve the situation, the profile entry
2373 .Pe rmmproc
2374 (previously named
2375 .Pe Delete-Prog )
2376 was introduced, very early.
2377 It could be set to any command, which would care for the mail removal
2378 instead of taking the default action, described above.
2379 Refiling the to-be-removed files to some garbage folder was a common
2380 example. Nmh's man page
2381 .Mp rmm(1)
2382 proposes
2383 .Cl "refile +d
2384 to move messages to the garbage folder and
2385 .Cl "rm `mhpath +d all`
2386 the empty the garbage folder.
2387 Managing the message removal this way is a sane approach. It keeps
2388 the removed messages in one place, makes it easy to remove the backup
2389 files, and, most important, enables the user to use the tools of MH
2390 itself to operate on the removed messages. One can
2391 .Pn scan
2392 them,
2393 .Pn show
2394 them, and restore them with
2395 .Pn refile .
2396 There's no more
2397 need to use
2398 .Pn mhpath
2399 to switch over from MH tools to Unix tools \(en MH can do it all itself.
2400 .P
2401 This approach matches perfect with the concepts of MH, thus making
2402 it powerful. Hence, I made it the default. And even more, I also
2403 removed the old backup prefix approach, as it is clearly less powerful.
2404 Keeping unused alternative in the code is a bad choice as they likely
2405 gather bugs, by not being constantly tested. Also, the increased code
2406 size and more conditions crease the maintenance costs. By strictly
2407 converting to the trash folder approach, I simplified the code base.
2408 .Pn rmm
2409 calls
2410 .Pn refile
2411 internally to move the to-be-removed
2412 message to the trash folder (\c
2413 .Fn +trash
2414 by default). Messages
2415 there can be operated on like on any other message in the storage.
2416 The sweep clean, one can use
2417 .Cl "rmm -unlink +trash a" ,
2418 where the
2419 .Sw -unlink
2420 switch causes the files to be truly unliked instead
2421 of moved to the trash folder.
2424 .H2 "Path Notations
2425 .P
2426 foo
2429 .H2 "MIME Integration
2430 .P
2431 user-visible access to whole messages and MIME parts are inherently
2432 different
2435 .H2 "Of One Cast
2436 .P