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

comparison thesis/tex/4-MasqmailsFuture.tex @ 200:2e006e8f5250

rewrote much and wrote result and more (ch04)

author	meillo@marmaro.de
date	Wed, 31 Dec 2008 17:28:42 +0100
parents	b08be036783d
children	f2b8481789f6

comparison

equal deleted inserted replaced

-:8af18dd9103f
+:2e006e8f5250
 \subsubsection*{Fulfilled requirements}
-\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.
+\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.
 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.
 Static authentication, based on \NAME{IP} addresses, can be set up using the \path{hosts.allow} and \path{hosts.deny} files. Dynamic authentication is supported in form of \NAME{SMTP-AUTH} and \SMTP-after-\NAME{POP}, but only for outgoing connections. The same for encryption which is also only available for outgoing \SMTP\ connections; here a wrapper application like \name{openssl} needs to be used. Support for authentication and encryption of incoming connections is completely missing, but a basic requirement for all secure emailing.
 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, if really nessesary, should be left over to the \NAME{MDA}, to deal with it in local delivery.
 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.
-Non-functional requirements need improvements too.
+Non-functional requirements need improvement too.
 \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.
 Reliability is also to improve. It is a key quality property for an \MTA, and not good enough in \masqmail. Also is the program lacking robustness. Checking the environment and reporting bad characteristics is wanted. Especially improving robustness inrelation to the queue is favorable; applying ideas of \name{crash-only software}\cite{candea03} will be a good step.
 Configuration could be eased more, by providing configuration generators to be able to run \masqmail\ right ``out of the box'' with only running one of several configuration scripts for common setups. This would make \masqmail\ better usable by people not technical educated.
+\subsubsection*{The need for structural changes}
+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.
-\section{Discussion on architecture}
+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.
-%fixme: why is there a need for a new arch??
-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.
+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.
-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.
+%\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
+\section{Discussion on MTA architecture}
 \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
 \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
-Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure.
+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.
 \begin{figure}
 	\begin{center}
 		\input{input/masqmail-arch.tex}
 	\end{center}
-	\caption{Internal structure of \masqmail}
+	\caption{Call graph of \masqmail\ to show its internal structure}
 	\label{fig:masqmail-arch}
 \end{figure}
-\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.
+\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.
 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}
 \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:
 \begin{quote}
 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}
 \end{quote}
-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.
+As well does \person{Dent} for \postfix: ``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.
 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 maintainance 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.
 \cite[page 55]{graff03}
 \end{quote}
-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.
+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.
-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.
+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.
 \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 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.
+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.
 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.
-The further section describes a new modern design for \masqmail. A plan to rewrite \masqmail\ from scratch.
-%\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
 \section{Result}
-Directions to go
+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.
-Now how could \masqmail\ be like in, say, five years?
+The implementation of authentication and encryption are covered in the next chapter within this thesis.
-This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
+All other work depends on how \masqmail's future plans look like.
+Now, how could \masqmail\ be like, in five years, for instance? 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 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) fix the current version
+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.
-2) create a new one
+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.
-But how is the effort of this complete rewrite compared to what is gained afterwards?
-<< would one create it at all? >>
+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.
+\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.
-pro---contra
+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.
+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.
-<< short term goals --- long term goals >>
+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.
-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.
-<< which parts to take out and do within the thesis >>

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 200:2e006e8f5250