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

comparison thesis/tex/4-MasqmailsFuture.tex @ 396:8ef85e22ff7d

again lots of fixes and removed fixmes

author	meillo@marmaro.de
date	Sat, 07 Feb 2009 19:00:25 +0100
parents	0d78755132b7
children	13e630c5a44d

comparison

equal deleted inserted replaced

-:0d78755132b7
+:8ef85e22ff7d
 \subsection{Functional requirements}
 \label{sec:functional-requirements}
 \index{functional requirements}
-Functional requirements are about the function of the software. They define what the program can do and in what way.
+Functional requirements are about the function of the software. They define what the program can do and in what way. The requirements are named ``\NAME{RF}'' for ``requirement, functional''.
-%fixme: add ref
-The requirements are named ``\NAME{RF}'' for ``requirement, functional''.
 \paragraph{\RF\,1: Incoming and outgoing channels}
 \label{rf1}
 \sendmail-compatible \MTA{}s must support at least two incoming channels: mail submitted using the \path{sendmail} command, and mail received on a \NAME{TCP} port. Thus it is common to split the incoming channels into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view \cite{hafiz05}.
 Outgoing mail is commonly either sent using \SMTP, piped into local commands (for example \path{uucp}), or delivered locally by appending to a mailbox. Outgoing channels are similar for \qmail, \postfix, and \name{sendmail~X}: All of them have a module to send mail using \SMTP, and one for writing into a local mailbox.
 \index{outgoing channels}
 \index{uucp}
-%fixme: is the def of MTA: transfer between machines, or transfer between users?
 Local mail delivery is a job that uses root privilege to be able to switch to any user in order to write to his mailbox. It is possible to deliver without being root privilege, but delivery to user's home folders is not generally possible then. Thus even the modular \MTA{}s \qmail\ and \postfix\ use root privilege for this job. As mail delivery to local users is \emph{not} included in the basic job of an \MTA{} and introduces a lot of new complexity, why should the \MTA\ bother? In order to keep the system simple, reduce privilege, and to have programs that do one job well, the local delivery job should be handed over to a specialist: the \NAME{MDA}. \NAME{MDA}s know about the various mailbox formats and are aware of the problems of concurrent write access and the like. Hence passing the message, and the responsibility for it, over to an \NAME{MDA} seems to be best.
 \index{local delivery}
 This means an outgoing connection that pipes mail into local commands is required. To other outgoing channels applies what was already said about incoming channels.
 \subsection{Non-functional requirements}
 \index{non-functional requirement}
-Now follows a list of non-functional requirements for \masqmail. These requirements specify the quality properties of a software. The list is based on \person{Hafiz} \cite[page~2]{hafiz05}, with inspiration from \person{Spinellis} \cite[page~6]{spinellis06} and \person{Kan} \cite{kan03}.
+Now follows a list of non-functional requirements for \masqmail. These requirements specify the quality properties of a software. The list is based on \person{Hafiz} \cite[page~2]{hafiz05}, with inspiration from \person{Spinellis} \cite[page~6]{spinellis06} and \person{Kan} \cite{kan03}. These non-functional requirements are named ``\NAME{RG}'' for ``requirement, general''.
-%fixme: refer to ch01 and ch02
-These non-functional requirements are named ``\NAME{RG}'' for ``requirement, general''.
 \paragraph{\RG\,1: Security}
 \index{security}
 \MTA{}s are critical points for computer security as they are accessible from external networks. They must be secured with high effort. Properties like the need for high privilege level, from outside influenced work load, work on unsafe data, and demand for reliability, increase the need for security. This is best done by modularization, also called \name{compartmentalization}, as described in section~\ref{sec:discussion-mta-arch}.
 \paragraph{\RG\,10: Usability}
 \index{usability}
 Usability, not mentioned by \person{Hafiz} \cite{hafiz05} (he focuses on architecture) but by \person{Spinellis} \cite{spinellis06} and \person{Kan} \cite{kan03}, is a property which is very important from the user's point of view. Software with bad usability is rarely used, no matter how good it is. If substitutes with better usability exist, the user will switch to one of them. Here, usability includes setting up and configuring; the term ``users'' includes administrators. Having \MTA{}s on home servers and workstations requires easy and standardized configuration. The common setups should be configurable with little action by the user. Complex configuration should be possible, but the focus should be on the most common form of configuration: choosing one of several common setups.
