docs/diploma: thesis/tex/4-MasqmailsFuture.tex comparison

comparison thesis/tex/4-MasqmailsFuture.tex @ 293:b4293d0b7062

much much work in ch04! especially for strategy discussion

author	meillo@marmaro.de
date	Sat, 17 Jan 2009 22:34:14 +0100
parents	8341092a7554
children	a014ce012053

comparison

equal deleted inserted replaced

-:83b0f64c0fc6
+:b4293d0b7062
 This chapter identifies requirements for \masqmail\ which are compared against the current code to see what is already fulfilled and what is missing. Then the outstanding work is ordered by relevance and a list of tasks to do is created. The end of this chapter is the evaluation of the best development strategy to get the work done in order to achieve the requirements.
 \section{The goal}
-Before requirements can be identified and further development can be discussed, it is important to clearly specify the goal to achieve. This means: What shall \masqmail\ be like, in, for instance, five years?
+Before requirements can be identified and further development can be discussed, it is important to clearly specify the goal to achieve. This means: What shall \masqmail\ be like in, for instance, five years?
-Should \masqmail\ become more specific to a more narrow niche, or rather become more general and move a bit out of its niche? Or should it even become a totally general \MTA, like \sendmail, \exim, \qmail, and \postfix\ are?
+Should \masqmail\ become more specific to a more narrow niche or rather become more general and move a bit out of its niche? Or should it even become a totally general \MTA\ like \sendmail, \exim, \qmail, and \postfix?
-Becoming completely general seems to be no choice because the competitors are too many and they are already too strong. It would require a strong base of developers and superior features to the competitors. There seems to be no need for another general purpose \MTA\ amoung those four programs. Thus it would most likely remain a try. \person{Venema} stated ``It is becoming less and less likely that someone will write another full-featured Postfix or Sendmail \MTA\ \emph{from scratch} (100 kloc).'' \cite{venema:postfix-growth}. At least \masqmail\ is not going to try that.
+Becoming completely general seems to be no choice because the competitors are too many and they are already too strong. It would require a strong base of developers and superior features to establish. There seems to be no need for another general purpose \MTA\ additional to those four programs. Thus the effort would most likely die a try. \person{Venema} stated ``It is becoming less and less likely that someone will write another full-featured Postfix or Sendmail \MTA\ \emph{from scratch} (100 kloc).'' \cite{venema:postfix-growth}. At least \masqmail\ is not going to try that.
-\masqmail\ was intended to be small and to cover the niche of managing relay over several smart hosts. Small and resource friendly software is still important for workstations, home servers, and especially for embedded computers. Other software that focuses on the niche of managing relay over several smart hosts is not known. Dial-up connections have become rare but mobile computers moving between different networks are popular. So, the niche is still present.
+\masqmail\ was intended to be a small ``real \MTA'' which covers the niche of managing the relay over several smart hosts. Small and resource friendly software is still important for workstations, home servers, and especially for embedded computers. Other software that focuses on the same niche is not known. Dial-up connections have become rare but mobile computers that move between different networks are popular. So, the niche is still present.
 What has changed in general is the security that is needed for software. \person{Graff} and \person{van Wyk} describe the situation well: ``[I]n today's world, your software is likely to have to operate in a very hostile security environment.'' Additionally they say: ``By definition, mail software processes information from potentially untrusted sources. Therefore, mail software must be written with great care, even when it runs with user privileges and even when it does not talk directly to a network.'' \cite[page~33, page~90]{graff03}. As \masqmail\ is mail software and trusted environments become rare, it is best for \masqmail\ to become a secure \MTA.
-In summary, the goal for \masqmail\ is to stay in the current niche with respect to modern usage scenarios, and to become a secure \MTA.
+In summary, the goal for \masqmail\ is to stay in the current niche with respect to modern usage scenarios and to become a secure \MTA.
 A popular email filter framework is \name{amavis} which integrates various spam and malware scanners. The common setup includes a receiving \MTA\ which sends it to \name{amavis} using \SMTP, \name{amavis} processes the mail and sends it then to a second \MTA\ that does the outgoing transfer. Having interfaces to such scanners is nice to have, though. (This setup with two \MTA\ instances is discussed in more detail in section \ref{sec:double-mta-setup}).
 \paragraph{\RF10: Archiving}
-Mail archiving and auditability become more important as email establishes as technology for serious business communication. The ability to archive verbatim copies of every mail coming into and every mail going out of the system, with relation between them, appears to be a goal to achieve.
+Mail archiving and auditability become more important as email establishes as technology for serious business communication. It is also a must for companies in many countries. << SOX >> %fixme: cite SOX
+The ability to archive verbatim copies of every mail coming into and every mail going out of the system, with relation between them, appears to be a goal to achieve.
 \postfix\ for example has a \texttt{always\_bcc} feature, to send a copy of every outgoing mail to a definable recipient. At least this functionality should be given, although a more complete approach, like \qmail\ provides, is preferable. \qmail\ is able to save copies of all sent and received messages and additionally complete \SMTP\ dialogs \cite[page~12]{sill02}.
