1.1 --- a/thesis/tex/1-Introduction.tex	Sun Feb 08 23:18:15 2009 +0100
     1.2 +++ b/thesis/tex/1-Introduction.tex	Sun Feb 08 23:51:48 2009 +0100
     1.3 @@ -143,7 +143,7 @@
     1.4  \hfill\citeweb{packages.debian:masqmail}
     1.5  \end{quote}
     1.6  
     1.7 -The program is a good replacement ``in these cases'' but not generally, since it lacks essential features for running on publically accessable mail servers. It is primarily not secure enough for being accessible from untrusted locations.
     1.8 +The program is a good replacement ``in these cases'' but not generally, since it lacks essential features for running on openly accessible mail servers. It is primarily not secure enough for being accessible from untrusted locations.
     1.9  
    1.10  \masqmail\ is best used in home networks which are non-permanently connected to the Internet. It is easy configurable for situations which are rarely solvable with the common \MTA{}s. Such include different handling of mail to local or remote destination and respecting different routes of online connection. These features are explained in more detail in section~\ref{sec:masqmail-features}.
    1.11  \index{non-permanent online connection}
    1.12 @@ -352,14 +352,12 @@
    1.13  \section{Why \masqmail\ is worth it}
    1.14  \index{masqmail}
    1.15  
    1.16 -First of all, \masqmail\ is better suited for its target field of operation (multiple non-permanent online connections) than every other \MTA. Especially is such usage easy to set up because \masqmail\ was designed for that. Many alternative \MTA{}s were not designed for those scenarios at all as the following two example show: ``Exim is designed for use on a network where most messages can be delivered at the first attempt.'' \cite[page~30]{hazel01}. ``qmail was designed for well-connected hosts: those with high-speed, always-on network connectivity.'' \cite[page9]{sill02}.
    1.17 +First of all, \masqmail\ is better suited for its target field of operation (multiple non-permanent online connections) than any other \MTA. Especially is such usage easy to set up because \masqmail\ was designed for it. Many alternative \MTA{}s were not designed for those scenarios as the following two example show: ``Exim is designed for use on a network where most messages can be delivered at the first attempt.'' \cite[page~30]{hazel01}. And: ``qmail was designed for well-connected hosts: those with high-speed, always-on network connectivity.'' \cite[page9]{sill02}.
    1.18  \index{non-permanent online connection}
    1.19  \index{qmail}
    1.20  \index{exim}
    1.21  
    1.22 -%fixme: hikernet
    1.23 -
    1.24 -Additionally does \masqmail\ make it easy to run an \MTA\ on workstations or notebooks. There is no need to do complex configuration or to be a mail server expert. Only a handful of options need to be set; the host name, the local networks, and one route for relaying are sufficient in most times.
    1.25 +\masqmail\ make it easy to run an \MTA\ on workstations or notebooks. There is no need to do complex configuration or to be a mail server expert. Only a handful of options need to be set; the host name, the local networks, and one route for relaying are sufficient in most times.
    1.26  \index{masqmail!on notebooks}
    1.27  \index{configuration}
    1.28  
    1.29 @@ -393,8 +391,11 @@
    1.30  \index{masqmail!on notebooks}
    1.31  
    1.32  
    1.33 +%fixme: hikernet
    1.34 +<< hikernet >>
    1.35  
    1.36 -Although the development on \masqmail\ has been stopped in 2003, \masqmail\ still has its users. Having users is already reason enough for further development and maintenance. This applies especially when the software covers a niche and when requirements for such software in general changed. Both is the case for \masqmail.
    1.37 +
    1.38 +Although the development of \masqmail\ has been stopped in 2003, \masqmail\ still has its users. Having users is already reason enough for further development and maintenance. This applies especially when the software covers a niche and when requirements for such software in general changed. Both is the case for \masqmail.
    1.39  
    1.40  It is difficult to get numbers about users of Free Software because no one needs to tell anyone when he uses some software. \name{Debian}'s \name{popcon} statistics \citeweb{popcon.debian} are a try to provided numbers. For January 2009, the statistics report 60 \masqmail\ installations of which 49 are in active use. If it is assumed that one third of all \name{Debian} users report their installed software\footnote{One third is a high guess as it means there would be only about 230 thousand \name{Debian} installations in total. But according to the \name{Linux Counter} \citeweb{counter.li.org} between 490 thousand and 12 million \name{Debian} users can be estimated.}, there would be in total around 150 active \masqmail\ installations in \name{Debian}. \name{Ubuntu} which also does \name{popcon} statistics \citeweb{popcon.ubuntu}, counts 82 installations with 13 active ones. If here also one third of all systems submit their data, 40 active installations can be added. Including a guessed amount of additional 30 installations on other Unix operating systems makes about 220 \masqmail\ installations in total. Of course one person may have \masqmail\ installed on more than one computer, but a total of 150 different users seems to be realistic.
    1.41  \index{Free Software}

     2.1 --- a/thesis/tex/2-MarketAnalysis.tex	Sun Feb 08 23:18:15 2009 +0100
     2.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Sun Feb 08 23:51:48 2009 +0100
     2.3 @@ -60,7 +60,7 @@
     2.4  	\label{fig:comm-lifecycle}
     2.5  \end{figure}
     2.6  
     2.7 -Video messages and voice mail are technologies in the introduction phase. Voice over \NAME{IP} is heavily growing these days. Instant Messaging has reached maturation and is still growing. Email is an example for a technology in the saturation phase. Telefax, for instance, is a declining technology.
     2.8 +Video messages and voice mail are technologies in the introduction phase. Voice over \NAME{IP} is heavily growing these days. Instant Messaging has reached maturation and is still growing. Email is an example for a technology in the saturation phase. Fax, for instance, is a declining technology.
     2.9  \index{fax}
    2.10  
    2.11  Email ranges in the saturation phase which is defined by a saturated market. No more products are needed: there is no more growth. This means, email is a technology which is used by everyone who want to use it. It is a standard technology. The current form of email in the current market is on the top of its life cycle. The future is decline, sooner or later.
    2.12 @@ -179,7 +179,7 @@
    2.13  The use of different hardware to access mail is another opportunity of the market. But as more hardware gets involved, the networks become more complex. Thus the need for more software and infrastructure to transfer mail within the growing network might be a weakness of the email system.
    2.14  
    2.15  An opportunity of the market and at the same time a strength of electronic mail is its standardization. Few other communication technologies are standardized, and thus freely available, in a similar way. Another opportunity and strength is the modular and extensible structure of electronic mail; it can easily evolve to new requirements.
    2.16 -\index{email!standardiziation}
    2.17 +\index{email!standardization}
    2.18  
    2.19  The increasing integration of communication channels is an opportunity for the market. But deciding whether it is a weakness or strength of email is difficult. Due to the impossibility to integrate synchronous stream data and large binary data, it is a weakness. But it is also a strength, because arbitrary asynchronous communication data already can be integrated. On the other hand, the integration might be a threat too, because integration often leads to complexity of software. Complex software is more error prone and thus less reliable. This, however, could again be a strength of electronic mail because its modular design decreases complexity.
    2.20  

     3.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Feb 08 23:18:15 2009 +0100
     3.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Feb 08 23:51:48 2009 +0100
     3.3 @@ -165,7 +165,7 @@
     3.4  The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \NAME{TLS}, the successor of \NAME{SSL}). \NAME{TLS} encrypts the datagrams of the \name{transport layer}. This means it works below the application protocols and can be used with any of them \citeweb{wikipedia:tls}.
     3.5  \index{tls}
     3.6  
     3.7 -Using secure tunnels that are provided by external programs should be preferred over including encryption into the application, because the application needs not to bother with encryption then. Outgoing \SMTP\ connections can get encrypted using a secure tunnel, created by an external application (like \name{openssl}). But incoming connections can not use external secure tunnels, because the remote \NAME{IP} address is hidden then; all connections would appear to come from localhost instead. Figure~\ref{fig:stunnel} depicts the situation of using an application like \name{stunnel} for incoming connections. The connection to port 25 comes from localhost and this information reaches the \MTA. Authentication based on \NAME{IP} addresses and many spam prevention methods are useless then.
     3.8 +Using secure tunnels that are provided by external programs should be preferred over including encryption into the application, because the application needs not to bother with encryption then. Outgoing \SMTP\ connections can get encrypted using a secure tunnel, created by an external application (like \name{openssl}). But incoming connections can not use external secure tunnels, because the remote \NAME{IP} address is hidden then; all connections would appear to come from the local host instead. Figure~\ref{fig:stunnel} depicts the situation of using an application like \name{stunnel} for incoming connections. The connection to port 25 comes from from local host and exactly this information is available to the \MTA. Authentication based on \NAME{IP} addresses and many spam prevention methods are useless then.
     3.9  \index{secure tunnel}
    3.10  \index{stunnel}
    3.11  \index{openssl}
    3.12 @@ -488,7 +488,7 @@
    3.13  \index{testability}
    3.14  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.
    3.15  
    3.16 -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.
    3.17 +Two additional scripts exist to send a set of mails to different kinds of recipients. They can be used for automated testing, but both check only the function of the whole system, not its parts.
    3.18  \index{test program}
    3.19  
    3.20  
    3.21 @@ -535,7 +535,7 @@
    3.22  
    3.23  The functional requirements that receive highest attention are \RF\,6 (authentication), \RF\,7 (encryption), and \RF\,8 (spam handling). Of the non-functional requirements, \RG\,1 (security), \RG\,2 (reliability), and \RG\,4 (extendability), rank highest.
    3.24  
    3.25 -These tasks are presented in more detail in a todo list, now. The list is sorted by focus and then by importance.
    3.26 +These tasks are presented in more detail in a to-do list, now. The list is sorted by focus and then by importance.
    3.27  
    3.28  
    3.29  \subsubsection*{\TODO\,1: Encryption (\RF\,7)}
    3.30 @@ -719,7 +719,7 @@
    3.31  \index{pipe}
    3.32  \index{Unix}
    3.33  
    3.34 -Repair strategies are useful, but only in the short-time view and in times of trouble. If the future is bright, however, one does best by investing into a software. As shown in section~\ref{sec:market-analysis-conclusion}, the future for \MTA{}s is bright. This means it is time to invest into a redesign with the intension to build up a more modern product.
    3.35 +Repair strategies are useful, but only in the short-time view and in times of trouble. If the future is bright, however, one does best by investing into a software. As shown in section~\ref{sec:market-analysis-conclusion}, the future for \MTA{}s is bright. This means it is time to invest into a redesign with the intention to build up a more modern product.
    3.36  
    3.37  In the author's view is \masqmail\ already needing this redesign since about 2003 when the old design was still quite suitable \dots\ it already delayed too long.
    3.38  \index{masqmail!new design}
    3.39 @@ -746,7 +746,7 @@
    3.40  Redesigning a software as requirements change helps keeping it alive.
    3.41  \index{redesign}
    3.42  
    3.43 -The knowledge of \person{Heraclitus}, a Greek philosopher, shall be an inspriation: ``Nothing endures but change.''
    3.44 +The knowledge of \person{Heraclitus}, a Greek philosopher, shall be an inspiration: ``Nothing endures but change.''
    3.45  
    3.46  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.
    3.47  \index{qmail}
    3.48 @@ -829,7 +829,7 @@
    3.49  Free Software ``sells'' if it has a good user base. For example: Although \qmail\ is somehow outdated and its author has not released any new version since about ten years, \qmail\ still has a very strong user base and community.
    3.50  \index{qmail}
    3.51  
    3.52 -Good concepts, sound design, and a sane philosophy gives users good feelings for the software and faith in it. They become interested in using it and to contribute. In contrast do constant repaire work and reappearance of weaknesses leave a bad feeling.
    3.53 +Good concepts, sound design, and a sane philosophy gives users good feelings for the software and faith in it. They become interested in using it and to contribute. In contrast do constant repair work and reappearance of weaknesses leave a bad feeling.
    3.54  
    3.55  The motivation of most volunteer developers is their wish to do good work with the goal to create good software. Projects that follow admirable plans towards a good product will motivate volunteers to help. More helpers can get the 2,5 man-years for a new design in less absolute time done. Additionally is a good developers base the best start for a good user base, and users define a software's value.
    3.56  \index{development!motivation}

     4.1 --- a/thesis/tex/5-Improvements.tex	Sun Feb 08 23:18:15 2009 +0100
     4.2 +++ b/thesis/tex/5-Improvements.tex	Sun Feb 08 23:51:48 2009 +0100
     4.3 @@ -32,7 +32,7 @@
     4.4  The third file controls the configuration files. New configuration options need to be added. The encryption policy for incoming connections needs to be defined. Three choices seem necessary: no encryption, offer encryption, insist on encryption. The encryption policy for outgoing connections should be part of each route setup. The options are the same: never encrypt, encrypt if possible, insist on encryption.
     4.5  \index{configuration}
     4.6  
     4.7 -\subsubsection*{Depencencies}
     4.8 +\subsubsection*{Dependencies}
     4.9  
    4.10  \NAME{STARTTLS} uses \NAME{TLS} encryption which is based on certificates. Thus the \MTA\ needs its own certificate. This should be generated during installation. A third party application like \name{openssl} should be taken for this job. The encryption itself should also be done using an available library. \name{openssl} or a substitute like \name{gnutls} does then become a dependency for \masqmail. \name{gnutls} seems to be the better choice because the \name{openssl} license is incompatible to the \NAME{GPL}, under which \masqmail\ and \name{gnutls} are covered.
    4.11  \index{tls}
    4.12 @@ -553,7 +553,7 @@
    4.13  \index{qmail}
    4.14  \index{root privilege}
    4.15  
    4.16 -The \name{queue-in} module is the part of the system that is most critical about permission. It either needs to run as deamon or be \name{setuid} or \name{setgid} in order to avoid a world-writable queue. \person{Ian~R.\ Justman} recommends to use \name{setgid} in this situation:
    4.17 +The \name{queue-in} module is the part of the system that is most critical about permission. It either needs to run as daemon or be \name{setuid} or \name{setgid} in order to avoid a world-writable queue. \person{Ian~R.\ Justman} recommends to use \name{setgid} in this situation:
    4.18  \index{setuid}
    4.19  
    4.20  \begin{quote}
    4.21 @@ -561,7 +561,7 @@
    4.22  \hfill\cite{justman:bugtraq}
    4.23  \end{quote}
    4.24  
    4.25 -\person{Bernstein} chose \name{setuid} for the \name{qmail-queue} module, \person{Venema} uses \name{setgid} in \postfix, yet the differences are small. Better than running the module as a deamon is each of them. A deamon needs more resources and therefore becomes inefficient on systems with low mail amount, like the ones \masqmail\ will probably run on. Short running processes are additionally higher obstacles for intruders, because a process will die soon if an intruder managed to take one over.
    4.26 +\person{Bernstein} chose \name{setuid} for the \name{qmail-queue} module, \person{Venema} uses \name{setgid} in \postfix, yet the differences are small. Better than running the module as a daemon is each of them. A daemon needs more resources and therefore becomes inefficient on systems with low mail amount, like the ones \masqmail\ will probably run on. Short running processes are additionally higher obstacles for intruders, because a process will die soon if an intruder managed to take one over.
    4.27  \index{qmail}
    4.28  \index{postfix}
    4.29  \index{setuid}

     5.1 --- a/thesis/tex/rfcs.tex	Sun Feb 08 23:18:15 2009 +0100
     5.2 +++ b/thesis/tex/rfcs.tex	Sun Feb 08 23:51:48 2009 +0100
     5.3 @@ -6,7 +6,7 @@
     5.4  A particular \RFC\ is located at {\small\url{http://tools.ietf.org/rfc/rfcNNNN.txt}}\,, where ``\texttt{NNNN}'' is the four-digit number of that \RFC. For example is \RFC\,821 located at {\small\url{http://tools.ietf.org/rfc/rfc0821.txt}}\,.
     5.5  \index{rfc}
     5.6  
     5.7 -More comfortable to browse are the \NAME{HTML} formated representations which contain navigation hyperlinks. They are accessable at {\small\url{http://tools.ietf.org/html/rfcNNNN}}\,.
     5.8 +More comfortable to browse are the \NAME{HTML} formatted representations which contain navigation hyperlinks. They are accessible at {\small\url{http://tools.ietf.org/html/rfcNNNN}}\,.
     5.9  
    5.10  Following is a list of \RFC{}s which are relevant for this thesis. An extensive list of mail-related \RFC{}s is available at \citeweb{imc:mail-rfcs}.
    5.11