-%fixme: << masqmail as portable app? >>
 \subsection{Architecture}
 \label{sec:discussion-mta-arch}
 \index{architecture}
-%fixme: what's this section to do with requirements?
+\masqmail's current architecture is monolithic like \sendmail's and \exim's. But more than the other two is it one block of interweaved code. \exim\ has a highly structured code with many internal interfaces, a good example is the interface for authentication ``modules''. \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules. \masqmail\ has none of them---it is what \sendmail\ was in the beginning: a single large block.
-\masqmail's current architecture is monolithic like \sendmail's and \exim's. But more than the other two is it one block of interweaved code. \exim\ has a highly structured code with many internal interfaces, a good example is the interface for authentication ``modules''. %fixme: add ref
-\sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules. \masqmail\ has none of them---it is what \sendmail\ was in the beginning: a single large block.
 \index{milter}
 \index{masqmail!architecture}
 Figure~\ref{fig:masqmail-arch} is a call graph generated from \masqmail's source code. It gives an impression of how interweaved the internals are. There are no compartments at all.
 \index{masqmail!call graph}
 Modularity is no direct requirement but a goal that has positive influence on important requirements like security, testability, extendability, maintainability, and not least simplicity. These quality properties then, on their part, make it easier to achieve the functional requirements.
 \index{security}
 Hence, aspiration for modularity, by compartmentalization, improves the overall quality and function of the software. It can be seen as an architectural requirement for a secure and modern \MTA.
-%fixme: explain: why are compartments and interfaces so good?
 \paragraph{\RF\,1: In/out channels}
 \index{incoming channels}
 \index{outgoing channels}
 The incoming and outgoing channels that \masqmail\ already has (depicted in figure~\ref{fig:masqmail-channels} on page \pageref{fig:masqmail-channels}) are the ones required for an \MTA{}s at the moment. Currently, support for other protocols seems not to be necessary, although new protocols and mailing concepts are likely to appear (see section~\ref{sec:email-trends}). As other protocols are not required today, \masqmail\ is regarded to fulfill \RF\,1. Without any support in \masqmail\ for adding further protocols, the best strategy is to delaying such work until the functionality is essential, anyway.
-%fixme: << smtp submission >> %fixme
+%fixme: << smtp submission >>
 \paragraph{\RF\,2: Queuing}
 \index{mail queue}
 One single mail queue is used in \masqmail. It satisfies all current requirements.
 \begin{quote}
 There may still be serious bugs in [masqmail], so mail might get lost. But in the nearly two years of its existence so far there was only one time a bug which caused mail retrieved via pop3 to be lost in rare circumstances.
 \hfill\citeweb{masqmail:homepage2}
 \end{quote}
-In summary: Current reliability needs to be improved.
+In summary: Current reliability needs to be improved. Implementing a state machine can help here.
-%fixme: state machine
 \paragraph{\RG\,3: Robustness}
 \index{robustness}
 The logging behavior of \masqmail\ is good, although it does not cover the whole code. 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. The origin of this problem, however, is \masqmail's trust in its environment.
-%fixme: rule of robustness, rule of repair
 \paragraph{\RG\,4: Extendability}
 \index{extendability}
 \masqmail's extendability is very poor. This is a general problem of monolithic software, but can though be provided with high effort. \exim\ is an example for good extendability in a monolithic program.
 The testability suffers from missing modularity, too. Testing program parts is hard to do. Nevertheless, it is done by compiling parts of the source to two special test programs: One tests reading input from a socket, the other tests constructing messages and sending it directly. Neither is designed for automated testing of source parts, they are rather to help the programmer during development.
 Two additional scripts exist to send a set of mails to differend kinds of recipients. They can be used for automated testing, but both check only the function of the whole system, not its parts.
 \index{test program}
