1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 21 17:26:18 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 21 20:35:26 2009 +0100
     1.3 @@ -44,7 +44,7 @@
     1.4  
     1.5  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.
     1.6  
     1.7 -%todo: is the def of MTA: transfer between machines, or transfer between users?
     1.8 +%fixme: is the def of MTA: transfer between machines, or transfer between users?
     1.9  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 it. 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.10  
    1.11  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.
    1.12 @@ -229,7 +229,7 @@
    1.13  \subsection{Architecture}
    1.14  \label{sec:discussion-mta-arch}
    1.15  
    1.16 -%todo: what's this section to do with requirements?
    1.17 +%fixme: what's this section to do with requirements?
    1.18  
    1.19  \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 one for authentication ``modules''. %fixme: add ref
    1.20  \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules.
    1.21 @@ -335,7 +335,7 @@
    1.22  
    1.23  \paragraph{\RG3: Robustness}
    1.24  The logging behavior of \masqmail\ is good, although it does not cover all problem situations. 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.25 -%todo: rule of robustness, rule of repair
    1.26 +%fixme: rule of robustness, rule of repair
    1.27  
    1.28  \paragraph{\RG4: Extendability}
    1.29  \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 in a monolithic program.
    1.30 @@ -548,8 +548,7 @@
    1.31  
    1.32  A new design does protect against such dead ends.
    1.33  
    1.34 -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 removing the problem sources---its insecure design. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. %fixme: declined ??
    1.35 -\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. Redesigning a software as requirements change helps keeping it alive. % add quote: ``one thing surely remains: change'' (something like that)
    1.36 +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 removing the problem sources---its insecure design. 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. Redesigning a software as requirements change helps keeping it alive. % fixme: add quote: ``one thing surely remains: change'' (something like that)
    1.37  
    1.38  Another danger is the dead end of complexity which is likely to appear by constantly working 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. %fixme: proof
    1.39  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.40 @@ -577,8 +576,7 @@
    1.41  
    1.42  This leaves current code to be better suited for adding functionality, and a new design to be better suited for quality improvements. Both strategies need to improve function as well as quality, but the difference determines the focus of the strategy.
    1.43  
    1.44 -Easier work is likely to be done earlier in Free Software projects than hard work. Thus by choosing \St1+2 volunteer developers tend to implement function first and delay quality improvements, no matter what the suggested order is. \St3 in contrast would support %fixme: beguenstigen
    1.45 -early quality improvements and later function improvements. This is real-life experience in Free Software development.
    1.46 +Easier work is likely to be done earlier in Free Software projects than hard work. Thus by choosing \St1+2 volunteer developers tend to implement function first and delay quality improvements, no matter what the suggested order is. \St3 in contrast would benefit early quality improvements and later function improvements. This is real-life experience in Free Software development.
    1.47  
    1.48  
    1.49  
    1.50 @@ -593,7 +591,7 @@
    1.51  
    1.52  In the long-time view, a restructuring for modularity is necessary anyway. The question is, when to do it: Right at the start in a new design, or later in some restructuring.
    1.53  
    1.54 -%fixme: define exactly, be clear: what does break even here mean
    1.55 +%fixme: define exactly, be clear: what does ``break even'' here mean
    1.56  
    1.57  
    1.58  
    1.59 @@ -654,11 +652,9 @@
    1.60  \item The long-time plan: Design a new architecture that satisfies the modern requirements especially the quality requirements.
    1.61  \end{enumerate}
    1.62  
    1.63 -The background thought is to first do the most needed stuff on the existing code to keep %fixme: erhalten
    1.64 -it usable. This satisfies the urgent needs and removes the time pressure from the development of the new design. After this is done, a new designed \masqmail\ should be developed from scratch. This is the work for the future. It shall, after it is usable and throughout tested, supersede the old \masqmail.
    1.65 +The background thought is to first do the most needed stuff on the existing code to keep it usable. This satisfies the urgent needs and removes the time pressure from the development of the new design. After this is done, a new designed \masqmail\ should be developed from scratch. This is the work for the future. It shall, after it is usable and throughout tested, supersede the old \masqmail.
    1.66  
    1.67 -The basic idea is, regularly developing a new design from scratch while the current version is still in use and gets repaired. Hence a modern design will inherit an old one in regular intervals. This is a very future-proof concept that combines the best of both worlds. The price to pay is only the increased work which gets covered %fixme: uebernommen
    1.68 -by volunteers that \emph{want} to do it.
    1.69 +The basic idea is, regularly developing a new design from scratch while the current version is still in use and gets repaired. Hence a modern design will inherit an old one in regular intervals. This is a very future-proof concept that combines the best of both worlds. The price to pay is only the increased work which gets covered by volunteers that \emph{want} to do it.
    1.70  
    1.71  
    1.72