-<< refer to SOX >> %fixme
 \subsection{Non-functional requirements}
 %fixme: refer to ch01 and ch02
 These non-functional requirements are named ``\NAME{RG}'' for ``requirement, general''.
 \paragraph{\RG1: Security}
-\MTA{}s are critical points for computer security, as they are accessible from external networks. They must be secured with high effort. Properties like the need for high privilege level, from outside influenced work load, work on unsafe data, and demand for reliability, increase the need for security. This is best done by modularization, also called \name{compartementalization}, as described in section \ref{sec:discussion-mta-arch}. \masqmail\ needs to be secure enough for its target field of operation. \masqmail\ is targeted to workstations and private networks, with explicit warning to not use it on permanent online hosts \citeweb{masqmail:homepage2}. But as non-permanent online connections and trustable environments become rare, \masqmail's security should be so good, that it is usable with permanent online connections and in unsafe environments. For example should mails with bad content not break \masqmail.
+\MTA{}s are critical points for computer security, as they are accessible from external networks. They must be secured with high effort. Properties like the need for high privilege level, from outside influenced work load, work on unsafe data, and demand for reliability, increase the need for security. This is best done by modularization, also called \name{compartementalization}, as described in section \ref{sec:discussion-mta-arch}.
+\masqmail\ needs to be secure enough for its target field of operation. \masqmail\ is targeted to workstations and private networks, with explicit warning to not use it on permanent online hosts \citeweb{masqmail:homepage2}. But as non-permanent online connections and trustable environments become rare, \masqmail's security should be so good, that it is usable with permanent online connections and in unsafe environments. For example should mails with bad content not break \masqmail.
 \paragraph{\RG2: Reliability}
 Reliability is the second essential quality property for an \MTA. Mail for which the \MTA\ took responsibility must never get lost while it is within the \MTA{}s responsibility. The \MTA\ must not be \emph{the cause} of any mail loss, no matter what happens. Unreliable \mta{}s are of no value. However, as the mail transport infrastructure are distributed systems, one of the communication partners or the transport medium may crash at any time during mail tranfer. Thus reliability is needed for mail transfer communication too.
 \paragraph{\RG6: Testability}
 Good testability make maintenance easier too, because functionality is directly verifiable when changes are done, thus removing uncertainty. Modularized software makes testing easier, because parts can be tested without external influences. \person{Spinellis} sees testability as a sub-quality of maintainability.
 \paragraph{\RG7: Performance}