-%fixme: think about clean-room testing
 \paragraph{\RG\,7: Performance}
 \index{performance}
 The performance---efficiency---of \masqmail\ is good enough for its target field of operation, where this is a minor goal.
 If a new design needs much effort and additionally is a risk, what about the existing code base then?
 Adding new functionality to an existing code base seems to be a secure and cheap strategy. The existing code is known to work and features can often be added in small increments. Risks like wasted effort if a new design fails are hardly existent, and the faults in the current design are already made and most probably fixed.
-Functionality that is hard to add incrementally into the application, like support for new protocols, may be addable to the outside. \masqmail\ can be secured to a huge amount by guarding it with wrappers that block attackers. Spam and malware scanners can be included by running two instances of \masqmail. All those methods base on the current code which they can indirectly improve.
+Functionality that is hard to add incrementally into the application, like support for new protocols, may be addable to the outside. \masqmail\ can be secured to a huge amount by guarding it with wrappers that block attackers \cite[page~71]{graff03}. Spam and malware scanners can be included by running two instances of \masqmail. All those methods base on the current code which they can indirectly improve.
 \index{wrapper}
 \index{extendability}
 The required effort is probably under one third of a new design and work directly shows results. These are strong arguments against a new design.
 A new design does protect against such dead ends.
 Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail, which had an almost monopoly for a long time. But when security became important, \sendmail\ was only repaired instead of the problem sources---its insecure design---would have been removed. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. \sendmail's reaction to the new requirements, in form of \name{sendmail~X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s.
 \index{sendmail}
-Redesigning a software as requirements change helps keeping it alive. % fixme: add quote: ``one thing surely remains: change'' (something like that)
+Redesigning a software as requirements change helps keeping it alive. The knowledge of the Greek philosopher \person{Heraclitus} shall be an inspriation: ``Nothing endures but change.''
 \index{redesign}
 Another danger is the dead end of complexity which is likely to appear by constant work on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} for example advertises such a philosophy of small and simple software by following the thoughts of the Unix inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code avoids complexity and is thus also a strong prerequisite for security.
 \index{suckless}
 \subsubsection*{Break Even}
 \index{Break Even}
-It is important to keep the time dimension in mind. This includes the  separation into a short-time and a long-time view. The short-time view shall cover between two and four years, here. The long-time view is the following time. % fixme: find sources!
+It is important to keep the time dimension in mind. This includes the  separation into a short-time and a long-time view. The short-time view shall cover between two and four years, here. The long-time view is the following time.
 In the short-time view, the effort for improving the existing code is much smaller than the effort for a new design plus improvements. But to have similar quality properties at the end of the short-time frame, a version that is based on current code will probably require nearly as much effort as a new designed version will take. For all further development afterwards, the new design will scale well while the old code will require exponential more work.
 \index{existing code}
 In the long-time view, a restructuring for modularity is necessary anyway. The question is, when it should be done: Right at the start in a new design, or later as restructuring work.
 The decision for later restructuring is problematic. Functionality is often more wanted than quality, thus more function is preferred over better quality, as quality is still ``good enough''. But it might be still ``good enough'' the next time, and the time after that one, and so on.
 Quality improvement is no popular work, but it is required to avoid dead ends. As more code increases the work that needs to be done for quality and modularity improvements, it is better to do these improvements early. Afterwards, all further development will profit from it.
 \index{quality improvement}
-Also, if some design is bad one should never hesitate to erase it and rebuild it in a sane way.
+If some design is bad, it should get replaced by a sane solution.
-%fixme: doubled speech!
+\person{Doug McIlroy} gives valuable advice for these situations: ``Don't hesitate to throw away the clumsy parts and rebuild them.'' \cite{mcilroy78}.
-Again \person{Doug McIlroy} gives valuable advice: ``Don't hesitate to throw away the clumsy parts and rebuild them.'' \cite{mcilroy78}.
+Though, making such a cut is hard, especially if the bad design is still \dots\ ``good enough''.
-However, making such a cut is hard, especially if the bad design is still \dots\ ``good enough''.

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 396:8ef85e22ff7d