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

comparison thesis/tex/4-MasqmailsFuture.tex @ 241:2c56f26758eb

rework in ch04: further dev and more

author	meillo@marmaro.de
date	Sun, 11 Jan 2009 14:07:48 +0100
parents	a6be202e1b49
children	aff94e950f39

comparison

equal deleted inserted replaced

-:046a8284b5d3
+:2c56f26758eb
 The importance is ranked from `-{}-' (not important) to `++' (very important). The pending work is ranked from `-{}-' (nothing) to `++' (very much). Large work tasks with high importance need to receive much attention, they are in focus. In contrast should small low importance work receive few attention. Here the attention/focus a task should get is calculated by summing up the importance and the pending work with equal weight. Normally, tasks with high focus are the ones of high priority and should be done first.
 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.
-These tasks to do are presented in more detail now.
+These tasks are presented in more detail now. They are sorted in the suggested order to work on them..
 \subsubsection*{\TODO1: Encryption (\RF7)}
-Encryption by using \NAME{STARTTLS} is definitely needed and should be added soon. This feature is essential for providing privacy.
+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.
-\subsubsection*{\TODO2: Spam handling (\RF8)}
+\subsubsection*{\TODO2: Authentication (\RF6)}
-\subsubsection*{\TODO6: Authentication (\RF6)}
+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.
-Authentication of incoming \SMTP\ connections is definitely needed and should be added soon. It is essential for restricting relaying.
-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.
 \subsubsection*{\TODO3: Security (\RG1)}
-\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.
+\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.
+Compartementalization, ref secure coding, postfix ...
+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.
 \subsubsection*{\TODO4: Reliability (\RG2)}
-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.
+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.
+\subsubsection*{\TODO5: Spam handling (\RF8)}
-\subsubsection*{\TODO5: Extendability (\RG4)}
+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.
-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.
+\subsubsection*{\TODO6: Extendability (\RG4)}
+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*{Further \NAME{TODO}s}
 \section{Ways for further development}
+Futher development of software can always go three different ways:
-\subsubsection*{The need for structural changes}
+\begin{enumerate}
+\item[S1:] Improve the current code base.
-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.
+\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 abandonnes the old code and starts over again. Wrappers and interposition filters would then be outright included into the new architecture.
+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}.
+\begin{table}
+	\begin{center}
+		\input{input/strategies.tex}
+	\end{center}
+	\caption{Development strategies and their suitability for requirements}
+	\label{tab:strategies}
+\end{table}
+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.
 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.
-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.
+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.
-%\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
+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.)
-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.
+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.
-All other work depends on how the plans for \masqmail's future look like.
+This leads to the conclusion, that S3 (A new design) is the best strategy for further development, from this point of view.
-What shall \masqmail\ be like, in, for instance, five years?
+\subsubsection*{S3: A new design from scratch}
-Two ways of further development come to mind.
+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.
-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.
-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.
-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.
-1) on current code base
-2) wrappers, interposition
-3) new design
-\subsubsection*{A redesign from scratch}
-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.
-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.
 \person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
 {\small
 \begin{verbatim}
 Total Physical Source Lines of Code (SLOC)                = 9,041
 Total Estimated Cost to Develop                           = $ 272,690
 (average salary = $56,286/year, overhead = 2.40).
 SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
 \end{verbatim}
 }
-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.
+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.
 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.
+---
+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}
+---
+\subsubsection*{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.
 \section{Result}
+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?
+Two ways of further development come to mind.
+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.
+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.
+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:
 \begin{enumerate}
 \item The short time goal: Add the most needed features, being authentication and encryption, to the current code base. \item 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 throughout tested, supersede the old \masqmail.
 \end{enumerate}

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 241:2c56f26758eb