1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 11 14:07:23 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 11 14:07:48 2009 +0100
     1.3 @@ -339,29 +339,32 @@
     1.4  
     1.5  The functional requirements that receive highest attention are \RF6: authentication, \RF7: encryption, and \RF8: spam handling. Of the non-functional requirements, \RG1: security, \RG2: reliability, and \RG4: Extendability, rank highest.
     1.6  
     1.7 -These tasks to do are presented in more detail now.
     1.8 -
     1.9 +These tasks are presented in more detail now. They are sorted in the suggested order to work on them..
    1.10  
    1.11  
    1.12  \subsubsection*{\TODO1: Encryption (\RF7)}
    1.13 -Encryption by using \NAME{STARTTLS} is definitely needed and should be added soon. This feature is essential for providing privacy.
    1.14 +Encryption is chosen first, as it is essential to providing privacy. Encryption by using \NAME{STARTTLS} is definitely needed and should be added soon. Without support for it, encrypted email transfer is hardly possible.
    1.15  
    1.16 -\subsubsection*{\TODO2: Spam handling (\RF8)}
    1.17 -\subsubsection*{\TODO6: Authentication (\RF6)}
    1.18 -Authentication of incoming \SMTP\ connections is definitely needed and should be added soon. It is essential for restricting relaying.
    1.19 -
    1.20 -As authentication can be a guard against spam, filter facilities have lower priority. But basic spam filtering and interfaces for external tools should be implemented in future. Content checking should be left over to the \NAME{MDA}, to deal with it during local delivery.
    1.21 +\subsubsection*{\TODO2: Authentication (\RF6)}
    1.22 +Authentication of incoming \SMTP\ connections also needed and should be added soon. It is important for restricting access to prevent relaying. For workstations and local networks, it has only medium importance and address-based authentication is sufficient in most times. But secret-based authentication is mandatory to receive mail from the internet.
    1.23  
    1.24  \subsubsection*{\TODO3: Security (\RG1)}
    1.25 -\masqmail's security is bad, thus the program is forced into a limited field of operation. The field of operation even shrinks, as security becomes more important and networking and interaction increases. Save and trusted environment become rare. Improving security is an important thing to do.
    1.26 +\masqmail's security is bad, thus the program is forced into a limited field of operation. The field of operation even shrinks, as security becomes more important and networking and interaction increases. Save and trusted environment become rare.
    1.27  
    1.28 +Compartementalization, ref secure coding, postfix ...
    1.29 +
    1.30 +Improving security is an important thing to do. Especially, \masqmail's security should be tested throughout to get a definitive view how good it really is and where the weak spots are.
    1.31  
    1.32  \subsubsection*{\TODO4: Reliability (\RG2)}
    1.33 -Reliability is also to improve. It is a key quality property for an \MTA, and not good enough in \masqmail. Additionally, the program is lacking robustness. Checking the environment and reporting bad characteristics is wanted. Especially improving robustness in relation to the queue is favorable; applying ideas of \name{crash-only software}\cite{candea03} will be a good step.
    1.34 +Reliability is also to improve. It is a key quality property for an \MTA, and not good enough in \masqmail. Reliability is strong related to the queue, thus improvements there are favorable. Applying ideas of \name{crash-only software} \cite{candea03} will be a good step. \person{Candea} and \person{Fox} see in killing the process the best way to stop a running program. Doing so inevitably demands for good reliability of the queue, and the startup inevitably demands for good recovery. The critical situations for reliability are nothing special anymore, they are common. Hence they are regulary tested and will definately work.
    1.35  
    1.36 +\subsubsection*{\TODO5: Spam handling (\RF8)}
    1.37 +As authentication can be a guard against spam, filter facilities have lower priority. But basic spam filtering and interfaces for external tools should be implemented in future.
    1.38  
    1.39 -\subsubsection*{\TODO5: Extendability (\RG4)}
    1.40 -Extendability, maintainability, and testability do all suffer from the monolithic architecture and are nearly impossible to improve without changing the programs structure. These properties can hardly be retrofitted into software. Extendability might become important in the future. The other two ease all further work on the software, and also improve security and reliability.
    1.41 +
    1.42 +\subsubsection*{\TODO6: Extendability (\RG4)}
    1.43 +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.
    1.44 +
    1.45  
    1.46  
    1.47  
    1.48 @@ -384,19 +387,107 @@
    1.49  
    1.50  \section{Ways for further development}
    1.51  
    1.52 +Futher development of software can always go three different ways:
    1.53 +\begin{enumerate}
    1.54 +\item[S1:] Improve the current code base.
    1.55 +\item[S2:] Add wrappers or interposition filters.
    1.56 +\item[S3:] Redesign the software from scratch and rebuild it.
    1.57 +\end{enumerate}
    1.58  
    1.59 -\subsubsection*{The need for structural changes}
    1.60 +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.61  
    1.62 -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 about security and reliability, like \MTA{}s. Worse if these features need changes in the program's structure, like adding mail scanning interfaces would do.
    1.63 +
    1.64 +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.65 +
    1.66 +\begin{table}
    1.67 +	\begin{center}
    1.68 +		\input{input/strategies.tex}
    1.69 +	\end{center}
    1.70 +	\caption{Development strategies and their suitability for requirements}
    1.71 +	\label{tab:strategies}
    1.72 +\end{table}
    1.73 +
    1.74 +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.75  
    1.76  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.77  
    1.78 -Quality properties, like security and reliability, as well as extendability 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.79 +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.80 +
    1.81 +
    1.82 +
    1.83 +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.84 +
    1.85 +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.86 +
    1.87 +This leads to the conclusion, that S3 (A new design) is the best strategy for further development, from this point of view.
    1.88 +
    1.89 +
    1.90 +\subsubsection*{S3: A new design from scratch}
    1.91 +
    1.92 +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.93 +
    1.94 +\person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
    1.95 +{\small
    1.96 +\begin{verbatim}
    1.97 +Total Physical Source Lines of Code (SLOC)                = 9,041
    1.98 +Development Effort Estimate, Person-Years (Person-Months) = 2.02 (24.22)
    1.99 + (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
   1.100 +Schedule Estimate, Years (Months)                         = 0.70 (8.39)
   1.101 + (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
   1.102 +Estimated Average Number of Developers (Effort/Schedule)  = 2.89
   1.103 +Total Estimated Cost to Develop                           = $ 272,690
   1.104 + (average salary = $56,286/year, overhead = 2.40).
   1.105 +SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
   1.106 +\end{verbatim}
   1.107 +}
   1.108 +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 Oliver \person{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.
   1.109 +
   1.110 +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.
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +---
   1.116 +
   1.117 +
   1.118 +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.
   1.119 +
   1.120 +
   1.121 +
   1.122 +%\subsubsection*{The need for structural changes}
   1.123  
   1.124  %\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
   1.125  
   1.126 +---
   1.127  
   1.128  
   1.129 +
   1.130 +
   1.131 +
   1.132 +
   1.133 +
   1.134 +\subsubsection*{A redesign from scratch}
   1.135 +
   1.136 +Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
   1.137 +\begin{quote}
   1.138 +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.
   1.139 +%
   1.140 +%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.
   1.141 +\hfill\cite[page 55]{graff03}
   1.142 +\end{quote}
   1.143 +
   1.144 +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.145 +
   1.146 +
   1.147 +
   1.148 +
   1.149 +
   1.150 +
   1.151 +
   1.152 +
   1.153 +
   1.154 +\section{Result}
   1.155 +
   1.156  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.
   1.157  
   1.158  All other work depends on how the plans for \masqmail's future look like.
   1.159 @@ -417,50 +508,6 @@
   1.160  
   1.161  
   1.162  
   1.163 -1) on current code base
   1.164 -
   1.165 -2) wrappers, interposition
   1.166 -
   1.167 -3) new design
   1.168 -
   1.169 -
   1.170 -
   1.171 -
   1.172 -
   1.173 -\subsubsection*{A redesign from scratch}
   1.174 -
   1.175 -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.176 -
   1.177 -But redesigning and rewriting a 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.178 -
   1.179 -\person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
   1.180 -{\small
   1.181 -\begin{verbatim}
   1.182 -Total Physical Source Lines of Code (SLOC)                = 9,041
   1.183 -Development Effort Estimate, Person-Years (Person-Months) = 2.02 (24.22)
   1.184 - (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
   1.185 -Schedule Estimate, Years (Months)                         = 0.70 (8.39)
   1.186 - (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
   1.187 -Estimated Average Number of Developers (Effort/Schedule)  = 2.89
   1.188 -Total Estimated Cost to Develop                           = $ 272,690
   1.189 - (average salary = $56,286/year, overhead = 2.40).
   1.190 -SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
   1.191 -\end{verbatim}
   1.192 -}
   1.193 -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 Oliver \person{Kurth} within four years, in his spare time. This means he needed around twice as much time. Of course, he programmed as volunteer developer, not as employee with eight work-hours per day.
   1.194 -
   1.195 -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.
   1.196 -
   1.197 -
   1.198 -
   1.199 -
   1.200 -
   1.201 -
   1.202 -
   1.203 -
   1.204 -
   1.205 -
   1.206 -\section{Result}
   1.207  
   1.208  The suggested further development plan for \masqmail\ is:
   1.209  \begin{enumerate}