-Also called ``efficiency''. Efficient software requires few time and few resources. The merge of communication hardware and its move from service providers to homes and to mobile devices, demand smaller and more resource-friendly software. The amount of mail will be lower, even if much more mail will be sent. More important will be the energy consumption and heat emission. These topics increased in relevance during the past years and they are expected to become more central.
+Also called ``efficiency''. Efficient software requires few time and few resources. The merge of communication hardware and its move from service providers to homes and to mobile devices, demand smaller and more resource-friendly software. The amount of mail will be lower even if much more mail will be sent, thus time performance is less important. \masqmail\ is not a program to be used on large servers, but on small devices. Thus more important for \masqmail\ will be energy and heat saving, maybe also system resources.
+As performance improvements are in contrast to many other quality properties (reliability, maintainability, usability, capability \cite[page~5]{kan03}), jeopardizing these to gain some more performance should not be done. \person{Kernighan} and \person{Pike} state clear: ``[T]he first principle of optimization is \emph{don't}.''\cite[page~165]{kernighan99}. Simplicity and clearness are of higher value.
 \paragraph{\RG8: Availability}
 Availability is important for server programs. They must stay operational by blocking \name{denial of service} attacks and the like.
 \paragraph{\RG9: Portability}
-Source code that compiles and runs on various operation systems is called portable. Portability can be achieved by using standard features of the programming language and common libraries. Basic rules to achieve portable code are defined by \person{Kernighan} and \person{Pike} \cite{kernighan99}. Portable code lets software spread faster.
+Source code that compiles and runs on various operation systems is called portable. Portability can be achieved by using standard features of the programming language and common libraries. Basic rules to achieve portable code are defined by \person{Kernighan} and \person{Pike} \cite{kernighan99}. Portable code lets software spread faster. Portability among the various flavors of \unix\ systems is a goal, because these systems are the ones \MTA{}s run on usually. No special care needs to be taken for non-\unix\ platforms.
 \paragraph{\RG10: Usability}
 Usability, not mentioned by \person{Hafiz} (he focuses on architecture) but by \person{Spinellis} and \person{Kan}, is a property very important from the user's point of view. Software with bad usability is rarely used, no matter how good it is. If substitutes with better usability exist, the user will switch to one of them. Here, usability includes setting up and configuring; and the term ``users'' includes administrators. Having \mta{}s on home servers and workstations requires easy and standardized configuration. The common setups should be configurable with little action by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several common setups.
+<< masqmail as portable app? >>
-\subsection{Thoughts about architecture}
+\subsection{Architecture}
 \label{sec:discussion-mta-arch}
 %todo: what's this section to do with requirements?
 \masqmail's current architecture is monolithic like \sendmail's and \exim's. But more than the other two, is it one block of interweaved code. \exim\ has a highly structured code with many internal interfaces, a good example is the one for authentication ``modules''. %fixme: add ref
 	\begin{center}
 		\vspace*{2ex}
 		%\includegraphics[scale=0.75]{img/callgraph.eps}
 		\includegraphics[scale=0.75]{img/masqmail-3-omitlog5.eps}
 	\end{center}
-	\caption{Internal structure of \masqmail, showed by a call graph}
+	\caption{Internal structure of \masqmail, showed by a call graph. (Logging functions are excluded.)}
+	%fixme: what else is excluded
 	\label{fig:masqmail-arch}
 \end{figure}
 \sendmail\ improved its old architecture by adding the milter interface, to include further functionality by invoking external programs. \exim\ was designed, and is carefully maintained, with a modular-like code structure in mind. \qmail\ started from scratch with a ``security-first'' approach, \postfix\ improved on it, and \name{sendmail X}/\name{MeTA1} tries to adopt the best of \qmail\ and \postfix\ to completely replace the old \sendmail\ architecture. \person{Hafiz} describes this evolution of \mta\ architecture very well \cite{hafiz05}.
 Here follows a description of how far the requirements are already fulfilled by \masqmail.
 \paragraph{\RF1: In/out channels}
-\masqmail's incoming and outgoing channels are the ones required for an \MTA{}s at the moment. They are depicted in figure \ref{fig:masqmail-in-out} on page \pageref{fig:masqmail-in-out}. This is all what is currently needed. But new protocols and mailing concepts are likely to appear (see section \ref{sec:electronic-mail}). \masqmail\ has no support for adding further protocols. Thus modifications at many places in the source are needed to add them though. Today, support for further protocols is not needed, so \masqmail\ is regarded to fulfill \RF1, but the probable future need should be kept in mind.
+The incoming and outgoing channels that \masqmail\ already has are the ones required for an \MTA{}s at the moment. They are depicted in figure \ref{fig:masqmail-in-out} on page \pageref{fig:masqmail-in-out}.
+Support for other protocols seems not to be necessary at the moment, although new protocols and mailing concepts are likely to appear (see section \ref{sec:electronic-mail}).
+Today, other protocols are not needed, so \masqmail\ is regarded to fulfill \RF1.
+But as \masqmail\ has no support for adding further protocols, delaying the work to support them until they are widely used, appears to be the best strategy anyway.
 << smtp submission >> %fixme
 \paragraph{\RF2: Queueing}
 One single mail queue is used in \masqmail; it satisfies all current requirements.
 \paragraph{\RG1: Security}
 \masqmail's current security is bad. However, it seems acceptable for using \masqmail\ on workstations and private networks, if the environment is trustable and \masqmail\ is protected against remote attackers. In environments where untrusted components or persons have access to \masqmail, its security is too low.
 Its author states it ``is not designed to'' such usage \citeweb{masqmail:homepage2}. This is a clear indicator for being careful. Issues like high memory consumption, low performance, and denial-of-service attacks---things not regarded by design---may cause serious problems. In any way, is a security report missing that confirms \masqmail's security level.
-\masqmail\ uses conditional compilation to exclude unneeded functionality from the executable at complile time. Excluding code means excluding all bugs and weaknesses within this code too. This improves security.
+\masqmail\ uses conditional compilation to exclude unneeded functionality from the executable at complile time. Excluding code means excluding all bugs and weaknesses within this code too. Excluding unused code is a good concept to improve security.
 \paragraph{\RG2: Reliability}
 Similar is its reliability not good enough. Situations where only one part of sent message was removed from the queue, and the other part remained as garbage, showed off \citeweb{debian:bug245882}. Problems with large mail and small bandwidth were also reported \citeweb{debian:bug216226}. Fortunately, lost email was no big problem yet, but \person{Kurth} warns:
 \begin{quote}
 There may still be serious bugs in [masqmail], so mail might get lost. But in the nearly two years of its existence so far there was only one time a bug which caused mail retrieved via pop3 to be lost in rare circumstances.
 \masqmail\ uses the filesytem to store the queue, storing the queue in a databases might improve the reliability through better persistence. %fixme
 \paragraph{\RG3: Robustness}
 The logging behavior of \masqmail\ is good, although it does not cover all problem situations. For example, if the queue directory is world writeable by accident (or as action of an intruder), any user can remove messages from the queue or replace them with own ones. \masqmail\ does not even write a debug message in this case. The origin of this problem, however, is \masqmail's trust in its environment.
+%todo: rule of robustness, rule of repair
 \paragraph{\RG4: Extendability}
 \masqmail's extendability is very poor. This is a general problem of monolithic software, but can thus be provided with high effort. \exim\ is an example for good extendability in a monolithic program.
 \paragraph{\RG5: Maintainability}
 \paragraph{\RG6: Testability}
 The testability suffers from missing modularity. Testing program parts is hard to do. Nevertheless, it is done by compiling parts of the source to special test programs. %fixme: what are the names? what do they test?
+This kind of testing is only clean-room testing, so .... %fixme
 \paragraph{\RG7: Performance}
 The performance---efficiency---of \masqmail\ is good enough for its target field of operation, where this is a minor goal.
 \paragraph{\RG8: Availability}
 This applies equal to availability. Hence no further work needs to be done her.
 \paragraph{\RG9: Portability}
 The code's portability is good with view on \unix-like operation systems. At least \name{Debian}, \name{Red Hat}, \NAME{SUSE}, \name{Slackware}, \name{Free}\NAME{BSD}, \name{Open}\NAME{BSD}, and \name{Net}\NAME{BSD} are reported to be able to compile and run \masqmail\ \citeweb{masqmail:homepage2}. Special requirements for the underlying file system are not known. Therefore, the portability is already good.
 \paragraph{\RG10: Usability}
-The usability, from the administrator's point of view, is very good. \masqmail\ was developed to suite a specific, limited job---its configuration does perfect match. The user's view does not reach to the \MTA, as it is hidden behind the \name{mail user agent}.
+The usability, from the administrator's point of view, is very good. \masqmail\ was developed to suite a specific, limited job---its configuration does perfect match. The user's view does not reach to the \MTA, as it is hidden behind the \name{mail user agent}. But configuration could be eased more, by providing configuration generators to be able to use \masqmail\ right ``out of the box'' after running one of several configuration scripts for common setups. This would improve \masqmail's usability for not technical educated people.
 \masqmail\ lacks an interface to plug in modules with additional functionality. There exists no add-on or module system. The code is only separated by function to the various source files. Some functional parts can be included or excluded by conditional compilation. But the \name{ifdef}s are scattered through all the code. This situation needs to be improved by collecting related function into single places that interact through clear interfaces with other parts. Also should these interfaces allow efficient adding of further functionality.
-\subsubsection*{Further \NAME{TODO}s}
-Support for other protocols than \SMTP\ seems not to be necessary at the moment. Adding such support will need lots of work in many parts of \masqmail. Hence delaying this work until the support becomes mandatory, appears to be the best strategy. This way work can be saved if some protocols never become popular.
-Archiving again is preferred to be implemented soon. It does not require much work, but enables all kinds of statistical analysis.
-Performance is a property that is nice to have. But as performance improvements are in contrast to many other quality properties (reliability, maintainability, usability, capability \cite[page~5]{kan03}), jeopardizing these to gain some more performance should not be done. \person{Kernighan} and \person{Pike} state clear: ``[T]he first principle of optimization is \emph{don't}.''\cite[page~165]{kernighan99}. \masqmail\ is not a program to be used on large servers, but on small devices. Thus important for \masqmail\ could be energy and heat saving, maybe also system resources, but not performance. Anyway, simplicity and clearness are of higher value.
-Portability among the various flavors of \unix\ systems is a goal, because these systems are the ones \MTA{}s run on usually. Portability problems with non-\unix\ platforms are primary expected to come from file systems lacking required features. But no special care should be taken here.
-% unix fs on windows
-Configuration could be eased more, by providing configuration generators to be able to use \masqmail\ right ``out of the box'' after running one of several configuration scripts for common setups. This would improve \masqmail's usability for not technical educated people.
-% masqmail as portable app?
 \section{Ways for further development}
+Knowing what needs to be done is only one part, the other is deciding \emph{how} to do it by focusing on a global development strategy.
+\subsection{Possibilities}
 Futher development of software can always go three different ways:
 \begin{enumerate}
 \item[S1:] Improve the current code base.
 \item[S2:] Add wrappers or interposition filters.
 \item[S3:] Redesign the software from scratch and rebuild it.
 \end{enumerate}
-The first two strategies base on the available source code, and can be applied in combination. The third strategy splits from the old code base and starts over again. Wrappers and interposition filters would then be outright included into the new architecture. Parts of existing old code could be used if appropriate.
+The first two strategies base on the available source code, and can be applied in combination. The third strategy splits from the old code base and starts over again. Wrappers and interposition filters would be outright included into a new architecture; they are a subset of a new design. Also parts of existing code can be used in a new design if appropriate.
-The requirements are now regarded, each on its own. Each one is linked to the development strategy that is prefered to reach the specific requirement. Some requirements may be well achievable by using different strategies, so they are linked to all of them. The order of the requirements in the list depend on their level of focus. This linking of strategies to the requirements is shown in table \ref{tab:strategies}.
+The requirements are now regarded each on its own, and are linked to the development strategy that is prefered to reach each specific requirement. If some requirement is well achievable by using different strategies then it is linked to all of them. Implementing encryption (\TODO1) and authentication (\TODO2), for example, are limited to a narrow region in the code. Such features are addable to the current code base without much problem. In contrast can quality properties like reliability (\TODO4), extendability (\TODO6), and maintainability hardly be added to code afterwards---if at all. Security (\TODO3) is addable in a new design, of course, but also with wrappers or interposition filters.
+This linking of strategies to the requirements is shown in table \ref{tab:strategies}. The requirements are ordered by their focus.
 \begin{table}
 	\begin{center}
 		\input{tbl/strategies.tbl}
 	\end{center}
 	\caption{Development strategies and their suitability for requirements}
 	\label{tab:strategies}
 \end{table}
-Next, the best strategy for further development needs to be discovered.
+Next, the best strategy for further development needs to be discovered. Therefore a score for each strategy is obtained now by summing up the focus points of each requirement for which a strategy is prefered. Herefore only positive focus points are regarded, with each plus symbol counting one. Requirements with negative focus are not regareded because they are already or nearly reached, but the view here is on outstanding work. %(Respecting negative focus points leads to a similar result.)
-Implementing \TODO1 encryption and \TODO2 authentication, for example, are limited to a narrow region in the code. Such features are addable to the current code base without much problem. In contrast does adding support for mail processing interfaces to external programs (\TODO5) or support for new protocols require a lot of effort. Changes in many parts of the source code are required. If such large features are needed, it is best to redesign the program's structure and rebuild it.
+Strategy 1 (Improve current code) has a score of 9 points. Strategy 2 (Wrappers and interposition filters) has a score of 7 points. Strategy 3 (A new design) scores on top with 17 points. \St1 and \St2 can be used in combination; the combined score is 13 points. Thus strategy 3 ranges first, followed by the combination of strategy 1 and 2.
-It is a bad idea to implement large retro-fitted features into software that is critical about security and reliability, like \MTA{}s. Worse if these features need changes in the program's structure, like adding mail scanning interfaces (\TODO5) would do. Quality properties, like security (\TODO3) and reliability (\TODO3), as well as extendability (\TODO6) and maintainability, can hardly be added afterwards---if at all.
+This leads to the conclusion, that S3 (A new design) is probably the best strategy for further development. But this result respects only the view on requirements and their relevance. Other factors like development effort and risks are important to think about too. These issues are discussed in the following sections, comparing \St3 against the combination \St1+2.
-A score for each strategy is obtained by summing up the focus points of each requirement for which a strategy is prefered. Herefore only positive focus points are regarded, with each plus symbol counting one. (Respecting negative focus points also leads to a similar result.)
-Strategy 1 (Improve current code), gets a score of 9 points. Strategy 2 (Wrappers and interposition filters) has a score of 7 points. And strategy 3 (A new design) scores on top with 17 points. As \St1 and \St2 may be used in combination, a combined score is important to calculate. The combination has in total 13 points, but it is still beaten by \St3.
-This leads to the conclusion, that S3 (A new design) is probably the best strategy for further development. But this conclusion respects only the view on requirements and their relevance. Other factors like development effort and risks are important to respect too. These issues are discussed in the following sections.
+\subsection{Discussion}
+\subsubsection*{Quality improvements} % PRO
-\subsubsection*{S3: A new design from scratch}
+Most quality properties can hardly be added to a software afterwards. Hence, if reliability, extendability, or maintainability shall be improved, a redesign of \masqmail\ is the best way to take. This is also true for adding modularity with internal and external interfaces, which is highly prefered from the architectural point of view (see section \ref{sec:discussion-mta-arch}).
-A program's structure is primary its architecture. Which is the most influencing design decision, and has the greatest impact on the program's future capabilities. The architecture defines what the program can do, and how it can be used. If the architecture does not fit to the requirements, development will reach a dead end \dots\ further work then will make everything worse. The only good solution is to change the architecture, which, sadly but most likely, means a redesign from scratch.
+The wish for good reliability, extendability, and maintainability inevitably point towards a rewrite using a modern, modular architecture. The need for further features, especially ones that require changes in \masqmail's structure, support the decision for a new design too. Hence a rewrite is enfavored if \masqmail\ should become a modern \MTA, with good quality properties.
-Quality properties, like security (\TODO3) and reliability (\TODO3), as well as extendability (\TODO6) and maintainability, can hardly be added afterwards---if at all. Only structural changes will improve them. Hence, if security, reliability, extendability (to add support for future mail transfer protocols), or maintainability shall be improved, a redesign of \masqmail\ is the only sane way to go.
-%Extendability does suffer from the monolithic architecture and is nearly impossible to improve without changing the programs structure. This property can hardly be retrofitted into software. Extendability is expected become important in the future as new protocols need to be supported.
+\subsubsection*{Security}
-However, a redesign and rewrite of software from scratch is hard. It takes time to design a new architecture, which then must prove it is secure and reliable. As well is much time and work needed to implement the design, test it, fix bugs, and so on. If flaws in the design appear during prototype implementation, it is necessary to start again. Thus the gain of a new design must overweight the effort needed.
+Similar is the situation for security. Security comes from good design, explain \person{Graff} and \person{van Wyk}:
-\person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
-\codeinput{input/masqmail-sloccount.txt}
-The development cost is not relevant for a \freesw\ project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by \person{Oliver Kurth} within four years, in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer, not as employee with eight work-hours per day.
-Given the assumptions that (1) an equal amount of code needs to be produced for a new \masqmail, (2) a third of existing code can be reused plus concepts and knowledge, and (3) development speed is like \person{Kurth}'s. Then it would take between two and three years to have a redesigned new \masqmail\ with the same features that \masqmail\ now has. Less time would be needed if a simpler architecture allows faster development, better testing, and less bugs.
----
-on venema: ``there'll be no second postfix'':
-Yes there will be one, when postfix becomes obsolete, and this day will come as requirements change. See sendmail for example: it had nearly the whole market ... and now it's dying. sendmail once also thought it would be the number 1, forever.
-cf. Tanenbaum vs. Linux: It was too early. Linux' time has not ended, but it will some day.
-anyway, masqmail is not intended to become a second postfix. It's more inteded to become a second qmail, but with a differend target field.
----
-Remarkable is the distribution of the score points between functional and non-functional requirements. S1 (Improve current code) gets most points from functional requirements. Thus it is the best strategy to improve them. S3 (New design), in contrast, scores high for non-functional requirements. Thus it is best chosen to improve the software's quality. S2 (Wrappers and interposition filters) is balanced.
-%\subsubsection*{The need for structural changes}
-%\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
----
-\textbf{A redesign from scratch}
-Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
 \begin{quote}
 Good design is the sword and shield of the security-conscious developer. Sound design defends your application from subversion or misuse, protecting your network and the information on it from internal and external attacks alike. It also provides a safe foundation for future extensions and maintenance of the software.
 %
 %Bad design makes life easier for attackers and harder for the good guys, especially if it contributes to a false sends of security while obscuring pertinent failings.
 \hfill\cite[page 55]{graff03}
 \end{quote}
-All this leads to the wish of a rewrite of \masqmail, using a modern, modular architecture, \emph{if} further features need to be added---features that require changes in \masqmail's structure. But a rewrite is also mandatory, if \masqmail\ should become a modern \MTA, with good quality properties.
+They also recommend to add wrappers and interposition filters \emph{around} applications, but more as repair techniques if it is not possible to design security \emph{into} a software the first way \cite[pages~71--72]{graff03}.
+\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted \emph{into} an architecture.'' \cite[page 64]{hafiz05} (emphasisis added).
-\textbf{Further reasons for a new design}
-impressing  simplicity of qmail: only about 1000 SLOC per file (= about one module). It's obvious what it does. cf. suckless.org
+\subsubsection*{Effort estimation}
+Although a strategy might lead to the best result, one may choose another one if the required effort is too high. The effort for a redesign and rebuild is estimated now.
+\person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
+\codeinput{input/masqmail-sloccount.txt}
+The development cost in money is not relevant for a \freesw\ project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by \person{Oliver Kurth} within four years in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer not as an employee with eight work-hours per day.
+Given the assumptions that (1) an equal amount of code needs to be produced for a new designed \masqmail, (2) a third of existing code can be reused plus concepts and knowledge, and (3) development speed is like \person{Kurth}'s. Then it would take between two and three years for one programmer to produce a redesigned new \masqmail\ with the same features that \masqmail\ now has. Less time would be needed if a simpler architecture allows faster development, better testing, and less bugs. Of course more developers would speed it up too.
+\subsubsection*{Risks}
+If the gained result still overwights the development effort, risks are something more to consider.
+A redesign and rewrite of software from scratch is hard. It takes time to design a new architecture, which then must prove that it is as good as expected. As well is much time and work needed to implement the design, test it, fix bugs, and so on. If flaws in the design appear during prototype implementation, it is necessary to start again.
+Such a redesign can fail at many points and it is for long unclear if the result is really better than what is already existent. Even if it is working, it is still not matured then.
+One thing is clear: Starting a redesign and rebuild \emph{is} a risky decision.
+\subsubsection*{Existing code is precious}
+If a new design needs much effort and additionally is a risk, what about the alternative then?
+Adding new functionality to an existing code base seems to be a secure and cheap strategy. The existing code is known to work and features can often be added in small increments. The risk of wasted effort if a new design fails is hardly existent. And the faults in the current design are already made and most probably fixed.
+Also functionality that is hard to add incrementally into the application, like support for new protocols, may be addable by ``translation programs'' to the outside. \masqmail\ can be secured to a huge amount by guarding it with wrappers that block attackers. Spam and malware scanners can be included by running two instances of \masqmail. All those methods base on the current code which they can indirectly improve.
+The required effort is probably under thirty percent of a new design and work directly shows results. These are strong arguments against a new design.
+%XXX
+\subsubsection*{Repairing}
+Repair strategies are only useful in the short time view and in times of trouble. But if the future is bright, one does best by investing. Here it means investing time in redesigning to build up a more modern product. cf. ch02: the future is bright!
+\masqmail\ should have already been redesigned in 2002 or so, when the old design was still quite suitable ... it already delayed too long.
+Clinging to much to existing code will be no help, it is an indicator for fear. Having the courage to through bad code away to make it better, shows the view forward.
+Further development on base of current code needs to improve the quality properties too. Some quality requirements can be achieved by adding wrappers or interposition filters from the outside. For those is the development effort approximately equal to a solution by new design. But for quality requirements like extendability or maintainability, the effort does increase with expotentionel rate as development proceeds. But without those properties development of a software will most likely come to a dead end.
+\subsubsection*{A guard against dead ends}
+But a new design does also protect against dangers. Changing requirements are a risk for software if it does not evolve with them. A famous example is \sendmail, which had nearly a monopoly for a long time. But when security became important \sendmail\ was only repaired, instead of removing the problem sources. Thus security problems reappeared and over the years \sendmail's market share shrinked as more secure \MTA{}s became available. %fixme: declined ??
+\sendmail's reaction to the changed requirements, in form of \name{sendmail X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s.
+Redesigning a software as requirements change helps keeping it alive. % add quote: ``one thing surely remains: change'' (something like that)
+Another danger is complexity which is likely to appear by constantly working on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} advertizes a philosophy of small and simple software by following the thoughts of the \unix\ inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code reduces bugs and, as the code function becomes obvious, it is a large step towards security.
+\subsubsection*{Modularity}
+The (by design) modular structure makes it also easy to add further functionality. \person{Sill} for example describes integrating the \name{amavis} filter framework into the \qmail\ system can be done by renaming the \name{qmail-queue} module to \name{qmail-queue-real} and renaming the \name{amavis} to \name{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in \qmail\ needs to be changed. This is a very admirable approach, but only possible in a modular system that consists of independent executables.
+Extendability does suffer from the monolithic architecture and is nearly impossible to improve without changing the programs structure. This property can hardly be retrofitted into software. Extendability is expected become important in the future as new protocols need to be supported.
+Hence, to be able to develop \masqmail\ for a long time, it is a must to refactor the existing code with the intention to modularize it. A new design is similar to such a throughout refactoring, except without basing on current code.
+\subsubsection*{Split between function and quality}
+Remarkable is the distribution of the score points between functional and non-functional requirements. S1 (Improve current code) gets most points from functional requirements. Thus it is the best strategy to improve them. S3 (New design), in contrast, scores high for non-functional requirements. Thus it is best chosen to improve the software's quality. S2 (Wrappers and interposition filters) is balanced.
+a question of order:
+- repair: first function, then quality
+- redesign: first quality, then function
+\subsubsection*{The break even}
+The effort needed is much smaller than for a new design plus improvements on the first view. But to have similar quality properties in four years, a \masqmail\ that is based on current code will probably require as much effort as a new designed \masqmail\ will take. For all further development afterwards, the new design will scale nearly linear while the old code will require exponentiell more work.
+It \emph{is} important to design from scratch somewhen! But when?
+\subsubsection*{The problem with ``good enough''}
 do not try to safe obsolete stuff. This will not work (see sendmail).
 It is often done in commercial software, when it's about making money. Free software with volunteer programmers in contrast care about good software..
 If the design is bad, one should never hesitate to abandonne obsolete stuff and build it from scratch. (cf. makefiles and tab).
 But making a cut is hard, as it is still ``good enough''.
+(It already is too late.)
----
-repair strategies is only useful in the short time view and for hard times. but if the future is bright, one must invest. here it means redesigning to build up a more modern product. cf. ch02: the future is bright!
-Masqmail should have been redesigned in 2002 or so, when the old design was still quite suitable ... it already delayed too long.
+\subsubsection*{Bonus: Good software, good feelings}
-Clinging to much to existing code will be no help, it is an indicator for fear. Having the courage to through bad code away to make it better, shows the view forward.
----
 repairing leaves a worse feeling. Free Software ``sells'' if it has a good userbase. Although qmail is somehow outdated and its author has released no new version since about 10 years, qmail has a very strong userbase and community.
 Good design, concepts and philosophy gives users good feelings and faith for the software. They become interested in using it and to contribute.
 The goal is good software. The wish to do good work is the motivation volunteers have. Work plans that lead to a good product will motivate volunteers to help with it. Hence more helpers may make the 2,5 man years for the new design, even become less absolute time than, few helping people that try to improve the existing code.
-\subsubsection*{S\,1 and S\,2: Improve old code and add wrappers}
-FIXME
 \section{Result}
+A program's structure is primary its architecture. Which is the most influencing design decision, and has the greatest impact on the program's future capabilities. The architecture defines what the program can do, and how it can be used. If the architecture does not fit to the requirements, development will reach a dead end \dots\ further work then will make everything worse. The only good solution then is to change the architecture, which, sadly but most likely, means a redesign from scratch.
 The most needed features---authentication and encryption---can be added to the current code base with changes in only few parts of the source. These changes should be made soon. Archiving of mail is another feature to add then. More complete logging coverage, reporting of unsafe environment, and fixing high risk security flaws are quality improvements to do. All this work should be done on basis of the current code.
-All other work depends on how the plans for \masqmail's future look like.
-What shall \masqmail\ be like, in, for instance, five years?
+\begin{enumerate}
-Two ways of further development come to mind.
+\item
+Stick to the old architecture and try to add features as possible. This approach needs less effort to be spent, because a working code is already present. Further development is only adding small increments to a exiting code base. But the further development goes, the larger is the work needed to add more functionality, and the more bugs will appear, caused by the increasing complexity. Quality of the software will decrease, because lacking of clear internal structure encourages further work to be quick fixes rather than good solutions.
-First, stick to the old architecture and try to add features as possible. This approach needs less effort to be spent, because a working code is already present. Further development is only adding small increments to a exiting code base. But the further development goes, the larger is the work needed to add more functionality, and the more bugs will appear, caused by the increasing complexity. Quality of the software will decrease, because lacking of clear internal structure encourages further work to be quick fixes rather than good solutions.
+\item
-Second, the way of designing \masqmail\ from scratch and rebuilding it. A lot of time and work is required to do this. Additionally, a new design from scratch introduces new risks: Is the design really better? Was thought of everything? Will there come problems not foreseeable now? Starting from scratch also means a step back. Against these disadvantages stands the gain from the new design: Further development will be easier and probably faster, overall quality will be better and easier to keep up, and dead ends for further development are better avoidable.
+The way of designing \masqmail\ from scratch and rebuilding it. A lot of time and work is required to do this. Additionally, a new design from scratch introduces new risks: Is the design really better? Was thought of everything? Will there come problems not foreseeable now? Starting from scratch also means a step back. Against these disadvantages stands the gain from the new design: Further development will be easier and probably faster, overall quality will be better and easier to keep up, and dead ends for further development are better avoidable.
+\end{enumerate}
-Essentially, the decision for one of the ways depends on the question whether \masqmail\ should remain what it is, then the first option seems to be the right one to choose. Or whether \masqmail\ should become a modern \mta\ which is able to expand to include new functionality, then the second option is to choose.
-Security, extendability, and the other quality properties appear to have also crucial importance in this decision. If they are required for future versions of \masqmail, then a new design is a must.
-\person{Graff} and \person{van Wyk} describe the situation well: ``[I]n today's world, your software is likely to have to operate in a very hostile security environment.'' \cite{graff03}. An old-fashioned \mta\ depends, for sure, on a dieing branch, called \name{trusted environments}. And nothing other than a fresh and better design will help to survive.
 The suggested further development plan for \masqmail\ is:

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 293:b4293d0b7062