1.1 --- a/thesis/tex/3-MailTransferAgents.tex	Tue Jan 20 21:55:22 2009 +0100
     1.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Wed Jan 21 14:48:10 2009 +0100
     1.3 @@ -202,15 +202,15 @@
     1.4  \subsubsection*{Architecture}
     1.5  
     1.6  Architecture is most important when comparing \MTA{}s. Many other properties of a program depend on its architecture. %fixme: add ref?
     1.7 -\person{Munawar Hafiz} \cite{hafiz05} discusses in detail on \mta\ architecture, comparing \sendmail, \qmail, \postfix, and \name{sendmail X}. \person{Jonathan de Boyne Pollard}'s \MTA\ review \cite{jdebp} is a source too.
     1.8 +\person{Munawar Hafiz} \cite{hafiz05} discusses in detail on \MTA\ architecture, comparing \sendmail, \qmail, \postfix, and \name{sendmail X}. \person{Jonathan de Boyne Pollard}'s \MTA\ review \cite{jdebp} is a source too.
     1.9  
    1.10  Two different architecture types show off: monolithic and modular \mta{}s.
    1.11  
    1.12 -Monolithic \MTA{}s are \sendmail, \name{smail}, \exim, and \masqmail. They all consist of one single \emph{setuid root}\footnote{\emph{setuid root} lets a program run with the rights of its owner, here root. This is considered to be a security risk often. Thus it it should be avoided if possible.} binary which does all the work.
    1.13 +Monolithic \MTA{}s are \sendmail, \name{smail}, \exim, and \masqmail. They all consist of one single \emph{setuid root}\footnote{\emph{setuid root} lets a program run with the rights of its owner, here root. This is considered to be a security risk. Thus it it should be avoided if possible.} binary which does all the work.
    1.14  
    1.15 -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} can be avoided.
    1.16 +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} can be avoided completely.
    1.17  
    1.18 -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, it was the architecture that enabled \postfix\ to grow without running into security problems. \cite[page 13]{venema:postfix-growth}
    1.19 +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, it was the architecture that enabled \postfix\ to grow without running into security problems. \cite[page 13]{venema:postfix-growth}
    1.20  
    1.21  The modular design, with each sub-program doing one part of the overall job, conforms to the \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.22  
    1.23 @@ -219,16 +219,22 @@
    1.24  
    1.25  \subsubsection*{Spam checking and content processing}
    1.26  
    1.27 -<< FIXME >> % fixme
    1.28 +Spam and malware increased during the last years. Today it is important for an \MTA\ to be able to provide checking for bad mail. This can be done by implementing functionality into the \MTA, or by invoking external programs to do this job.
    1.29  
    1.30 +\sendmail\ invented \name{milter} which is the common abbreviation for the \name{sendmail mail filter} \NAME{API}. It is used to interface external programs of various kind. \postfix\ adopted the \name{milter} interface, but is also able to easily include scanning modules into its modular structure. \qmail\ is pretty old and did not evolve with the changing market situation. Anyhow, its modular structure enables external scanners to be included into \qmail. \exim\ has the advantage that is was designed with the goal to provide extensive scanning facilities. It is therefore very good suited to scan itself or invoke external scanners.
    1.31  
    1.32 -\subsubsection*{Future requirements}
    1.33 +
    1.34 +\subsubsection*{Provider independence}
    1.35  
    1.36  In chapter \ref{chap:market-analysis}, it was tried to figure out trends and future requirements for \MTA{}s. The four programs are compared on these (possible) future requirements now.
    1.37  
    1.38 -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 cryptic and very complex (it has legendary 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 appears to be necessary 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 almost always contrary goals.
    1.39 +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 cryptic and very complex (it has legendary Turing-completeness) thus it needs simplification wrappers around it to provide easier configuration. They exist in form of the \name{m4} macros that generate a \path{sendmail.cf} file. But adjusting the generated result by hand appears to be necessary 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 functionality that is required nowadays. \name{netqmail} is the community effort to help in the latter point. \exim\ has only one single configuration file (\path{exim.conf}), but it suffers most from its flexibility---like \sendmail. Flexibility and easy configuration are almost always contrary goals.
    1.40  
    1.41 -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 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, seems to be a good example.
    1.42 +\subsubsection*{Performance}
    1.43 +
    1.44 +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 still will 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. Optimization, be it for performance or other efficiencies, is often in contrast to simplicity and clarity, which effect security. Optimizing does in most times decrease the simplicity and clarity. Simple \mta{}s not aiming for high performance are what is needed in future. The simple design of \qmail (\qmail\ is still fast) seems to be a good example.
    1.45 +
    1.46 +\subsubsection*{Security}
    1.47  
    1.48  The third trend---even more security awareness---is addressed by each of the four programs. It seems as if all widely used \mta{}s provide good security nowadays. Even \sendmail\ can be considered secure today. %fixme:ref
    1.49  But the modular architecture, used by \qmail\ and \postfix, is generally seen to be conceptually more secure, however. %fixme: ref
    1.50 @@ -241,18 +247,14 @@
    1.51  
    1.52  \section{Summary}
    1.53  
    1.54 -FIXME %fixme
    1.55 +This chapter first took an overview over the field of \MTA{}s. Three major types of \MTA{}s were identified: Relay-only \MTA{}s (also called forwarders), groupware, and the ``real \MTA{}s''. \masqmail\ belongs to the last group, it is additionally sendmail-compatible and Free Software.
    1.56  
    1.57 -%fixme: write a result here
    1.58 +Next a look at the market shares of \MTA{}s was taken and it was seen that four \MTA{}s, that are similar to \masqmail, have high importance: \sendmail, \postfix, \qmail, and \exim. Their combined share is between one third and the half of the market. The rest is split between proprietary \MTA{}s, unknown software behind mail security layers, and a rest of really small market shares.
    1.59  
    1.60 +Each one of these four major Free Software \MTA{}s was presented afterwards and at the end, these programs were compared on some selected properties.
    1.61  
    1.62 +Now, the reader should have a general knowledge about the four important \MTA{}s. Further chapters will refer frequently to them.
    1.63  
    1.64  
    1.65  %todo: my own poll (?)
    1.66  
    1.67 -
    1.68 -%<< complexity >> << security >> << simplicity of configuration and administration >> << flexibility of configuration and administration >> << code size >> << code quality >> << documentation (amount and quality) >> << community (amount and quality) >> << used it myself >> << had problems with it >>
    1.69 -
    1.70 -
    1.71 -%<< quality criteria >> << standards of any kind >> << how to compare? >> << (bewertungsmatrix) objectivity >> << how many criteria for ``good''? >>
    1.72 -