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

comparison thesis/tex/4-MasqmailsFuture.tex @ 196:b80438534651

rewrites and new content about non-functional requirements

author	meillo@marmaro.de
date	Wed, 31 Dec 2008 14:00:30 +0100
parents	74a6cbdc7255
children	b08be036783d

comparison

equal deleted inserted replaced

-:ff55d3d6fbca
+:b80438534651
 Here follows a list of quality requirements for \masqmail, or other kinds of programs in similar environment and with similar jobs. These requirements specify the non-functional properties of the software, thus they are also called \name{non-functional requirements}. The list is based on \person{Hafiz} \cite[page~2]{hafiz05}, with insperation from \person{Spinellis} \cite[page~6]{spinellis06}.
 %fixme: refer to ch01 and ch02
 \subsubsection*{Security}
-\MTA{}s are critical points for computer security, as they are accessable from external networks. They must be secured with high effort. Properties like high priviledge level, work load influenced from extern, work on unsafe data, and demand for reliability, increase the security needed. \masqmail\ needs to be secure enough for its target field of operation.
+\MTA{}s are critical points for computer security, as they are accessable from external networks. They must be secured with high effort. Properties like high priviledge level, work load influenced from extern, work on unsafe data, and demand for reliability, increase the need for security. \masqmail\ needs to be secure enough for its target field of operation.
 \subsubsection*{Reliability}
-Reliability is the second essential quality property for an \MTA. Mail, for which the \MTA\ took responsibility, must never get lost. The \MTA\ must not be the cause of any mail loss, no matter what happens. Unreliable \mta{}s are of no value.
+Reliability is the second essential quality property for an \MTA. Mail for which the \MTA\ took responsibility must never get lost. The \MTA\ must not be \emph{the cause} of any mail loss, no matter what happens. Unreliable \mta{}s are of no value.
 \subsubsection*{Robustness}
-Being robust means handling errors properly. Small errors may get tolerated, large errors may kill a process, to get restarted afterwards. Log messages should be written in every case. Robust software does not need a special environment, it creates the right environment itself. \person{Raymond}'s \name{Rule of Robustness} and his \name{Rule of Repair} are good descriptions.\cite[pages~18--21]{raymond03}
+Being robust means handling errors properly. Small errors may get tolerated, large errors may kill a process. Killed processes should be automatically restarted and lead to a clean state again. Log messages should be written in every case. Robust software does not need a special environment, it creates the right environment itself. \person{Raymond}'s \name{Rule of Robustness} and his \name{Rule of Repair} are good descriptions.\cite[pages~18--21]{raymond03}
 \subsubsection*{Extendability}
-Modern needs like large messages demand for more efficient mail transport through the net. Aswell is a final solution needed to defeat the spam problem. New mail transport protocols seem to be the only good solutions for both problems. They also can improve reliability, authentication, and verification issues. \masqmail\ should be able to support new mail transfer protocols as they appear and are used.
+Modern needs like large messages demand for more efficient mail transport through the net. Aswell is a final solution needed to defeat the spam problem. New mail transport protocols seem to be the only good solutions for both problems. They also can improve reliability, authentication, and verification issues. \masqmail's architecture needs to be extendable, to allow new features to be added afterwards. For example new mail transfer protocols as they appear and are used.
-%fixme: like old sendmail, but not too much like it
 \subsubsection*{Maintainability}
-Maintaining software takes much time and effort. \person{Spinellis} measures ``40\,\% to 70\,\% of the effort that goes into a software system is expended after the system is written first time.''\cite[page~1]{spinellis03} This is maintaining work. Hence making software good to maintain is effort that will become invalueable afterwards.
+Maintaining software takes much time and effort. \person{Spinellis} guesses ``40\,\% to 70\,\% of the effort that goes into a software system is expended after the system is written first time.'' \cite[page~1]{spinellis03}. This work is called \emph{maintaining}. Hence making software good to maintain is effort that will easy 40 to 70\,\% of the work afterwards.
 \subsubsection*{Testability}
-Good testability make maintainance easier, because functionality is directly verifiable when changes are done, thus removing the uncertaintay. Modularized software makes testing easier, because parts can be testet without external influences.
+Good testability make maintainance easier too, because functionality is directly verifiable when changes are done, thus removing the uncertainty. Modularized software makes testing easier, because parts can be testet without external influences. \person{Spinellis} sees testability as a subquality of maintainability.
 \subsubsection*{Performance}
