1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Mon Dec 29 20:16:58 2008 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Mon Dec 29 21:43:52 2008 +0100
     1.3 @@ -245,11 +245,12 @@
     1.4  \subsubsection*{Discussion on architecture}
     1.5  
     1.6  %fixme: why is there a need for a new arch??
     1.7 +Adding authentication and encryption support is limited to a narrow region in the code. Such features are addable to the current code base without much problem. In contrast do support for new protocols or mail processing interfaces to external programs require a lot of effort. Changes in many parts of the source code are required. It is no good idea to implement large retro-fitted features in a software that is critical in security and reliability, like \masqmail. Worse if these features need changes in the program's structure, like adding mail scanning interfaces would do.
     1.8  
     1.9 +If such features are needed, it is best do redesign the program's structure and rebuild it. A program's structure is primary its architecture. Which is probably the most influencing design decision, and has the greatest impact on the program's future capabilities. The architecture defines what the program can do, how it can be used. If the architecture does not fit the requirements, develpement reached a dead end \dots\ further work will make everything worse. The only good solution is to change the architecture, which, sadley but most likely, means a redesign from scratch.
    1.10  
    1.11 -A program's architecture is probably the most influencing design decision, and has the greatest impact on the program's future capabilities. %fixme: search quote ... check if good
    1.12 -
    1.13 -\masqmail's current artitecture is monolitic like \sendmail's and \exim's. But more than the other two, is it one block of interweaved code. \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules. \exim\ has a highly structured code with many internal interfaces, like the one for supported authentication ``modules''. \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
    1.14 +\masqmail's current artitecture is monolitic like \sendmail's and \exim's. But more than the other two, is it one block of interweaved code. \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules. \exim\ has a highly structured code with many internal interfaces, a good example is the one for authentication ``modules''. %fixme: add ref
    1.15 +\masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
    1.16  
    1.17  Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure.
    1.18  
    1.19 @@ -257,25 +258,21 @@
    1.20  	\begin{center}
    1.21  		\input{input/masqmail-arch.tex}
    1.22  	\end{center}
    1.23 -	\caption{Internal architecture of \masqmail}
    1.24 +	\caption{Internal structure of \masqmail}
    1.25  	\label{fig:masqmail-arch}
    1.26  \end{figure}
    1.27  
    1.28  \sendmail\ improved its old architecture, for example by adding the milter interface. \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} \cite{hafiz05}. describes this evolution of \mta\ architecture very well.
    1.29  
    1.30 -Every one of the popular \MTA{}s is more modular, or became more modular over time, than \masqmail\ is. Modern requirements like spam protection and future requirements like the use of new mail transport protocols demand modular designs for keeping the software simple. Simplicity is a key property for security.
    1.31 +Every one of the popular \MTA{}s is more modular, or became more modular over time, than \masqmail\ is. Modern requirements like spam protection and future requirements like---probably---the use of new mail transport protocols demand modular designs for keeping the software simple. Simplicity is a key property for security. ``[T]he essence of security engenieering is to build systems that are as simple as possible.''\cite[page 45]{graff03}
    1.32  
    1.33 -\person{Hafiz} agrees:
    1.34 +\person{Hafiz} agrees: ``The goal of making software secure can be better achieved by making the design simple and easier to understand and verify.''\cite[page 64]{hafiz05} He identifies the security of \qmail\ to come from it's \name{compartmentalization}, which goes hand in hand with modularity:
    1.35  \begin{quote}
    1.36 -The goal of making software secure can be better achieved by making the design simple and easier to understand and verify. \cite[page64]{hafiz05}
    1.37 +A perfect example is the contrast between the feature envy early \sendmail\ architecture implemented as one process and the simple, modular architecture of \qmail. The security of \qmail\ comes from its compartmentalized simple processes that perform one task only and are therefore testable for security. \cite[page 64]{hafiz05}
    1.38  \end{quote}
    1.39 -He identifies the security of \qmail\ to come from it's \name{compartmentalization}, which goes hand in hand with modularity:
    1.40 -\begin{quote}
    1.41 -A perfect example is the contrast between the feature envy early \sendmail\ architecture implemented as one process and the simple, modular architecture of \qmail. The security of \qmail\ comes from its compartmentalized simple processes that perform one task only and are therefor testable for security. \cite[page 64]{hafiz05}
    1.42 -\end{quote}
    1.43 -As well does \person{Dent}: ``The modular architecture of Postfix forms the basis for much of its security.''\cite[page 7]{dent04}
    1.44 +As well does \person{Dent}: ``The modular architecture of Postfix forms the basis for much of its security.''\cite[page 7]{dent04} Modularity is also needed to satisfy modern \MTA\ requirements, in providing a clear interface to add functionality without increasing the overall complexity much.
    1.45  
    1.46 -Modularity is needed for supporting modern \MTA\ requirements, providing a clear interface to add further functionality without increasing the overall complexity much. Modularity is also an enabler for security. Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
    1.47 +Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
    1.48  \begin{quote}
    1.49  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 maintainance of the software.
    1.50  %
    1.51 @@ -283,18 +280,34 @@
    1.52  \cite[page 55]{graff03}
    1.53  \end{quote}
    1.54  
    1.55 -\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
    1.56  
    1.57 -All this leads to one logical step: The rewrite of \masqmail\ using a modern, modular architecture, to get a modern \MTA\ satisfying nowadays needs.
    1.58 +All this leads to a rewrite of \masqmail, using a modern, modular architecture, \emph{if} further features need to be added, ones that require changes in \masqmail's structure. As well is a rewrite needed, if \masqmail\ should become a modern \MTA, with good quality properties.
    1.59  
    1.60 +But redesigning and rewriting a software from scratch is hard. It takes time to design a new architecture, which must prove it is secure and reliable. And much time and work is needed to implement the design, test it, fix bugs, and so on. Thus the gain of a new design must overweight the effort needed to spend.
    1.61  
    1.62 +\person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
    1.63 +{\small
    1.64 +\begin{verbatim}
    1.65 +Total Physical Source Lines of Code (SLOC)                = 9,041
    1.66 +Development Effort Estimate, Person-Years (Person-Months) = 2.02 (24.22)
    1.67 + (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
    1.68 +Schedule Estimate, Years (Months)                         = 0.70 (8.39)
    1.69 + (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
    1.70 +Estimated Average Number of Developers (Effort/Schedule)  = 2.89
    1.71 +Total Estimated Cost to Develop                           = $ 272,690
    1.72 + (average salary = $56,286/year, overhead = 2.40).
    1.73 +SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
    1.74 +\end{verbatim}
    1.75 +}
    1.76 +The development cost is not relevant for a \freesw\ project of volunteer developers, but the time needed is. About 24 man-months are estimated. The current code base was written almost completely by Oliver \person{Kurth} within four years, in his spare time. This means he needed around twice as much time.
    1.77  
    1.78 -<< what would be needed (effort) >>
    1.79 +Given the asumptions that an equal amount of code is to be produced, a third of existing code can be reused plus concepts and experience, and development speed is like \person{Kurth}'s. Then it would take about two years to have a redesigned new \masqmail\ with the same features. Less time could be needed if a simpler architecture allows faster develpement, better testing, and less bugs.
    1.80  
    1.81 -The next section is a design
    1.82 +The further section describes a new modern design for \masqmail. A plan to rewrite \masqmail\ from scratch.
    1.83  
    1.84  
    1.85  
    1.86 +%\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
    1.87  
    1.88  
    1.89