1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Wed Dec 31 14:58:43 2008 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Wed Dec 31 17:28:42 2008 +0100
     1.3 @@ -225,7 +225,7 @@
     1.4  
     1.5  \subsubsection*{Fulfilled requirements}
     1.6  
     1.7 -\masqmail's incoming and outgoing channels are the common ones: the \texttt{sendmail} command and \SMTP\ for incoming mail; local delivery, piping to commands, and \SMTP\ for outgoing mail. Support for other protocols is not available. To add it, modifications at many places in the source are needed.
     1.8 +\masqmail's incoming and outgoing channels are the ones common to most \MTA{}s: the \texttt{sendmail} command and \SMTP\ for incoming mail; local delivery, piping to commands, and \SMTP\ for outgoing mail. Support for other protocols is not available. To add it, modifications at many places in the source are needed.
     1.9  
    1.10  One single mail queue is used in \masqmail. The envelope and mail headers are generated when the mail is put into the queue. Aliasing is done on delivery, after the route to be used was determined. Headers may be rewritten then. These parts do all provide the functionality required.
    1.11  
    1.12 @@ -267,7 +267,7 @@
    1.13  
    1.14  Archiving again is prefered to be implemented soon. It does not require much work, but enables all kinds of statistical analysis. Also it is a requirement for companies to archive their mail communication.
    1.15  
    1.16 -Non-functional requirements need improvements too.
    1.17 +Non-functional requirements need improvement too.
    1.18  
    1.19  \masqmail's security is bad and limits it thus to a field of operation that shrinks. Security becomes more important and networking and interaction increases. Save and trusted environment become rare. Improving security is an important thing to do in future.
    1.20  
    1.21 @@ -283,30 +283,35 @@
    1.22  
    1.23  
    1.24  
    1.25 +\subsubsection*{The need for structural changes}
    1.26  
    1.27 +Adding authentication and encryption support, for example, is 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 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 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.28  
    1.29 +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, and how it can be used. If the architecture does not fit the requirements, develpement reached a dead end \dots\ further work on this basis will make everything worse. The only good solution is to change the architecture, which, sadley but most likely, means a redesign from scratch.
    1.30  
    1.31 -\section{Discussion on architecture}
    1.32 +Quality properties, like security and reliability, as well as extendability and maintainablity, 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.33  
    1.34 -%fixme: why is there a need for a new arch??
    1.35 -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.36 +%\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
    1.37  
    1.38 -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.39 +
    1.40 +
    1.41 +
    1.42 +\section{Discussion on MTA architecture}
    1.43  
    1.44  \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.45  \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
    1.46  
    1.47 -Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure.
    1.48 +Figure \ref{fig:masqmail-arch} is a call graph generated from \masqmail's source code. It gives a impression of how interweaved the internal structure is.
    1.49  
    1.50  \begin{figure}
    1.51  	\begin{center}
    1.52  		\input{input/masqmail-arch.tex}
    1.53  	\end{center}
    1.54 -	\caption{Internal structure of \masqmail}
    1.55 +	\caption{Call graph of \masqmail\ to show its internal structure}
    1.56  	\label{fig:masqmail-arch}
    1.57  \end{figure}
    1.58  
    1.59 -\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.60 +\sendmail\ improved its old architecture, for example by adding the milter interface, to add further functionality by invocing 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} \cite{hafiz05}. describes this evolution of \mta\ architecture very well.
    1.61  
    1.62  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.63  
    1.64 @@ -314,7 +319,9 @@
    1.65  \begin{quote}
    1.66  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.67  \end{quote}
    1.68 -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.69 +As well does \person{Dent} for \postfix: ``The modular architecture of Postfix forms the basis for much of its security.'' \cite[page 7]{dent04}
    1.70 +
    1.71 +Modularity is also needed to satisfy modern \MTA\ requirements, in providing a clear interface to add functionality without increasing the overall complexity much.
    1.72  
    1.73  Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
    1.74  \begin{quote}
    1.75 @@ -325,9 +332,9 @@
    1.76  \end{quote}
    1.77  
    1.78  
    1.79 -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.80 +All this leads to the wish of 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. But a rewrite is also needed, if \masqmail\ should become a modern \MTA, with good quality properties.
    1.81  
    1.82 -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.83 +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. As well is much time and work needed to implement the design, test it, fix bugs, and so on. Thus the gain of a new design must overweight the effort needed.
    1.84  
    1.85  \person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
    1.86  {\small
    1.87 @@ -343,15 +350,14 @@
    1.88  SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
    1.89  \end{verbatim}
    1.90  }
    1.91 -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.92 +The development cost is not relevant for a \freesw\ project of volunteer developers, but the development time 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.93  
    1.94  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.95  
    1.96 -The further section describes a new modern design for \masqmail. A plan to rewrite \masqmail\ from scratch.
    1.97  
    1.98  
    1.99  
   1.100 -%\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
   1.101 +
   1.102  
   1.103  
   1.104  
   1.105 @@ -363,32 +369,27 @@
   1.106  
   1.107  \section{Result}
   1.108  
   1.109 -Directions to go
   1.110 +The most needed features, authentication and encryption, can be added to the current code base with changes only some areas. 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 security flaws are quality improvements to do. All this work should be done on basis of the current code.
   1.111  
   1.112 -Now how could \masqmail\ be like in, say, five years?
   1.113 +The implementation of authentication and encryption are covered in the next chapter within this thesis.
   1.114  
   1.115 -This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
   1.116 +All other work depends on how \masqmail's future plans look like.
   1.117  
   1.118 +Now, how could \masqmail\ be like, in five years, for instance? Two ways of further development come to mind.
   1.119  
   1.120 +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 alreads 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 instead of requiring good solutions by design.
   1.121  
   1.122 +Second, designing \masqmail\ from scratch and rebuilding it. A lot of time and work is required to do so. Additionally, a new design from scratch introduces new risks: Is the design really better? Was thought of everything? Will there come problems not seeable now? Starting from scratch also means a step back. Against these disadvantages stands the gain of 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 can be avoided.
   1.123  
   1.124 -1) fix the current version
   1.125 +Finally, 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 \masqmail\ should become a modern \mta\ which is able to expand to include new functionality, then the second option is to choose.
   1.126  
   1.127 +Security, extendability, and the other quality properties appear to have crucial importance in this decision. If they are important for future versions of \masqmail, a new design is a must.
   1.128  
   1.129 -2) create a new one
   1.130 -But how is the effort of this complete rewrite compared to what is gained afterwards?
   1.131 -<< would one create it at all? >>
   1.132 +\person{Graff} and \person{van Wyk} describe the situation best: ``[I]n today's world, your software is likely to have to operate in a very hostile security environment.'' \cite{graff05} An old-fashioned \mta\ depends, for sure, on a dieing branch, called \name{trusted envrironments}. And nothing other than a fresh and better design will help to survive.
   1.133  
   1.134 +The suggested further development on \masqmail\ is: First add the most needed features, being authentication and encryption, to the current code base. This is the short time goal. Second---and this is the long time goal---design a new architecture that satisfies the requirements identified, especially the quality requirements. The implementation of this design shall then, after being usable and throughoutly tested, superseed the old \masqmail.
   1.135  
   1.136 -pro---contra
   1.137 +This action is similar to the change from \sendmail\ to \name{sendmail X}/\name{MeTA1}, except the \sendmail\ change was too late. The plan is to first do the most needed stuff on the old design to make it still usable; then design a new version from scratch, for the future.
   1.138  
   1.139 +The following chapter \ref{chap:improvements} is about the work on the current code base, to reach the short time goals. The chapter afterwards, numbered \ref{chap:new-design}, then introduces a new, modern design for future versions of \masqmail.
   1.140  
   1.141 -
   1.142 -
   1.143 -<< short term goals --- long term goals >>
   1.144 -
   1.145 -do it like sendmail: first do the most needed stuff on the old design to make it still usable. Then design a new version from scratch, for the future.
   1.146 -
   1.147 -<< which parts to take out and do within the thesis >>
   1.148 -
   1.149 -