1.1 --- a/thesis/tex/3-MailTransferAgents.tex	Thu Dec 11 17:28:06 2008 +0100
     1.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Thu Dec 11 17:29:09 2008 +0100
     1.3 @@ -71,7 +71,7 @@
     1.4  
     1.5  The programs chosen are: \sendmail, \exim, \qmail, and \postfix. They are the most important representatives of the regarded group. Although \MTA\ statistics are rare, FIXME(have different results), and good data is hard to collect, these programs tend to stay near the top.
     1.6  
     1.7 -Table \ref{tab:mta-market-share} shows the Top 10 \MTA{}s of three different statistics. The first published by \name{O'ReillyNet} in YYYY \citeweb{oreillynet:mta-stats} , the second by \name{Mailradar.com} from YYYY \citeweb{mailradar:mta-stats} , and the third by \person{Daniel~J.\ Bernstein} (the author of \qmail) done in 2001 \citeweb{djb:mta-stats}.
     1.8 +Table \ref{tab:mta-market-share} shows the Top 10 \MTA{}s of three different statistics. The first published by \name{O'ReillyNet} in 2007 \citeweb{oreillynet:mta-stats} , the second by \name{MailRadar.com} from YYYY \citeweb{mailradar:mta-stats} , and the third by \person{Daniel~J.\ Bernstein} (the author of \qmail) done in 2001 \citeweb{djb:mta-stats}.
     1.9  
    1.10  \begin{table}
    1.11  	\begin{center}
    1.12 @@ -171,9 +171,9 @@
    1.13  
    1.14  Modular \MTA{}s are \NAME{MMDF}, \qmail, \postfix, and \name{MeTA1}. They consist of several programs, each doing a part of the overall job. The different programs run with the least permissions the need, and \emph{setuid root} needs not to be used.
    1.15  
    1.16 -The architecture does not directly define the program's security, but ``[t]he goal of making a software secure can be better achieved by making the design simple and easier to understand and verify''\cite[chapter 6]{hafiz05}. \exim, though being monolithic, has a fairly clean security record. But it is very hard to keep the security up, as the program growth. \person{Wietse Venema} (the author of \postfix) says, the architecture enabled \postfix\ to grow without running into security problems. \citeweb{venema:postfix-growth}
    1.17 +The architecture does not directly define the program's security, but ``[t]he goal of making a software secure can be better achieved by making the design simple and easier to understand and verify''\cite[chapter 6]{hafiz05}. \exim, though being monolithic, has a fairly clean security record. But it is very hard to keep the security up, as the program growth. \person{Wietse Venema} (the author of \postfix) says, the architecture enabled \postfix\ to grow without running into security problems. \citeweb[page 13]{venema:postfix-growth}
    1.18  
    1.19 -The modular design, with each sub-program doing one part of the overall job, is applied \name{Unix Philosophy}. The Unix Philosophy \cite{gancarz} demands ``small is beautiful'' and ``do one job and do it good''. Monolithic \MTA{}s fail here. %fixme: check correct wording
    1.20 +The modular design, with each sub-program doing one part of the overall job, is applied \name{Unix Philosophy}. The Unix Philosophy \cite{gancarz95} demands ``small is beautiful'' and ``make each program do one thing well''. Monolithic \MTA{}s fail here.
    1.21  
    1.22  Today modular \mta\ architectures are the state-of-the-art.
    1.23  
    1.24 @@ -183,8 +183,7 @@
    1.25  
    1.26  Section \ref{sec:what-will-be-important} tried to figure out the importances for future \MTA{}s. The four programs are compared on these (possible) future requirements now.
    1.27  
    1.28 -The first trend was provider independence, requiring easy configuration. \postfix\ seems to do best here. It has one single configuration file (FIXME) which is easy to manage. \sendmail\ and \qmail\ appear to have bad positions. Their configuration is complex, thus they would need simplification wrappers around them to provide easy configuration. For \path{sendmail.cf} exist the \name{m4} macros, but adjusting \path{sendmail.cf} by hand seems to be nessesary for non-trivial configurations. And \path{sendmail.cf}'s complexity, including Turing-completeness,%fixme: ref
    1.29 - is legendary. \qmail's configuration files are not so complex, but the whole system (requiring various system users) is complex to set up. \exim\ suffers most from its flexibility, like \sendmail. Flexibility and easy configuration are contrary.
    1.30 +The first trend was provider independence, requiring easy configuration. \postfix\ seems to do best here. It used primary two configuration files (\path{master.cf} and \path{main.cf}) which are easy to manage. \sendmail\ appears to have a bad position. Its configuration file \path{sendmail.cf} is very complex, including Turing-completeness, thus it needs simplification wrappers around it to provide easier configuration. There exist the \name{m4} macros to generate \path{sendmail.cf}, but adjusting the generated result by hand seems to be nessesary for non-trivial configurations. \qmail's configuration files are simple, but the whole system is complex to set up; it requires various system users and is hardly usable without applying several patches to add basic functionality. \name{netqmail} is the community effort to help here. \exim\ has only one single configuration file (\path{exim.conf}), but it suffers most from its flexibility, like \sendmail. Flexibility and easy configuration are contrary.
    1.31  
    1.32  As second trend, the decreasing nessesarity 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 then. Of course there still will be the need for high performance \MTA{}s, but a growing share of the market will not require high performance. Performance is related to simplicity, which effects security. Increasing performance does in most times decrease the other two. Simple \mta{}s not aiming for highest performance are what is needed in future. The simple of \qmail, still being fast enough, seems to be a good example.
    1.33  

     2.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Thu Dec 11 17:28:06 2008 +0100
     2.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Thu Dec 11 17:29:09 2008 +0100
     2.3 @@ -36,26 +36,27 @@
     2.4  
     2.5  \section{Directions to go}
     2.6  
     2.7 -<<  plans to get masqmail more popular again (if that is the goal) >> %FIXME
     2.8 +<<  plans to get masqmail more popular again (if that is the goal) >>
     2.9  
    2.10  
    2.11  \subsection{\masqmail\ in five years}
    2.12  
    2.13  Now how could \masqmail\ be like in, say, five years?
    2.14  
    2.15 -<< requirements >> %FIXME
    2.16 +<< requirements >>
    2.17  
    2.18 -<< which parts to do >> %FIXME
    2.19 +<< which parts to do >>
    2.20  
    2.21 -<< how to make masqmail future-safe >> %FIXME
    2.22 +<< how to make masqmail future-safe >>
    2.23  
    2.24 -<< how to advertise masqmail >> %FIXME
    2.25 +<< how to advertise masqmail >>
    2.26  
    2.27 -<< why is it worth to revive masqmail? >> %FIXME
    2.28 +<< why is it worth to revive masqmail? >>
    2.29  
    2.30  
    2.31 +<< short term goals --- long term goals >>
    2.32  
    2.33 -<<  concrete decisions based on results of the last 2 chapters >> %FIXME
    2.34 +<<  concrete decisions based on results of the last 2 chapters >>
    2.35  
    2.36  
    2.37  
    2.38 @@ -68,11 +69,11 @@
    2.39  
    2.40  A design from scratch?
    2.41  
    2.42 -<< what would be needed (effort) >> %FIXME
    2.43 +<< what would be needed (effort) >>
    2.44  
    2.45 -<< would one create it at all? >> %FIXME
    2.46 +<< would one create it at all? >>
    2.47  
    2.48 -<< should it be done? >> %FIXME
    2.49 +<< should it be done? >>
    2.50  
    2.51  
    2.52  
    2.53 @@ -115,6 +116,6 @@
    2.54  
    2.55  \section{Work to do}
    2.56  
    2.57 -<< which parts to take out and do within the thesis >> %FIXME
    2.58 +<< which parts to take out and do within the thesis >>
    2.59  
    2.60