1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 14:47:27 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 19:00:25 2009 +0100
     1.3 @@ -39,9 +39,7 @@
     1.4  \label{sec:functional-requirements}
     1.5  \index{functional requirements}
     1.6  
     1.7 -Functional requirements are about the function of the software. They define what the program can do and in what way.
     1.8 -%fixme: add ref
     1.9 -The requirements are named ``\NAME{RF}'' for ``requirement, functional''.
    1.10 +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''.
    1.11  
    1.12  
    1.13  \paragraph{\RF\,1: Incoming and outgoing channels}
    1.14 @@ -58,7 +56,6 @@
    1.15  \index{outgoing channels}
    1.16  \index{uucp}
    1.17  
    1.18 -%fixme: is the def of MTA: transfer between machines, or transfer between users?
    1.19  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.
    1.20  \index{local delivery}
    1.21  
    1.22 @@ -241,9 +238,7 @@
    1.23  \subsection{Non-functional requirements}
    1.24  \index{non-functional requirement}
    1.25  
    1.26 -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}.
    1.27 -%fixme: refer to ch01 and ch02
    1.28 -These non-functional requirements are named ``\NAME{RG}'' for ``requirement, general''.
    1.29 +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''.
    1.30  
    1.31  
    1.32  \paragraph{\RG\,1: Security}
    1.33 @@ -309,7 +304,6 @@
    1.34  \index{usability}
    1.35  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.
    1.36  
    1.37 -%fixme: << masqmail as portable app? >>
    1.38  
    1.39  
    1.40  
    1.41 @@ -317,10 +311,7 @@
    1.42  \label{sec:discussion-mta-arch}
    1.43  \index{architecture}
    1.44  
    1.45 -%fixme: what's this section to do with requirements?
    1.46 -
    1.47 -\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
    1.48 -\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.
    1.49 +\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.
    1.50  \index{milter}
    1.51  \index{masqmail!architecture}
    1.52  
    1.53 @@ -364,7 +355,6 @@
    1.54  
    1.55  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.
    1.56  
    1.57 -%fixme: explain: why are compartments and interfaces so good?
    1.58  
    1.59  
    1.60  
    1.61 @@ -385,7 +375,7 @@
    1.62  \index{outgoing channels}
    1.63  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.
    1.64  
    1.65 -%fixme: << smtp submission >> %fixme
    1.66 +%fixme: << smtp submission >>
    1.67  
    1.68  \paragraph{\RF\,2: Queuing}
    1.69  \index{mail queue}
    1.70 @@ -446,13 +436,11 @@
    1.71  \hfill\citeweb{masqmail:homepage2}
    1.72  \end{quote}
    1.73  
    1.74 -In summary: Current reliability needs to be improved.
    1.75 -%fixme: state machine
    1.76 +In summary: Current reliability needs to be improved. Implementing a state machine can help here.
    1.77  
    1.78  \paragraph{\RG\,3: Robustness}
    1.79  \index{robustness}
    1.80  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.
    1.81 -%fixme: rule of robustness, rule of repair
    1.82  
    1.83  \paragraph{\RG\,4: Extendability}
    1.84  \index{extendability}
    1.85 @@ -471,7 +459,6 @@
    1.86  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.
    1.87  \index{test program}
    1.88  
    1.89 -%fixme: think about clean-room testing
    1.90  
    1.91  \paragraph{\RG\,7: Performance}
    1.92  \index{performance}
    1.93 @@ -679,7 +666,7 @@
    1.94  
    1.95  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.
    1.96  
    1.97 -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.
    1.98 +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.
    1.99  \index{wrapper}
   1.100  \index{extendability}
   1.101  
   1.102 @@ -717,7 +704,7 @@
   1.103  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.
   1.104  \index{sendmail}
   1.105  
   1.106 -Redesigning a software as requirements change helps keeping it alive. % fixme: add quote: ``one thing surely remains: change'' (something like that)
   1.107 +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.''
   1.108  \index{redesign}
   1.109  
   1.110  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.
   1.111 @@ -759,7 +746,7 @@
   1.112  \subsubsection*{Break Even}
   1.113  \index{Break Even}
   1.114  
   1.115 -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!
   1.116 +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.
   1.117  
   1.118  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.
   1.119  \index{existing code}
   1.120 @@ -778,12 +765,11 @@
   1.121  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.
   1.122  \index{quality improvement}
   1.123  
   1.124 -Also, if some design is bad one should never hesitate to erase it and rebuild it in a sane way.
   1.125 -%fixme: doubled speech!
   1.126 +If some design is bad, it should get replaced by a sane solution.
   1.127  
   1.128 -Again \person{Doug McIlroy} gives valuable advice: ``Don't hesitate to throw away the clumsy parts and rebuild them.'' \cite{mcilroy78}.
   1.129 +\person{Doug McIlroy} gives valuable advice for these situations: ``Don't hesitate to throw away the clumsy parts and rebuild them.'' \cite{mcilroy78}.
   1.130  
   1.131 -However, making such a cut is hard, especially if the bad design is still \dots\ ``good enough''.
   1.132 +Though, making such a cut is hard, especially if the bad design is still \dots\ ``good enough''.
   1.133  
   1.134  
   1.135