1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 14 21:39:50 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 14 21:40:38 2009 +0100
     1.3 @@ -1,29 +1,23 @@
     1.4  \chapter{\masqmail's present and future}
     1.5  
     1.6 -This chapter \dots %fixme write text here
     1.7 +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.
     1.8  
     1.9  
    1.10 +\section{The goal}
    1.11  
    1.12 +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?
    1.13  
    1.14 ----
    1.15 +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?
    1.16  
    1.17 -\textbf{Full featured or stripped down}
    1.18 +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.
    1.19  
    1.20 -Here shows a misfit off: On the one hand does \masqmail\ want to be a \sendmail\ replacement. But on the other hand, is it not designed to be used like \sendmail. If \masqmail\ is inteded to replace other \MTA{}s, then one may replace another one with it. Hence it must be secure enough. It either needs the security features or must drop the unsecure funtionality. The second option, however, leads to being \emph{no} replacement for other \MTA{}s. It is a valid decision to not be a replacement for \sendmail\ or thelike, but this is a design decision---the change of a primary goal.
    1.21 +\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.
    1.22  
    1.23 -If \masqmail\ should be an \MTA\ to replace others, a switch to a better suited architecture that provides good security and extendability by design, seems required. But if \masqmail\ is wanted to cover some special jobs, not to replace common \MTA{}s, then its architecture depends on the special requirements of the specific job; \MTA\ architectures, like discussed by \person{Hafiz}, may be inadequate.
    1.24 +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.
    1.25  
    1.26 -What future is to choose for \masqmail---one to be a full featured \MTA, or one to be a stipped down \MTA\ for special jobs?
    1.27 +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.
    1.28  
    1.29 -The critical point to discuss upon is surely the listening on a port to accepte messages from outside via \NAME{SMTP} (herafter also refered to as the \NAME{SMTP}-in channel). This feature is required for an \MTA\ to be a \name{smart host}, to relay mail. But running as deamon and listening on a port requires much more security effort, because the program is put in direct contact with attackers and other bad guys.
    1.30  
    1.31 -\MTA{}s without \SMTP-in channels can not receive mail from arbitrary outside hosts. They are only invoked by local users. This lowers the security need a lot---however, security is a general goal and still required, but on a lower level. Unfortunately, as they do not receive mail anymore (except by local submission), they are just better \name{forwarders} that are able to send mail directly to the destination.
    1.32 -
    1.33 -This is not what \masqmail\ was intended to be. Programs that cover this purpose are available; one is \name{msmtp}.
    1.34 -
    1.35 -\masqmail\ shall be a complete \mta. It shall be able to replace ones like \sendmail.
    1.36 -
    1.37 ----
    1.38  
    1.39  
    1.40  
    1.41 @@ -31,7 +25,7 @@
    1.42  \section{Requirements}
    1.43  \label{sec:mta-requirements}
    1.44  
    1.45 -This section identifies the requirements for a modern \masqmail. Most of them will apply to modern \MTA{}s in general.
    1.46 +This section identifies the requirements for \masqmail\ to reach the above defined goal. Most of the requirements will apply to modern \MTA{}s in general.
    1.47  
    1.48  
    1.49  
    1.50 @@ -429,7 +423,7 @@
    1.51  \item[S3:] Redesign the software from scratch and rebuild it.
    1.52  \end{enumerate}
    1.53  
    1.54 -The first two strategies base on the available source code, and can be applied in combination. The third strategy abandonnes the old code and starts over again. Wrappers and interposition filters would then be outright included into the new architecture.
    1.55 +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.
    1.56  
    1.57  
    1.58  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}.
    1.59 @@ -442,23 +436,30 @@
    1.60  	\label{tab:strategies}
    1.61  \end{table}
    1.62  
    1.63 -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 new protocols or mail processing interfaces to external programs (\TODO5) require a lot of effort. Changes in many parts of the source code are required. 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.
    1.64  
    1.65 -If such large features are needed, it is best to redesign the program's structure and rebuild it. 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.
    1.66 +Next, the best strategy for further development needs to be discovered.
    1.67 +
    1.68 +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.
    1.69 +
    1.70 +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.
    1.71 +
    1.72 +
    1.73 +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.)
    1.74 +
    1.75 +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.
    1.76 +
    1.77 +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.
    1.78 +
    1.79 +
    1.80 +
    1.81 +
    1.82 +
    1.83 +\subsubsection*{S3: A new design from scratch}
    1.84 +
    1.85 +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.
    1.86  
    1.87  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.
    1.88  
    1.89 -
    1.90 -
    1.91 -Next, the best strategy for further development needs to be discovered. The focus points of the requirements, for which a strategy is prefered, are summed up to obtain a score for the strategies. Herefor only positive focus points are regarded, with each plus symbol counting one. (Respecting negative focus points also leads to a similar result.)
    1.92 -
    1.93 -S1: Improve current code, gets a score of 9 points. S2: Wrappers and interposition filters, has a score of 7 points. S3: New design, scores on top with 17 points. As S1 and S2 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 S3.
    1.94 -
    1.95 -This leads to the conclusion, that S3 (A new design) is the best strategy for further development, from this point of view.
    1.96 -
    1.97 -
    1.98 -\subsubsection*{S3: A new design from scratch}
    1.99 -
   1.100  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.
   1.101  
   1.102  \person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
   1.103 @@ -515,7 +516,7 @@
   1.104  
   1.105  
   1.106  
   1.107 -\subsubsection*{A redesign from scratch}
   1.108 +\textbf{A redesign from scratch}
   1.109  
   1.110  Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
   1.111  \begin{quote}
   1.112 @@ -528,7 +529,7 @@
   1.113  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.
   1.114  
   1.115  
   1.116 -\subsubsection*{Further reasons for a new design}
   1.117 +\textbf{Further reasons for a new design}
   1.118  
   1.119  impressing  simplicity of qmail: only about 1000 SLOC per file (= about one module). It's obvious what it does. cf. suckless.org
   1.120  
   1.121 @@ -562,6 +563,19 @@
   1.122  
   1.123  
   1.124  
   1.125 +\subsubsection*{S\,1 and S\,2: Improve old code and add wrappers}
   1.126 +
   1.127 +
   1.128 +FIXME
   1.129 +
   1.130 +
   1.131 +
   1.132 +
   1.133 +
   1.134 +
   1.135 +
   1.136 +
   1.137 +
   1.138  \section{Result}
   1.139  
   1.140  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.