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