1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Feb 08 23:18:15 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Feb 08 23:51:48 2009 +0100
     1.3 @@ -165,7 +165,7 @@
     1.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}.
     1.5  \index{tls}
     1.6  
     1.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.
     1.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.
     1.9  \index{secure tunnel}
    1.10  \index{stunnel}
    1.11  \index{openssl}
    1.12 @@ -488,7 +488,7 @@
    1.13  \index{testability}
    1.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.
    1.15  
    1.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.
    1.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.
    1.18  \index{test program}
    1.19  
    1.20  
    1.21 @@ -535,7 +535,7 @@
    1.22  
    1.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.
    1.24  
    1.25 -These tasks are presented in more detail in a todo list, now. The list is sorted by focus and then by importance.
    1.26 +These tasks are presented in more detail in a to-do list, now. The list is sorted by focus and then by importance.
    1.27  
    1.28  
    1.29  \subsubsection*{\TODO\,1: Encryption (\RF\,7)}
    1.30 @@ -719,7 +719,7 @@
    1.31  \index{pipe}
    1.32  \index{Unix}
    1.33  
    1.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.
    1.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.
    1.36  
    1.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.
    1.38  \index{masqmail!new design}
    1.39 @@ -746,7 +746,7 @@
    1.40  Redesigning a software as requirements change helps keeping it alive.
    1.41  \index{redesign}
    1.42  
    1.43 -The knowledge of \person{Heraclitus}, a Greek philosopher, shall be an inspriation: ``Nothing endures but change.''
    1.44 +The knowledge of \person{Heraclitus}, a Greek philosopher, shall be an inspiration: ``Nothing endures but change.''
    1.45  
    1.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.
    1.47  \index{qmail}
    1.48 @@ -829,7 +829,7 @@
    1.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.
    1.50  \index{qmail}
    1.51  
    1.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.
    1.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.
    1.54  
    1.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.
    1.56  \index{development!motivation}