| rev |
line source |
|
meillo@39
|
1 .RN 1
|
|
meillo@39
|
2
|
|
meillo@0
|
3 .H0 "Introduction
|
|
meillo@0
|
4 .P
|
|
meillo@32
|
5 This chapter introduces MH, its history, concepts and how it is used.
|
|
meillo@32
|
6 Then, it describes nmh's code base and community to give the reader
|
|
meillo@32
|
7 a better understanding of the state from which mmh started off.
|
|
meillo@32
|
8 Further more, this chapter lists the motivation and goals of the mmh project.
|
|
meillo@32
|
9 This chapter introduces MH, nmh and mmh to the reader and outlines
|
|
meillo@32
|
10 the mmh project itself.
|
|
meillo@8
|
11
|
|
meillo@0
|
12
|
|
meillo@28
|
13 .H1 "MH \(en the Mail Handler
|
|
meillo@0
|
14 .P
|
|
meillo@2
|
15 MH is an electronic mail system, originating in the RAND Corporation.
|
|
meillo@32
|
16 Most important for this thesis is that MH defines a mail handling concept.
|
|
meillo@32
|
17 In fact, MH had started as a design proposal, not as an implementation,
|
|
meillo@32
|
18 and in spirit it had remained this way. This is similar to Unix, which
|
|
meillo@42
|
19 influenced the world more in being a set of system design concepts
|
|
meillo@32
|
20 than in being a specific software product.
|
|
meillo@42
|
21 These ideas behind Unix are summarized in the \fIUnix philosophy\fP.
|
|
meillo@42
|
22 MH follows this philosophy.
|
|
meillo@2
|
23
|
|
meillo@11
|
24 .U2 "History
|
|
meillo@2
|
25 .P
|
|
meillo@2
|
26 MH is an electronic mail system, originating in the RAND Corporation.
|
|
meillo@32
|
27 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
|
|
meillo@32
|
28 had proposed the design
|
|
meillo@32
|
29 of a new mail handling system, called ``Mail Handler'' (MH),
|
|
meillo@32
|
30 to superseed RAND's old monolithic ``Mail System'' (MS).
|
|
meillo@27
|
31 Two years later, in 1979, Bruce Borden took the proposal and implemented a
|
|
meillo@32
|
32 prototype of MH.
|
|
meillo@32
|
33 Before the prototype had been available, the concept was
|
|
meillo@32
|
34 believed to be practically unusable because of being too slow.
|
|
meillo@32
|
35 But the prototype proved successful and replaced MS thereafter.
|
|
meillo@32
|
36 In replacing MS, MH became an all-in-one mail system.
|
|
meillo@2
|
37 .P
|
|
meillo@32
|
38 A decade later, the University of California at Irvine had started to use MH.
|
|
meillo@2
|
39 They also took over its development and pushed MH forward.
|
|
meillo@32
|
40 This was the time when the Internet appeared, UCB implemented
|
|
meillo@32
|
41 the TCP/IP stack, and Allman wrote Sendmail.
|
|
meillo@32
|
42 MH was extended as emailing got more features.
|
|
meillo@32
|
43 The development of MH was closely related to the development of email
|
|
meillo@32
|
44 RFCs. In the advent of MIME, MH was the first implementation of this new
|
|
meillo@32
|
45 email standard.
|
|
meillo@2
|
46 .P
|
|
meillo@2
|
47 In the nineties, MH had been moved into the public domain, making it
|
|
meillo@32
|
48 attractive to Free Software developers.
|
|
meillo@32
|
49 The Internet had started to become popular and in 1997,
|
|
meillo@32
|
50 Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
|
|
meillo@32
|
51 a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
|
|
meillo@32
|
52 and Craig Leres.
|
|
meillo@32
|
53 Colman intended to modernize MH and improve its portability and
|
|
meillo@32
|
54 MIME handling capabilities.
|
|
meillo@32
|
55 This should be done openly within the Internet community.
|
|
meillo@32
|
56 The development of MH stopped soon after the development of nmh had started.
|
|
meillo@32
|
57 Today, nmh almost completely replaced the original MH.
|
|
meillo@0
|
58
|
|
meillo@11
|
59 .U2 "Concepts
|
|
meillo@0
|
60 .P
|
|
meillo@8
|
61 MH is a toolchest, modelled after the Unix toolchest. It consists of a
|
|
meillo@42
|
62 set of tools, each covering a specific task of email handling.
|
|
meillo@42
|
63 The programs
|
|
meillo@8
|
64 operate on a common mail storage. The specific format of the mail storage
|
|
meillo@32
|
65 characterizes MH in the same way like the format of the file system
|
|
meillo@32
|
66 characterizes Unix.
|
|
meillo@42
|
67 .P
|
|
meillo@32
|
68 The mail storage consists of \fImail folders\fP (directories) and
|
|
meillo@32
|
69 \fPmessages\fP (regular files).
|
|
meillo@32
|
70 Each message is stored in a separate file in the format it had been
|
|
meillo@32
|
71 received (i.e. transfer format). The files are named with ascending numbers
|
|
meillo@32
|
72 in each folder.
|
|
meillo@42
|
73 .P
|
|
meillo@32
|
74 MH tools maintain a \fIcontext\fP, which includes
|
|
meillo@32
|
75 the current mail folder and current message.
|
|
meillo@32
|
76 Processes in Unix have a similar context, containing the current working
|
|
meillo@32
|
77 directory, for instance. In contrast, the process context is maintained
|
|
meillo@32
|
78 by the Unix kernel automatically, whereas MH tools need to maintain the MH
|
|
meillo@32
|
79 context themselves.
|
|
meillo@32
|
80 The user can have one MH context or multiple ones, he can even share it
|
|
meillo@32
|
81 with other users.
|
|
meillo@42
|
82 .P
|
|
meillo@32
|
83 Messages can have symbolic names. These can be automatically updated
|
|
meillo@32
|
84 position names like being the next or the last message,
|
|
meillo@32
|
85 or user-settable group names for arbitrary sets of messages.
|
|
meillo@32
|
86 These names are called sequences.
|
|
meillo@32
|
87 Sequences can be bound to the folder or to the context.
|
|
meillo@2
|
88 .P
|
|
meillo@32
|
89 New MH tools are built out of or on top of existing ones easily \(en
|
|
meillo@32
|
90 a property common to toolchests.
|
|
meillo@32
|
91 Multiple versions of the same command with different default values
|
|
meillo@32
|
92 are created very easily. This provides shortcuts and tayloring.
|
|
meillo@32
|
93 Form templates for new messages or for replies are easily exchangable.
|
|
meillo@32
|
94 Generally, output is adjustable with format files.
|
|
meillo@42
|
95 .P
|
|
meillo@32
|
96 The configuration is stored in a file that is called the user's \fIprofile\fP.
|
|
meillo@32
|
97 MH encourages the user to taylor and automate the mail handling.
|
|
meillo@42
|
98 Almost every part of the system can be adjusted to personal preference.
|
|
meillo@32
|
99 The system is well scriptable and extendable.
|
|
meillo@32
|
100 As the MH toolchest was modelled after the Unix toolchest, the
|
|
meillo@32
|
101 properties of the latter apply to the former as well.
|
|
meillo@8
|
102
|
|
meillo@32
|
103 .U2 "Versions
|
|
meillo@27
|
104 .P
|
|
meillo@27
|
105 Three versions of MH are available today:
|
|
meillo@32
|
106 .IP "Old MH"
|
|
meillo@42
|
107 .br
|
|
meillo@32
|
108 In most cases this version had been replaced by nmh,
|
|
meillo@32
|
109 but some systems might still provide old MH.
|
|
meillo@32
|
110 The main reasons to still use old MH are historical reasons.
|
|
meillo@32
|
111 MH provides hardly any benefits over nmh.
|
|
meillo@27
|
112 The development of old MH has stopped after the 6.8.4 release in
|
|
meillo@27
|
113 February 1996.
|
|
meillo@42
|
114 .IP nmh
|
|
meillo@42
|
115 .br
|
|
meillo@27
|
116 The most widespread version of MH was forked off version 6.8.3 in December
|
|
meillo@32
|
117 1996. It is based on the \fILBL changes\fP.
|
|
meillo@32
|
118 Backward-compatibility to old MH is provided by having new featues deactivated
|
|
meillo@32
|
119 by default. In consequence, the user needs to activate them explicitely to
|
|
meillo@32
|
120 be able to use them.
|
|
meillo@32
|
121 Throughout the previous years, the work on nmh was mostly maintenance work.
|
|
meillo@32
|
122 Development revived in December 2011 and stayed busy since then.
|
|
meillo@32
|
123 .IP mmh
|
|
meillo@42
|
124 .br
|
|
meillo@32
|
125 This descendent of nmh is the subject of this thesis.
|
|
meillo@32
|
126 It had started as an experimental version, but became de facto a fork.
|
|
meillo@8
|
127
|
|
meillo@27
|
128 .U2 "Example Session
|
|
meillo@27
|
129 .P
|
|
meillo@32
|
130 Following is an example mail handling session with mmh.
|
|
meillo@32
|
131 It should be mostly compatible with nmh and old MH.
|
|
meillo@32
|
132 Details might vary but the look'n'feel is the same.
|
|
meillo@42
|
133 .DS
|
|
meillo@42
|
134 $ \f(CBinc\fP
|
|
meillo@42
|
135 Incorporating new mail into inbox...
|
|
meillo@42
|
136
|
|
meillo@42
|
137 1+ 2012-05-16 11:16 meillo@dream.home Hello
|
|
meillo@42
|
138 2 2012-05-16 11:17 meillo@dream.home book
|
|
meillo@42
|
139
|
|
meillo@42
|
140 $ \f(CBshow\fP
|
|
meillo@42
|
141 Date: Wed, 16 May 2012 11:16:00 +0200
|
|
meillo@42
|
142 To: meillo
|
|
meillo@42
|
143 From: <meillo@dream.home.schnalke.org>
|
|
meillo@42
|
144 Subject: Hello
|
|
meillo@42
|
145
|
|
meillo@42
|
146 part text/plain 13
|
|
meillo@42
|
147 mmh is great
|
|
meillo@42
|
148
|
|
meillo@42
|
149 $ \f(CBnext\fP
|
|
meillo@42
|
150 Date: Wed, 16 May 2012 11:17:24 +0200
|
|
meillo@42
|
151 To: meillo
|
|
meillo@42
|
152 From: <meillo@dream.home.schnalke.org>
|
|
meillo@42
|
153 Subject: book
|
|
meillo@42
|
154
|
|
meillo@42
|
155 part text/plain 79
|
|
meillo@42
|
156 Hello meillo,
|
|
meillo@42
|
157
|
|
meillo@42
|
158 have a look at the ``Daemon book''. You need to read that!
|
|
meillo@42
|
159
|
|
meillo@42
|
160 foo
|
|
meillo@42
|
161
|
|
meillo@42
|
162 $ \f(CBrmm 1\fP
|
|
meillo@42
|
163
|
|
meillo@42
|
164 $ \f(CBscan\fP
|
|
meillo@42
|
165 2+ 2012-05-16 11:17 meillo@dream.home book
|
|
meillo@42
|
166
|
|
meillo@42
|
167 $
|
|
meillo@42
|
168 .DE
|
|
meillo@27
|
169
|
|
meillo@27
|
170
|
|
meillo@28
|
171 .H1 "nmh: Code and Community
|
|
meillo@2
|
172 .P
|
|
meillo@8
|
173 In order to understand the state, goals and dynamics of a project,
|
|
meillo@42
|
174 one needs to know its history. MH predates the Internet,
|
|
meillo@42
|
175 it comes from times before networking was universal,
|
|
meillo@42
|
176 times when emailing was small, short and simple.
|
|
meillo@42
|
177 Then it grew, spread and adopted to the changes email went through.
|
|
meillo@42
|
178 The core-concepts, however, remained the same.
|
|
meillo@42
|
179 During the 80s a small group of students at the University of
|
|
meillo@8
|
180 California, actively worked on MH. They added features and optimized,
|
|
meillo@8
|
181 like it is common for scientific work. This is still in pre-ANSI C
|
|
meillo@8
|
182 times. The source code contains many ancient parts. Code constructs
|
|
meillo@8
|
183 specific to BSD or hardware of that time are usual.
|
|
meillo@2
|
184 .P
|
|
meillo@8
|
185 Nmh started eight years after the ANSI C standard had been
|
|
meillo@8
|
186 established. A more modern coding style entered the code base. Still
|
|
meillo@8
|
187 a part of the developers come from ``the old days''. The developer
|
|
meillo@42
|
188 base became more diverse and thus the code had different style.
|
|
meillo@42
|
189 Programming practices
|
|
meillo@8
|
190 from different decades merged into the project. Different coding
|
|
meillo@8
|
191 styles came together. It appears as if multiple peers added code
|
|
meillo@42
|
192 parts, resulting in a conclomeration rather than a homogenic
|
|
meillo@8
|
193 of-one-cast mail system. Still, the basic concepts hold it together.
|
|
meillo@8
|
194 They were mostly untouched throughout the years.
|
|
meillo@8
|
195 .P
|
|
meillo@8
|
196 Although, at the surface, nmh is a toolchest, meaning a collection
|
|
meillo@8
|
197 of completely modularized small programs, on the source code level,
|
|
meillo@8
|
198 it is much more interweaved. Parts of the basic functions are
|
|
meillo@8
|
199 collected in a MH standard library, which is good, but often
|
|
meillo@8
|
200 separate functions are compiled into programs, for effiency reasons.
|
|
meillo@8
|
201 This lead to intricate innards.
|
|
meillo@8
|
202 The advent of MIME rose the complexity of email by a magnitude. This
|
|
meillo@8
|
203 is visible in nmh. The MIME-related parts are the most complex ones.
|
|
meillo@8
|
204 It's also visible that MIME support had been added on top of the
|
|
meillo@32
|
205 old MH later. The MH style made this easily possible, but it
|
|
meillo@8
|
206 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
|
|
meillo@8
|
207 and had not been thoroughly included into the concepts (e.g. the
|
|
meillo@8
|
208 user-visible access to whole messages and MIME parts are inherently
|
|
meillo@8
|
209 different).
|
|
meillo@8
|
210 .P
|
|
meillo@8
|
211 For compatibility's sake, it is a common understanding to have the
|
|
meillo@8
|
212 default settings to be compatible, requiring any new feature to be
|
|
meillo@8
|
213 explicitely enabled. This puts a burden on new users, because nmh
|
|
meillo@8
|
214 out-of-the-box keeps staying in the same ancient style, where users
|
|
meillo@8
|
215 usually want to have it practical for modern emailing.
|
|
meillo@8
|
216 But of course, this depends on if nmh is seen to be a front-end or a
|
|
meillo@8
|
217 back-end.
|
|
meillo@8
|
218
|
|
meillo@8
|
219
|
|
meillo@27
|
220 .H1 "mmh
|
|
meillo@28
|
221 .P
|
|
meillo@42
|
222 I started to work on my experimental version in Fall 2011.
|
|
meillo@42
|
223 In December, when I announced my work on the nmh-workers mailing list,
|
|
meillo@42
|
224 .[
|
|
meillo@42
|
225 nmh-workers mmh announce december
|
|
meillo@42
|
226 .]
|
|
meillo@42
|
227 the activity in nmh rose heavily.
|
|
meillo@42
|
228 Suddently the community started to move.
|
|
meillo@42
|
229 This movement was pushed much by Paul Vixie's ``edginess'' message.
|
|
meillo@42
|
230 .[
|
|
meillo@42
|
231 nmh-workers vixie edginess
|
|
meillo@42
|
232 .]
|
|
meillo@42
|
233 After long years of much stagnation, nmh became actively developed again.
|
|
meillo@42
|
234 Hence, while I was working on mmh, the community was working on nmh,
|
|
meillo@42
|
235 in parallel.
|
|
meillo@28
|
236 .P
|
|
meillo@42
|
237 The name \fImmh\fP stands for \fImeillo's mail handler\fP,
|
|
meillo@42
|
238 because mmh is my own version of MH.
|
|
meillo@42
|
239 (My login name is \fImeillo\fP.)
|
|
meillo@42
|
240 The project follows my personal considerations and preferences.
|
|
meillo@42
|
241 By calling it a personal project, I don't need to justify my decisions,
|
|
meillo@42
|
242 though, still I do.
|
|
meillo@42
|
243 This enabled me to follow my vision staightly and thus produce
|
|
meillo@42
|
244 a result of greater pureness.
|
|
meillo@42
|
245 This project model was inspired by the window manager \fIdwm\fP,
|
|
meillo@42
|
246 which is Anselm Garbe's personal window manager \(en
|
|
meillo@42
|
247 targeted to satisfy Garbe's personal needs whenever conflicts appear.
|
|
meillo@42
|
248 dwm had remained much more focused on its original goals,
|
|
meillo@42
|
249 whereas its community-driven predecessor \fIwmii\fP had
|
|
meillo@42
|
250 grown large and lost it's leanness.
|
|
meillo@42
|
251 This should not happen to mmh.
|
|
meillo@42
|
252 .P
|
|
meillo@42
|
253 mmh can also stand for \fImodern mail handler\fP, and this is
|
|
meillo@42
|
254 the variant chosen as titel for this document. One main focus of the
|
|
meillo@42
|
255 project was to modernize nmh. Another main goal is resembled in the
|
|
meillo@42
|
256 name \fIminimized mail handler\fP: Drop any parts that don't add
|
|
meillo@42
|
257 to the main task of mmh, being a MUA.
|
|
meillo@42
|
258 .P
|
|
meillo@42
|
259 It should also be noted that \fLstrcmp("mmh","nmh")<0\fP is true.
|
|
meillo@42
|
260 Although mmh bases on nmh, it is likely seen as a step backward.
|
|
meillo@42
|
261 I agree.
|
|
meillo@42
|
262 However, this step backward actually is a step forward,
|
|
meillo@42
|
263 although in another direction.
|
|
meillo@27
|
264
|
|
meillo@45
|
265
|
|
meillo@45
|
266 .H1 "This Thesis
|
|
meillo@45
|
267
|
|
meillo@27
|
268 .U2 "Motivation
|
|
meillo@27
|
269 .P
|
|
meillo@43
|
270 MH is the most important of very few command line toolchest email systems.
|
|
meillo@43
|
271 (There's also \fIim\fP by Tatsuya Kinoshita,
|
|
meillo@43
|
272 which operates on an MH mail storage.)
|
|
meillo@43
|
273 Toolchests are powerful because they can be perfectly automated and
|
|
meillo@43
|
274 extended. Toolchests are good back-ends for various sorts of front-ends.
|
|
meillo@43
|
275 They allow multiple front-ends for different special needs
|
|
meillo@43
|
276 to be implemented quickly and withough internal knowledge on emailing.
|
|
meillo@43
|
277 Further more, toolchests are much better to maintain than large monolithic
|
|
meillo@43
|
278 programs.
|
|
meillo@43
|
279 As there are few toolchests for emailing and MH-like ones are the most
|
|
meillo@43
|
280 popular amoung them, they should be developed further to keep their
|
|
meillo@43
|
281 conceptional elegance and unique scripting qualities available to users.
|
|
meillo@43
|
282 mmh will create a modern and convenient entry point for new, interested
|
|
meillo@43
|
283 users to MH-like systems.
|
|
meillo@43
|
284 .P
|
|
meillo@45
|
285 The mmh project is motivated by deficites of nmh and
|
|
meillo@45
|
286 my wish for general changes, combined
|
|
meillo@45
|
287 with the nmh community's reluctancy to change.
|
|
meillo@45
|
288 .P
|
|
meillo@45
|
289 nmh hadn't adjusted to modern emailing needs well enough.
|
|
meillo@45
|
290 The default setup was completely unusable for modern emailing.
|
|
meillo@45
|
291 Too much setup work was required.
|
|
meillo@45
|
292 Several modern features were already available but the community
|
|
meillo@45
|
293 didn't wanted to have them as default.
|
|
meillo@45
|
294 mmh is a way to change this.
|
|
meillo@45
|
295 .P
|
|
meillo@45
|
296 In my eyes, MH's concepts could be exploited even better and
|
|
meillo@45
|
297 the style of the tools could be improved. Both would simplify
|
|
meillo@45
|
298 and generalize the system, providing cleaner interfaces and more
|
|
meillo@45
|
299 software leverage, at the same time.
|
|
meillo@45
|
300 mmh is a way to demonstrate this.
|
|
meillo@45
|
301 .P
|
|
meillo@45
|
302 In providing several parts of an email system, nmh can hardly
|
|
meillo@45
|
303 compete with the large specialized projects that focus
|
|
meillo@45
|
304 on only one of the components.
|
|
meillo@45
|
305 The situation can be improved by concentrating the development power
|
|
meillo@45
|
306 on the most unique part of MH and letting the user pick his prefered
|
|
meillo@45
|
307 set of other mail components.
|
|
meillo@45
|
308 Today's pre-packaged software components encourage this model.
|
|
meillo@45
|
309 mmh is a way to go for this approach.
|
|
meillo@45
|
310 .P
|
|
meillo@43
|
311 It's worthwhile to fork nmh for the development of mmh, because
|
|
meillo@43
|
312 the two projects focus on different goals and differ in fundamental questions.
|
|
meillo@43
|
313 The nmh community's reluctance to change conflicts
|
|
meillo@43
|
314 with my strong will to change.
|
|
meillo@43
|
315 In developing a separate experimental version new approaches can
|
|
meillo@43
|
316 easily be tried out without the need to discuss changes beforehand.
|
|
meillo@43
|
317 In fact, revolutionary changes are hardly possible otherwise.
|
|
meillo@45
|
318 These reasons support the decision to start mmh as a fork of nmh.
|
|
meillo@43
|
319 .P
|
|
meillo@45
|
320 The mmh project provides the basis to implemented and demonstrated
|
|
meillo@45
|
321 the listed ideas without the need to change nmh or its community.
|
|
meillo@43
|
322 Of course, the results of the mmh project shall improve nmh, in the end.
|
|
meillo@27
|
323
|
|
meillo@27
|
324 .U2 "Target Field
|
|
meillo@27
|
325 .P
|
|
meillo@45
|
326 Any effort needs to be targeted towards a specific goal
|
|
meillo@45
|
327 in order to be successful.
|
|
meillo@45
|
328 Following is a description of the imagined typical mmh user.
|
|
meillo@45
|
329 mmh should satisfy his needs.
|
|
meillo@45
|
330 .P
|
|
meillo@43
|
331 The target user of mmh likes Unix and its philosophy.
|
|
meillo@27
|
332 He likes to use programs that are conceptionally appealing.
|
|
meillo@27
|
333 He's familiar with the command line and enjoys its power.
|
|
meillo@27
|
334 He is at least capable of shell scripting and wants to improve his
|
|
meillo@27
|
335 productivity by scripting the mail system.
|
|
meillo@43
|
336 He naturally uses modern email features, like attachments,
|
|
meillo@43
|
337 non-ASCII text, and digital cryptrography.
|
|
meillo@43
|
338 He is able to setup email system components besides mmh,
|
|
meillo@43
|
339 and actually likes the choice to pick the ones he preferes.
|
|
meillo@43
|
340 He has a reasonably modern system that complies to standards,
|
|
meillo@43
|
341 like POSIX and ANSI C.
|
|
meillo@27
|
342 .P
|
|
meillo@43
|
343 XXX common scenarios?
|
|
meillo@8
|
344 .P
|
|
meillo@45
|
345 General assumptions of the project are:
|
|
meillo@8
|
346 .BU
|
|
meillo@45
|
347 Elegance \(en being simplicity, clarity and generality \(en is most important.
|
|
meillo@8
|
348 .BU
|
|
meillo@45
|
349 Concepts are more important than concrete implementations.
|
|
meillo@8
|
350 .BU
|
|
meillo@45
|
351 Time and space optimizations are only useful if absolutely needed to make
|
|
meillo@45
|
352 the software usable.
|
|
meillo@8
|
353 .BU
|
|
meillo@45
|
354 Having a lot of choice is bad.
|
|
meillo@8
|
355
|
|
meillo@27
|
356 .U2 "Work to do
|
|
meillo@45
|
357 .P
|
|
meillo@45
|
358 The general goals for the mmh project are the following:
|
|
meillo@45
|
359 .BU
|
|
meillo@45
|
360 mmh should be perfectly suited for modern emailing, out-of-the-box.
|
|
meillo@45
|
361 This is a necessity to spread among new users.
|
|
meillo@45
|
362 .BU
|
|
meillo@45
|
363 The system shall be of-one-style. It should feel like cast as one.
|
|
meillo@45
|
364 .P
|
|
meillo@45
|
365 To do list:
|
|
meillo@8
|
366 .BU
|
|
meillo@27
|
367 Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
|
|
meillo@8
|
368 task. Mail shall enter mmh's mail storage via the system mail drop
|
|
meillo@8
|
369 and it shall leave mmh via the local \fLsendmail\fP command.
|
|
meillo@8
|
370 .BU
|
|
meillo@8
|
371 Remove any further functions that are not related to mmh's main task.
|
|
meillo@8
|
372 Bulletin board support is on example. Also remove support for ancient
|
|
meillo@8
|
373 technologies, like hardcopy terminals.
|
|
meillo@8
|
374 .BU
|
|
meillo@8
|
375 Refactor the source code to meet modern style criteria. Use
|
|
meillo@8
|
376 standardized library functions when possible.
|
|
meillo@8
|
377 .BU
|
|
meillo@8
|
378 Replace performance optimizations by clear and readable code.
|
|
meillo@8
|
379 .BU
|
|
meillo@8
|
380 Reduce the feature set to the commonly used one, removing
|
|
meillo@8
|
381 corner-cases. Set sane default values.
|
|
meillo@8
|
382 .BU
|
|
meillo@8
|
383 Add better attachment support. Add support for digital signatures and
|
|
meillo@8
|
384 encryption.
|
|
meillo@8
|
385 .BU
|
|
meillo@8
|
386 Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
|
|
meillo@8
|
387 Integrate MIME support deeper and more natural into MH.
|
|
meillo@8
|
388 .BU
|
|
meillo@8
|
389 Provide a ready-to-use setup out-of-the-box.
|
|
meillo@27
|
390
|
|
meillo@27
|
391 .U2 "Methods
|
|
meillo@27
|
392 .P
|
|
meillo@27
|
393 foo
|