-Also called ``efficiency''. Software requiring few time and few resources is nice. But as performance improvements are in contrast to many other quality poperties (reliability, maintainability, usability, capability \cite[page~5]{kan03}), japardizing them to gain some more performance should not be done. \person{Kernighan} and \person{Pike} state clear: ``[T]he first principle of optimization is \emph{don't}.''\cite[page~165]{kernighan99}
+Also called ``efficiency''. Efficient software requires few time and few resources. The merge of communication hardware and its move from service providers to homes and to mobile devices, demand smaller and more resource-friendly software. The amount of mail will be lower, even if much more mail will be sent. More important will be the energy consumption and heat emission. These topics increased in relevance during the past years and they are expected to become more central.
-The merge of communication hardware and the move of email services from providers to homes, demands smaller and more resource-friendly software. The amount of mail will be lower, even if much more mail will be sent. More important will be the energy consumption and heat emission. These topics increased in relevance during the past years and they are expected to become more central. \masqmail\ is not a program to be used on large servers, but to be used on small devices. Thus focusing on energy and heat, not on performance, is the direction to go.
 \subsubsection*{Availability}
-Availability is important for server programs. They must stay operational, even when bad guys run \name{denial of service} attacks.
+Availability is important for server programs. They must stay operational, even during \name{denial of service} attacks.
 \subsubsection*{Portability}
-Not to forget is portability. It can be accieved by using standard features of the programming language and common libraries. Basic rules for portable code are defined by \person{Kerighan} and \person{Pike} \cite{kernighan99}.
+Source code that compiles and runs on various operationg systems is called portable. Portability can be achieved by using standard features of the programming language and common libraries. Basic rules for portable code are defined by \person{Kerighan} and \person{Pike} \cite{kernighan99}. Portable code lets software spread faster.
-Focusing on \unix\ systems seems to be okay, but being portable between different flavors of them is important. Also should the \masqmail\ be independent of the underlying file system.
 \subsubsection*{Usability}
-Usability, not mentioned by \person{Hafiz} but by \person{Spinellis} and \person{Kan}, is a property very important from the user's point of view. Software with bad usability is rarely used, no matter how good it is---if roughly equivilent substitutes with better usability exist, the user will switch to one of them.
+Usability, not mentioned by \person{Hafiz} (he focuses on architecture) but by \person{Spinellis} and \person{Kan}, is a property very important from the user's point of view. Software with bad usability is rarely used, no matter how good it is. If roughly equivilent substitutes with better usability exist, the user will switch to one of them. Usability here means easy to set up and configure, too; users are also administrators here. Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common setups should be configurable with single actions by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several standard setups.
-Usability here means easy to set up and configure, too. Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common setups should be configurable with single actions by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several standard setups.
 \masqmail\ does not provide special support for spam filter or content checking. But it is possible to invoke external filter applications by running two independent instances of \masqmail, connected by the filter application. The receiving \MTA\ instance accepts mail and pushes it into the filter. The filter application receives mail, processes it, possible modifies it, and pushes it over to a second \MTA\ instance. The second \MTA\ is responsible for further delivery of the mail. Appendix \ref{app:FIXME} shows configuration files to create such a setup. This is a concept that works in general. However, real spam \emph{prevention}---to not accept spam mail at all---or good filter interfaces are not available, but are nessesary for using \masqmail\ in an unsafe environment.
 There is currently no way of archiving every message going through \masqmail.
-%fixme: write about non-functional requirements
+Non-functional requirements are not so easy to be marked as fulfilled or not. Instead they are discussed here.
-Making \masqmail\ a \name{crash-only software}\cite{candea03} would be a step to make it more robust.
+\masqmail\ needs to be ``secure enough'', but what is ``secure enough''? This depends on its target field. Currently \masqmail\ is targeted to workstations and private networks, with explicit warning for use on permanent online hosts \citeweb{masqmail:homepage2}. \masqmail's current security is bad. (For instance does a long time known attack against \sendmail, described by \person{Sill} \cite[page~4]{sill02}, still outwit \masqmail). The security, however, seems acceptable for use on workstations and private networks, if the environment is trusted. In environments where untrusted components or persons have access to \masqmail, its security is too low.
+Similar for its reliability. It has been reported that \masqmail\ has not sent mail under some circumstances \citeweb{FIXME}. %fixme
+The author also noticed problems with where only one part of the queued message was removed, the other part remained as garbage. Fortunately, reports abou lost mail are not known. Current reliability is not good enough.
+The logging behavior of \masqmail\ is good, but does not cover everything. Also it trusts its environment. For example, if the queue directory is world writeable by accident (or as action of an intruder), any user can remove messages from the queue or replace them with own ones. \masqmail\ does not even write a debug message in this case.
+\masqmail's extendability is very poor. This is a general problem of monolithic software, but can thus be provided with high effort. \exim\ is an example for good extendability for a monolithic program.
+The maintainability of \masqmail\ appears to be equivilent to other software of similar kind. Missing modularity and therefore more complexity makes the maintainer's work harder. In summary is \masqmail's maintainability bearable, and in view of its missing modularity good. The testability suffers from the same. Testing program parts is hard, but done by compiling source parts to special test programs.
+The performance---effenciency---of \masqmail\ is good enough for its target field of operation, where this is a minor goal. As well is its availability. Hence no further work needs to be done her.
+The code's protability is good with view on \unix-like operation systems. At least \name{Debian}, \name{Redhat}, \NAME{SUSE}, \name{slackware}, \name{Free}\NAME{BSD}, \name{Open}\NAME{BSD}, and \name{Net}\NAME{BSD} are reported to be able to compile and run \masqmail\ \citeweb{masqmail:homepage2}. About special requirements for the underlying file system is not heard of. The portability is already good.
+The usability, from the administator's point of view, is very good. \masqmail\ was developed to suite a specific, limited job, its configuration does perfect match. The user's view does not reach to the \MTA, as it is hidden behind the \name{mail user agent}.
 \subsubsection*{Missing parts}
 Support for other protocols than \SMTP\ seems not to be nessesary at the moment. Adding such support will need lots of work in all parts of \masqmail, hence delaying it until the support is needed appears to be the best solution.
 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.
-%fixme: what about non-functional requirements?
+Non-functional requirements need improvements 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.
-\subsubsection*{Discussion on architecture}
+Extendability, maintainability, and testability do all lack from the monolithic architecture and are nearly impossible to improve without changing the programs structure. These properties can hardly be retrofitted into software. But extendability might become important in the future, and the other two make all further work on the software easier.
+Performance is a nice-to-have property, but as performance improvements are in contrast to many other quality poperties (reliability, maintainability, usability, capability \cite[page~5]{kan03}), jeopardizing these to gain some more performance should not be done. \person{Kernighan} and \person{Pike} state clear: ``[T]he first principle of optimization is \emph{don't}.''\cite[page~165]{kernighan99}. \masqmail\ is not a program to be used on large servers, but on small devices. Thus important for \masqmail\ is focusing on energy and heat, maybe also system resources, not on performance.
+Focusing on being portable amoung the various flavors of \unix\ systems seems to be okay, because these systems are the ones \MTA{}s run on usually. Problems with non-\unix platforms are primary expected to come from file systems lacking required features. But no special care should be taken here.
+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.
+\section{Discussion on architecture}
 %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.
 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{A design from scratch}
+\section{Result}
+Directions to go
+Now how could \masqmail\ be like in, say, five years?
+This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
+1) fix the current version
+2) create a new one
+But how is the effort of this complete rewrite compared to what is gained afterwards?
+<< would one create it at all? >>
+pro---contra
+<< short term goals --- long term goals >>
+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 >>
+\chapter{A design from scratch}
 The last sections identified the jobs that need to be done by a modern \MTA; problems and prefered choices were mentioned too. Now the various jobs are assigned to modules, of which an architecture is created. It is inpired by existing ones and driven by the identified jobs and requirements.
 http://fanf.livejournal.com/70432.html %how not to design an mta - address verification
 http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning
-\section{Result}
-Directions to go
-Now how could \masqmail\ be like in, say, five years?
-This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
-1) fix the current version
-2) create a new one
-But how is the effort of this complete rewrite compared to what is gained afterwards?
-<< would one create it at all? >>
-pro---contra
-<< short term goals --- long term goals >>
-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 @ 196:b80438534651