1.1 --- a/thesis/tex/2-MarketAnalysis.tex	Wed Jan 21 17:26:18 2009 +0100
     1.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Wed Jan 21 20:35:26 2009 +0100
     1.3 @@ -71,7 +71,6 @@
     1.4  There is a consolidation of communication technologies with similar transport characteristics, nowadays. Email is the most flexible kind of asynchronous communication technology in major use. Hence email is the best choice for transferring messages of any kind today. But in future it probably will be \name{Unified Messaging}, which tries to group all kinds of asynchronous messaging into one communication system. It aims to provide transparent transport for all kinds of content and flexible access interfaces for all kinds of clients. Unified messaging seems to have the potential to be the successor of all asynchronous communication technologies, including email.
     1.5  
     1.6  Today email still is the major asynchronous communication technology and it probably will be it for the next years. As Unified Messaging needs similar transfer facilities to email, it may to be an evolution not a revolution. Hence \mta{}s will still have importance in future, maybe in a modified way.
     1.7 -%todo: decentral organization, like the internet -> MTAs are well suited -> further technologies will need something similar
     1.8  
     1.9  
    1.10  \subsubsection*{Integration}

     2.1 --- a/thesis/tex/3-MailTransferAgents.tex	Wed Jan 21 17:26:18 2009 +0100
     2.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Wed Jan 21 20:35:26 2009 +0100
     2.3 @@ -57,8 +57,7 @@
     2.4  \subsubsection*{Other segmenting}
     2.5  \name{Mail transfer agents} can also be split in other ways.
     2.6  
     2.7 -Due to \sendmail's significance in the early times of email, compatibility interfaces for \sendmail\ are important for \unix\ \MTA{}s. The reason is that many mail applications simply the \sendmail\ \MTA\ to be installed on the system. Being not \emph{sendmail-compatible} may not matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on \unix\ systems. Hence being sendmail-compatible is a major property of a \mta. %todo: how many MTAs are sendmail-compatible?
     2.8 -\MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility add-on, will not be covered here. One example for such a program is \name{Apache James}.  %FIXME: check if correct
     2.9 +Due to \sendmail's significance in the early times of email, compatibility interfaces for \sendmail\ are important for \unix\ \MTA{}s. The reason is that many mail applications simply the \sendmail\ \MTA\ to be installed on the system. Being not \emph{sendmail-compatible} may not matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on \unix\ systems. Hence being sendmail-compatible is a major property of a \mta. \MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility add-on, will not be covered here. One example for such a program is \name{Apache James}.  %FIXME: check if correct
    2.10  
    2.11  Another separation can be done between \freesw\ \MTA{}s and proprietary ones. Many of the \MTA{}s for \unix\ systems are \freesw. Only these are regarded in the following sections, because comparing \freesw\ with proprietary or commercial software is not what typical users of programs like \masqmail\ do. %fixme: what are typical users?
    2.12  Comparison with non-free programs may be a point for large \freesw\ projects, trying to step into the business world. Small projects, mostly used by individuals at home, %fixme: is this the right target field? see chap02
    2.13 @@ -131,7 +130,7 @@
    2.14  \sendmail\ designed to transfer mails between different protocols and networks, this lead to a very flexible, though complex, configuration.
    2.15  
    2.16  It was first released with \NAME{BSD} 4.1c in 1983.
    2.17 -%todo: write about its importance and about sendmail-compat
    2.18 +%fixme: write about its importance and about sendmail-compat
    2.19  
    2.20  The latest version is 8.14.3 from May 2008. The program is distributed under the \name{Sendmail License} as both, \freesw\ and proprietary software.
    2.21  
    2.22 @@ -190,7 +189,6 @@
    2.23  Here provided is an overview important properties of the four previously introduced \MTA{}s. The data comes from the above stated sources and is collected in table \ref{tab:mta-comparison}\footnote{The lines of code were measured with \person{David~A.\ Wheeler}'s \name{sloccount} \citeweb{sloccount}.}.
    2.24  
    2.25  \begin{table}
    2.26 -% FIXME: improve table data!!!
    2.27  	\begin{center}
    2.28  		\input{tbl/mta-comparison.tbl}
    2.29  	\end{center}
    2.30 @@ -256,5 +254,5 @@
    2.31  Now, the reader should have a general knowledge about the four important \MTA{}s. Further chapters will refer frequently to them.
    2.32  
    2.33  
    2.34 -%todo: my own poll (?)
    2.35 +%fixme: my own poll (?)
    2.36  

     3.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 21 17:26:18 2009 +0100
     3.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 21 20:35:26 2009 +0100
     3.3 @@ -44,7 +44,7 @@
     3.4  
     3.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.
     3.6  
     3.7 -%todo: is the def of MTA: transfer between machines, or transfer between users?
     3.8 +%fixme: is the def of MTA: transfer between machines, or transfer between users?
     3.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.
    3.10  
    3.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.
    3.12 @@ -229,7 +229,7 @@
    3.13  \subsection{Architecture}
    3.14  \label{sec:discussion-mta-arch}
    3.15  
    3.16 -%todo: what's this section to do with requirements?
    3.17 +%fixme: what's this section to do with requirements?
    3.18  
    3.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
    3.20  \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules.
    3.21 @@ -335,7 +335,7 @@
    3.22  
    3.23  \paragraph{\RG3: Robustness}
    3.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.
    3.25 -%todo: rule of robustness, rule of repair
    3.26 +%fixme: rule of robustness, rule of repair
    3.27  
    3.28  \paragraph{\RG4: Extendability}
    3.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.
    3.30 @@ -548,8 +548,7 @@
    3.31  
    3.32  A new design does protect against such dead ends.
    3.33  
    3.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 ??
    3.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)
    3.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)
    3.37  
    3.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
    3.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.
    3.40 @@ -577,8 +576,7 @@
    3.41  
    3.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.
    3.43  
    3.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
    3.45 -early quality improvements and later function improvements. This is real-life experience in Free Software development.
    3.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.
    3.47  
    3.48  
    3.49  
    3.50 @@ -593,7 +591,7 @@
    3.51  
    3.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.
    3.53  
    3.54 -%fixme: define exactly, be clear: what does break even here mean
    3.55 +%fixme: define exactly, be clear: what does ``break even'' here mean
    3.56  
    3.57  
    3.58  
    3.59 @@ -654,11 +652,9 @@
    3.60  \item The long-time plan: Design a new architecture that satisfies the modern requirements especially the quality requirements.
    3.61  \end{enumerate}
    3.62  
    3.63 -The background thought is to first do the most needed stuff on the existing code to keep %fixme: erhalten
    3.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.
    3.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.
    3.66  
    3.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
    3.68 -by volunteers that \emph{want} to do it.
    3.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.
    3.70  
    3.71  
    3.72  

     4.1 --- a/thesis/tex/5-Improvements.tex	Wed Jan 21 17:26:18 2009 +0100
     4.2 +++ b/thesis/tex/5-Improvements.tex	Wed Jan 21 20:35:26 2009 +0100
     4.3 @@ -386,7 +386,7 @@
     4.4  The \name{outgoing} queue contains processed messages. The header and envelope information is complete and in valid form.
     4.5  
     4.6  \name{Receiver modules} are the communication interface between outside senders and the \name{queue-in} module. Each protocol needs a corresponding \name{receiver module} to be supported. Most popular are the \name{sendmail} module (which is a command to be called from the local host) and the \name{smtpd} module (which listens on port 25). Other modules to support other protocols may be added as needed.
     4.7 -%todo: get invoked by inetd, or better ucspi-tcp (by bernstein) which can limit max number of concurrent connections. and includes tcp-wrappers functionality.
     4.8 +%fixme: get invoked by inetd, or better ucspi-tcp (by bernstein) which can limit max number of concurrent connections. and includes tcp-wrappers functionality.
     4.9  
    4.10  
    4.11  \name{Transport modules}, on the oppersite side of the system, are the modules to send outgoing mail; they are the interface between \name{queue-out} and remote hosts or local commands for further processing. The most popular ones are the \name{smtp} module (which acts as the \SMTP\ client) and the \name{pipe} module (to interface gateways to other systems or networks, like fax or uucp). A module for local delivery is not included, as it is in most other \MTA{}s; the reasons are described in FIXME.%fixme