1.1 --- a/thesis/fig/masqmail-typical-usage.pic	Sat Feb 07 22:51:17 2009 +0100
     1.2 +++ b/thesis/fig/masqmail-typical-usage.pic	Sat Feb 07 23:47:34 2009 +0100
     1.3 @@ -39,7 +39,7 @@
     1.4  
     1.5  move to last [].e
     1.6  
     1.7 -move 0.5
     1.8 +move movewid/2
     1.9  
    1.10  
    1.11  [

     2.1 --- a/thesis/tex/0-preface.tex	Sat Feb 07 22:51:17 2009 +0100
     2.2 +++ b/thesis/tex/0-preface.tex	Sat Feb 07 23:47:34 2009 +0100
     2.3 @@ -4,7 +4,7 @@
     2.4  
     2.5  This thesis is about \masqmail, a small mail transfer agent for workstations and home networks. In October 2007 I had chosen \masqmail\ for my machines because of its small size though it was a ``real'' mail transfer agent. \masqmail\ served me well since then and I have found no reasons to change.
     2.6  
     2.7 -Unfortunately, the \masqmail\ package in \name{Debian}, which is my preferred \NAME{GNU}/Linux distribution, is unmaintained since the beginning of 2008. Unmaintained packages are likely to get dropped out of a distribution if critical bugs appear in them. Although \masqmail\ had no critical bugs, this was a situation I definitely wanted to prevent.
     2.8 +Unfortunately, the \masqmail\ package in \name{Debian}, which is my preferred \NAME{GNU}/Li\-nux distribution, is unmaintained since the beginning of 2008. Unmaintained packages are likely to get dropped out of a distribution if critical bugs appear in them. Although \masqmail\ had no critical bugs, this was a situation I definitely wanted to prevent.
     2.9  
    2.10  Using my diploma thesis as a ``power-start'' for maintaining and developing \masqmail\ in the future was a great idea. As it came to my mind I knew this is the thing I \emph{wanted} to do. --- I did it! :-)
    2.11  
    2.12 @@ -65,7 +65,7 @@
    2.13  References to external resources are marked using one of three styles, distinguished by the type of resource.
    2.14  
    2.15  \begin{enumerate}
    2.16 -\item References to books, articles, and similar documents look like this: \cite{kernighan84}. The letters represent the author(s) (here \person{Kernighan} and \person{Pike}), while the number represents the year of publication (here 1984).
    2.17 +\item References to books, articles, and documents of similar kind, look like this: \cite{kernighan84}. The letters represent the author(s) (here \person{Kernighan} and \person{Pike}), while the number represents the year of publication (here 1984).
    2.18  
    2.19  \item Websites are different from documents as they are less some text written by some author but more a place where information is gathered. Website may also change from time to time, thus the date of access is given to indicate the version to which was referred. References to websites have such appearance: \citeweb{masqmail:homepage}.
    2.20  

     3.1 --- a/thesis/tex/1-Introduction.tex	Sat Feb 07 22:51:17 2009 +0100
     3.2 +++ b/thesis/tex/1-Introduction.tex	Sat Feb 07 23:47:34 2009 +0100
     3.3 @@ -276,7 +276,7 @@
     3.4  Mail queuing is essential for \masqmail\ and thus supported of course, alias expansion is also supported.
     3.5  \index{alias expansion}
     3.6  
     3.7 -The \masqmail\ executable can be called by various names for sendmail-compatibility reasons. As many programs expect the \MTA\ to be located at \path{/usr/lib/sendmail} or \path{/usr/sbin/sendmail}, symbolic links are pointing from there to the \masqmail\ executable. Furthermore does \sendmail\ support calling it with a different name instead of supplying command line arguments. The best known of these shortcuts is \path{mailq} which is equivalent to calling it with the argument \verb+-bq+. \masqmail\ recognizes the shortcuts \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The first two are inspired by \sendmail. Not implemented yet is the shortcut \path{newaliases} because \masqmail\ does not generate binary representations of the alias file.\footnote{A shell script named \path{newaliases} that invokes \texttt{masqmail -bi} can provide the command to satisfy strict requirements.} \path{hoststat} and \path{purgestat} are missing for complete sendmail-compatibility.
     3.8 +The \masqmail\ executable can be called by various names for sendmail-com\-pa\-ti\-bi\-li\-ty reasons. As many programs expect the \MTA\ to be located at \path{/usr/lib/sendmail} or \path{/usr/sbin/sendmail}, symbolic links are pointing from there to the \masqmail\ executable. Furthermore does \sendmail\ support calling it with a different name instead of supplying command line arguments. The best known of these shortcuts is \path{mailq} which is equivalent to calling it with the argument \verb+-bq+. \masqmail\ recognizes the shortcuts \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The first two are inspired by \sendmail. Not implemented yet is the shortcut \path{newaliases} because \masqmail\ does not generate binary representations of the alias file.\footnote{A shell script named \path{newaliases} that invokes \texttt{masqmail -bi} can provide the command to satisfy strict requirements.} \path{hoststat} and \path{purgestat} are missing for complete sendmail-compatibility.
     3.9  \index{sendmail!compatibility}
    3.10  \index{symbolic link}
    3.11  \index{shortcuts}

     4.1 --- a/thesis/tex/2-MarketAnalysis.tex	Sat Feb 07 22:51:17 2009 +0100
     4.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Sat Feb 07 23:47:34 2009 +0100
     4.3 @@ -97,7 +97,7 @@
     4.4  
     4.5  \subsubsection*{Communication hardware}
     4.6  
     4.7 -Communication hardware comes from two different roots: On one side, the telephone, now available as mobile phones. This group centers around recorded data and dialog but messages are also supported by the answering machine and \NAME{SMS}. On the other side, mail and its relatives like email, which use computers as main hardware. This part centers around document messages but also supports dialog communication in Instant Messaging and Voice over \NAME{IP}.
     4.8 +Communication hardware comes from two different roots: On one side, the telephone, now available as mobile phones. This group centers around re\-cor\-ded data and dialog but messages are also supported by the answering machine and \NAME{SMS}. On the other side, mail and its relatives like email, which use computers as main hardware. This part centers around document messages but also supports dialog communication in Instant Messaging and Voice over \NAME{IP}.
     4.9  
    4.10  The last years finally brought the two groups together, with \name{smart phones} being the merging hardware element. Smart phones are computers in the size of mobile phones or mobile phones with the capabilities of computers, however one likes to see it. They provide both functions by being telephones \emph{and} computers.
    4.11  \index{smart phone}
    4.12 @@ -165,7 +165,7 @@
    4.13  \hfill\cite{wheeler03}
    4.14  \end{quote}
    4.15  
    4.16 -The amount of spam is huge. Panda Security and Commtouch state in their \name{Email Threats Trend Report} for the second Quarter of 2008: ``Spam levels throughout the second quarter averaged 77\,\%, ranging from a low of 64\,\% to a peak of 94\,\% of all email [...]'' \cite[page 4]{panda:email-threats}. The report sees the main source of spam in bot nets consisting of zombie computers: ``Spam and malware levels remain high for yet another quarter, powered by the brawny yet agile networks of zombie \NAME{IP}s.'' \cite[page 1]{panda:email-threats}. This is supported by IronPort Systems: ``More than 80 percent of spam now comes from a `zombie'---an infected \NAME{PC}, typically in a consumer broadband network, that has been hijacked by spammers.'' \cite{ironport:zombie-computers}. Positive for \MTA{}s is that they are not the main source for spam, but it is only a small delight. Spam is a general weakness of the email system because it is not stoppable.
    4.17 +The amount of spam is huge. Panda Security and Commtouch write in their \name{Email Threats Trend Report} for the second Quarter of 2008: ``Spam levels throughout the second quarter averaged 77\,\%, ranging from a low of 64\,\% to a peak of 94\,\% of all email [...]'' \cite[page 4]{panda:email-threats}. The report sees the main source of spam in bot nets consisting of zombie computers: ``Spam and malware levels remain high for yet another quarter, powered by the brawny yet agile networks of zombie \NAME{IP}s.'' \cite[page 1]{panda:email-threats}. This is supported by IronPort Systems: ``More than 80 percent of spam now comes from a `zombie'---an infected \NAME{PC}, typically in a consumer broadband network, that has been hijacked by spammers.'' \cite{ironport:zombie-computers}. Positive for \MTA{}s is that they are not the main source for spam, but it is only a small delight. Spam is a general weakness of the email system because it is not stoppable.
    4.18  \index{spam!sources of}
    4.19  
    4.20  
    4.21 @@ -265,7 +265,7 @@
    4.22  
    4.23  \MTA{}s are still important in this new email architecture, but in a slightly different way. They do not transfer mail itself anymore, but they transport the notifications about new mail to the destinations. This is a quite similar job as in the \NAME{SMTP} model. The real transfer of the mail, however, can be done in an arbitrary way, for example via \NAME{FTP} or \NAME{SCP}.
    4.24  
    4.25 -A second concept, this one primary to arm against spam, is \person{David~A.\ Wheeler}'s \name{Guarded Email} \cite{wheeler03}. It requires messages to be recognized as Ham (non-spam) to be accepted, otherwise a challenge-response authentication will be initiated.
    4.26 +A second concept, this one primary to arm against spam, is \person{David~A.\ Whee\-ler}'s \name{Guarded Email} \cite{wheeler03}. It requires messages to be recognized as Ham (non-spam) to be accepted, otherwise a challenge-response authentication will be initiated.
    4.27  \index{Guarded Email}
    4.28  
    4.29  \name{Hashcash} by \person{Adam Back}---a third concept---tries to limit spam and denial of service attacks \cite{back02}. It requests payment for email. The costs are computing time for the generation of hash values. Thus sending spam becomes expensive. Further information about \name{Hashcash} can be found on \citeweb{hashcash:homepage}.

     5.1 --- a/thesis/tex/3-MailTransferAgents.tex	Sat Feb 07 22:51:17 2009 +0100
     5.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Sat Feb 07 23:47:34 2009 +0100
     5.3 @@ -274,7 +274,7 @@
     5.4  
     5.5  \paragraph{Performance}
     5.6  \index{performance}
     5.7 -As second trend, the decreasing necessity for high performance was identified. This goes along with the move of \MTA{}s from service providers to home servers. \postfix\ focuses much on performance, this might not be an important point in the future. Of course there will still be the need for high performance \MTA{}s, but a growing share of the market will not require high performance. Energy and space efficiency is related to performance; it is a similar goal in a different direction. But optimization, be it for performance or other efficiencies, is often in contrast to simplicity and clarity; these two improve security. Optimizing does in most times decrease the simplicity and clarity. Simple \MTA{}s that do not aim for high performance are what is needed in future. The simple design of \qmail\footnote{\qmail\ is still fast} is a good example.
     5.8 +As second trend was the decreasing necessity for high per\-for\-mance identified. This goes along with the move of \MTA{}s from service providers to home servers. \postfix\ focuses much on performance, this might not be an important point in the future. Of course there will still be the need for high performance \MTA{}s, but a growing share of the market will not require high performance. Energy and space efficiency is related to performance; it is a similar goal in a different direction. But optimization, be it for performance or other efficiencies, is often in contrast to simplicity and clarity; these two improve security. Optimizing does in most times decrease the simplicity and clarity. Simple \MTA{}s that do not aim for high performance are what is needed in future. The simple design of \qmail\footnote{\qmail\ is still fast} is a good example.
     5.9  
    5.10  \paragraph{Security}
    5.11  \index{security}

     6.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 22:51:17 2009 +0100
     6.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 23:47:34 2009 +0100
     6.3 @@ -699,12 +699,14 @@
     6.4  
     6.5  A new design does protect against such dead ends.
     6.6  
     6.7 -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.
     6.8 +Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail; it 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.
     6.9  \index{sendmail}
    6.10  
    6.11 -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.''
    6.12 +Redesigning a software as requirements change helps keeping it alive.
    6.13  \index{redesign}
    6.14  
    6.15 +The knowledge of \person{Heraclitus}, a Greek philosopher, shall be an inspriation: ``Nothing endures but change.''
    6.16 +
    6.17  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.
    6.18  \index{suckless}
    6.19  
    6.20 @@ -717,7 +719,7 @@
    6.21  
    6.22  The avoidance of dead ends is essential for further development on current code, too. Hence it is mandatory to refactor the existing code base sooner or later. Most important is the intention to modularize it, as modularity improves many quality properties, eases further development, and essentially improves security.
    6.23  
    6.24 -One example how modular structure makes it easy to add further functionality is described by \person{Sill}: He says that integrating the \name{amavis} filter framework into the \qmail\ system can be done by simply renaming the \path{qmail-queue} module to \path{qmail-queue-real} and renaming the \path{amavis} executable to \path{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable ability which is only possible in a modular system that consists of independent executables.
    6.25 +One example how modular structure makes it easy to add further functionality is described by \person{Sill}: He says that integrating the \name{amavis} filter framework into the \qmail\ system can be done by simply renaming the \path{qmail-queue} module to \path{qmail-queue-real} and then renaming the \path{amavis} executable to \path{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable ability which is only possible in a modular system that consists of independent executables.
    6.26  \index{modularity}
    6.27  
    6.28  This thesis showed several times that modularity is a key property for good software design. Modularity can hardly be retrofitted into software, hence development on base of current code will need a throughout restructuring too, to modularize the source code. Thus a new design is similar to such a throughout refactoring, except the dependence on current code.