1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Tue Jan 27 10:40:36 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Tue Jan 27 11:18:30 2009 +0100
     1.3 @@ -157,7 +157,7 @@
     1.4  
     1.5  Spam is identified by the results of a set of checks. Static rules, querying databases (\NAME{DNS} blacklists \cite{cole07} \cite{levine08}), requesting special client behavior (\name{greylisting} \cite{harris03}, \name{hashcash} \cite{back02}), or statistical analysis (\name{bayesian filters} \cite{graham02}) are checks that may be used. Running more checks leads to better results, but takes more system resources and more time.
     1.6  
     1.7 -Doing some basic checks during the \SMTP\ dialog seems to be a must \cite[page~25]{eisentraut05}. Including them into the \MTA\ makes them fast to avoid \SMTP\ dialog timeouts. For modularity and risibility reasons internal interfaces to specialized modules seem to be best.
     1.8 +Doing some basic checks during the \SMTP\ dialog seems to be a must \cite[page~25]{eisentraut05}. Including them into the \MTA\ makes them fast to avoid \SMTP\ dialog timeouts. For modularity and reusability reasons internal interfaces to specialized modules seem to be best. \person{Raymond} says: ``Modularity (simple parts, clean interfaces) is a way to organize programs to make them simpler.'' \cite[chapter~1]{raymond03}.
     1.9  
    1.10  More detailed checks after the message is queued should be done using external scanners. Interfaces to invoke them need to be defined. (See also the remarks about \name{amavis} in the next section.)
    1.11  
    1.12 @@ -552,7 +552,7 @@
    1.13  
    1.14  Besides these advantages of existing code, one must not forget that further work on it is often repair work. Small bug fixes are not the problem, but adding something for which the software originally was not designed for are problems. Such work often destroys the clear concepts of the software, especially in interweaved monolithic code.
    1.15  
    1.16 -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, currently. This means it is time to invest into a redesigning to build up a more modern product.
    1.17 +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 redesigning to build up a more modern product.
    1.18  
    1.19  In the author's view is \masqmail\ already needing a redesign since about 2003 when the old design was still quite suitable \dots\ it already delayed too long.
    1.20  
    1.21 @@ -570,8 +570,7 @@
    1.22  
    1.23  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.24  
    1.25 -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.26 -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.27 +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. 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.28  
    1.29  
    1.30  
    1.31 @@ -583,7 +582,7 @@
    1.32  
    1.33  One example how modular structure makes it easy to add further functionality: \person{Sill} describes that integrating the \name{amavis} filter framework into the \qmail\ system can be done by renaming the \name{qmail-queue} module to \name{qmail-queue-real} and renaming the \name{amavis} to \name{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable approach, but only possible in a modular system that consists of independent executables.
    1.34  
    1.35 -This thesis showed several times that modularity is the key property for good software design. This property 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 without depending on current code.
    1.36 +This thesis showed several times that modularity is a key property for good software design. This property 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 without depending on current code.
    1.37  
    1.38  
    1.39  
    1.40 @@ -625,6 +624,8 @@
    1.41  
    1.42  However, making such a cut is hard, especially if the bad design is still ``good enough''.
    1.43  
    1.44 +\person{Doug McIlroy}, a person with important influence on \unix\ especially by inventing the \unix\ pipe, gives valuable advice: ``To do a new job, build afresh rather than complicate old programs by adding new features.'' and: ``Don't hesitate to throw away the clumsy parts and rebuild them.'' \cite{mcilroy78}.
    1.45 +
    1.46  
    1.47  
    1.48