1.1 --- a/thesis/bib/thesis.bib	Wed Dec 10 08:32:12 2008 +0100
     1.2 +++ b/thesis/bib/thesis.bib	Wed Dec 10 16:48:41 2008 +0100
     1.3 @@ -131,3 +131,11 @@
     1.4  	note = "Available online at: {\small\url{http://shearer.org/MTA_Comparison} (2008-12-09)} or {\small\url{http://lwn.net/Articles/196711} (2008-12-09)}",
     1.5  }
     1.6  
     1.7 +
     1.8 +@book{gancarz,
     1.9 +	author = "Mike Gancarz",
    1.10 +	title = "The Unix Philosophy",
    1.11 +	year = "",
    1.12 +	publisher = ""
    1.13 +}
    1.14 +

     2.1 --- a/thesis/bib/websites.bib	Wed Dec 10 08:32:12 2008 +0100
     2.2 +++ b/thesis/bib/websites.bib	Wed Dec 10 16:48:41 2008 +0100
     2.3 @@ -268,7 +268,11 @@
     2.4  }
     2.5  
     2.6  
     2.7 -
     2.8 +@misc{venema:postfix-growth,
     2.9 +	author = "Wietse Venema",
    2.10 +	title = "\emph{FIXME}",
    2.11 +	howpublished = "On the Internet: {\small\url{http://archives.neohapsis.com/archives/postfix/2006-07/1762.html} (2008-12-10)}",
    2.12 +}
    2.13  
    2.14  
    2.15  

     3.1 --- a/thesis/tex/1-Introduction.tex	Wed Dec 10 08:32:12 2008 +0100
     3.2 +++ b/thesis/tex/1-Introduction.tex	Wed Dec 10 16:48:41 2008 +0100
     3.3 @@ -14,7 +14,7 @@
     3.4  
     3.5  (include history of email, definition of MTA and sendmail-compatibility in text)
     3.6  
     3.7 -The \masqmail\ program was written by Oliver Kurth, starting in 1999. His aim was to create a small \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ is easy configurable for situations which are rarely solveable with the common \MTA{}s.
     3.8 +The \masqmail\ program was written by \person{Oliver Kurth}, starting in 1999. His aim was to create a small \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ is easy configurable for situations which are rarely solveable with the common \MTA{}s.
     3.9  
    3.10  \masqmail\ queues mail for destinations outside the local network if no connection to the internet is online. If the machine goes online, this mail is sent. Mail to local machines is sent immediately.
    3.11  
    3.12 @@ -26,7 +26,7 @@
    3.13  
    3.14  
    3.15  \subsubsection{Target field}
    3.16 -Its original author, Oliver Kurth, sees \masqmail\ so:
    3.17 +Its original author, \person{Oliver Kurth}, sees \masqmail\ so:
    3.18  \begin{quote}
    3.19  MasqMail is a mail server designed for hosts that do not have a permanent internet connection eg. a home network or a single host at home. It has special support for connections to different ISPs. It replaces sendmail or other MTAs such as qmail or exim.
    3.20  \end{quote}

     4.1 --- a/thesis/tex/2-MarketAnalysis.tex	Wed Dec 10 08:32:12 2008 +0100
     4.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Wed Dec 10 16:48:41 2008 +0100
     4.3 @@ -21,7 +21,7 @@
     4.4  
     4.5  Another possible separation is to distinguished written and recorded information. Recorded information, like audio or video data, is accessible only in a linear way by spooling and replay. Written information, on the other hand, can be accessed in arbitrary sequence, detail and speed.
     4.6  
     4.7 -Lenke and Schmitz \cite{lenke95} use the same criteria to classify \emph{new media}. %fixme: is this term common?
     4.8 +\person{Lenke} and \person{Schmitz} \cite{lenke95} use the same criteria to classify \emph{new media}. %fixme: is this term common?
     4.9  They additionally divide into local and remote communication---the latter is presumed here---and by the number of communication participants. As communication technologies for n:m communication (like chat rooms) are usable for 1:1 too (private chat), and ones for 1:1 (email) are usable for n:m (mailing lists), a classification by participant structures is omitted here.
    4.10  
    4.11  Figure \ref{fig:comm-classification} shows a classification of communication technologies sorted by the properties synchronous/asynchronous and written/recorded. Email and \NAME{SMS} are written and asynchronous communication; \NAME{IM} and chats are written information too, but synchronous. Recorded information are voice mail and video messages as examples for asynchronous communication. VoIP is an example for synchronous communication.
    4.12 @@ -98,7 +98,7 @@
    4.13  \subsubsection*{Unified Communication}
    4.14  \name{Unified communication} is the technology aiming to consolidate and integrate all electronic communication and providing access for all kinds of hardware clients. Unified communication tries to bring the tree trends here mentioned together. The \name{{\smaller PC} Magazine} has the following definition in its Encyclopedia \citeweb{pcmag:uc}: ``[Unified communications is] The real-time redirection of a voice, text or e-mail message to the device closest to the intended recipient at any given time.'' The main goal is to integrate all kinds of communication (asynchronous and synchronous) into one system, hence this requires real-time delivery of data.
    4.15  
    4.16 -According to Michael Osterman \citeweb{howto-def-uc}, unified communications is already possible as far as various incoming sources are routed to one storage where messages can be accessed by one or a few clients. But a system with an ``intelligent parser of a single data stream into separate streams that are designed to meet the real-time needs of the user'' is a goal for the future, he says.
    4.17 +According to \person{Michael Osterman} \citeweb{howto-def-uc}, unified communications is already possible as far as various incoming sources are routed to one storage where messages can be accessed by one or a few clients. But a system with an ``intelligent parser of a single data stream into separate streams that are designed to meet the real-time needs of the user'' is a goal for the future, he says.
    4.18  
    4.19  The question is, if the integration of synchronous and asynchronous message transfer does make sense. A communication between one person talking on the phone and the other replying using his instant messenger, certainly does, if the text-to-speech and speech-to-text converting is fast and the quality good enough. But transferring large video messages and real-time communication data with the same technology, possibly does not.
    4.20  
    4.21 @@ -191,7 +191,7 @@
    4.22  
    4.23  \subsubsection*{New email protocols}
    4.24  
    4.25 -Another concept to redesign the electronic mail system, but this time focused on mail transfer is named ``Internet Mail 2000''. It was proposed by Daniel J.\ Bernstein, the creator of \name{qmail}. Similar approaches were independently introduced by others too.
    4.26 +Another concept to redesign the electronic mail system, but this time focused on mail transfer is named ``Internet Mail 2000''. It was proposed by \person{Daniel~J.\ Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others too.
    4.27  
    4.28  As main change it makes the sender have the responsibility of mail storage; only a notification about a mail message gets send to the receiver, who can fetch the message then from the sender's server. This is in contrast to the \NAME{SMTP} mail architecture, where mail and the responsibility for it is transferred from the sender to the receiver.
    4.29  
    4.30 @@ -221,15 +221,12 @@
    4.31  
    4.32  Provider independence through running an own mail server at home asks for easy configuration of the \MTA. Providers have specialists to configure the systems, but ordinary people do not. Solutions are either having some home service system for computer configuration established with specialists coming to ones home to set up the systems; like it is already common for problems with the power and water supply systems. Or configuration needs to be easy and fool-prove, to be done by the owner himself. The latter solution depends on standardized parts that fit together seamlessly. The technology must not be a problem itself. Only settings custom to the users environment should be left open for him to set. This of course needs to be doable using a simple configuration interface like a web interface. Non-technical educated users should be able to configure the system.
    4.33  
    4.34 -\sendmail\ and \name{qmail} appear to have bad positions at this point. Their configuration is complex, thus they would need simplification wrappers around them to provide easy configuration.
    4.35 -
    4.36 -The approach of wrappers around the main program to make it look easier to the outside is a good concept in general. %FIXME: add ref
    4.37 -It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ graphical programs, websites, command line programs; all of them either in a questionnaire style or interactive).
    4.38 +Complex configuration itself is not a problem if simplification wrappers around it do provide an easy interface. The approach of wrappers to make it look easier to the outside is a good concept in general. %FIXME: add ref
    4.39 +It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. \sendmail\ took this approach with the \name{m4} macros. %fixme: add ref
    4.40 +Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ graphical programs, websites, command line programs; all of them either in a questionnaire style or interactive).
    4.41  
    4.42  When \MTA{}s become popular on home servers and maybe even on workstations and smart phones, then performance will be less important. Providers need \mta{}s that process large amounts of mail in short time. Home servers or workstations however, do not see that much mail; they need to handle only tens or hundreds of email messages per hour. Thus performance will probably not be a main requirement for an \MTA\ in future, if they mainly run on private machines.
    4.43  
    4.44 -\name{postfix} focuses much on performance, this might not be an important point then.
    4.45 -
    4.46  New mailing concepts and architectures like push email or \name{Internet Mail 2000} will, if they succeed, require \mta{}s to adopt the new technology. \MTA{}s that are not able to change are going to be sorted out by evolution. Thus it is important to not focus too much on one use case, but to stay flexible. Allman saw the flexibility of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}).
    4.47  
    4.48  Another important requirement for all kinds of software will be security. There is a constant trend coming from completely non-secured software, in the 70s and 80s, over growing security awareness, in the 90s, to security being a primary goal, now. This leads to the conclusion that software security will be even more important in the next years. As more clients get connected to the Internet and especially more computers are listening for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing of software systems will be done with increasing effort in future.
    4.49 @@ -238,7 +235,7 @@
    4.50  
    4.51  Secure and robust software is a pre-requisite for such boxes to make that vision possible.
    4.52  
    4.53 -It seems as if all widely used \mta{}s provide good security nowadays. \name{qmail}'s architecture, also used in \name{postfix}, is generally seen to be conceptually more secure, however.
    4.54 +It seems as if all widely used \mta{}s provide good security nowadays. The modular architecture is generally seen to be conceptually more secure, however.
    4.55  
    4.56  In summary: Easy configuration, as well as the somehow opposed flexibility will be important for future \mta{}s. Also will it be security, but not performance. \MTA{}s might become more commodity software, like web servers already are today, with the purpose to include it in many systems and the need of minimal configuration.
    4.57  

     5.1 --- a/thesis/tex/3-MailTransferAgents.tex	Wed Dec 10 08:32:12 2008 +0100
     5.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Wed Dec 10 16:48:41 2008 +0100
     5.3 @@ -8,7 +8,7 @@
     5.4  \section{Types of MTAs}
     5.5  ``Mail transfer agent'' is a term covering a variety of programs. One thing is common to them: they transfer email from one machine to another.
     5.6  
     5.7 -This is how Bryan Costales defines a \mta\ in \cite{costales97}:
     5.8 +This is how \person{Bryan Costales} defines a \mta\ in \cite{costales97}:
     5.9  \begin{quote}
    5.10  A mail transfer agent (MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office.
    5.11  \end{quote}
    5.12 @@ -44,7 +44,7 @@
    5.13  \subsubsection*{``Real'' MTAs}
    5.14  There is a third type of \mta{}s in between the minimalistic \name{relay-only} \MTA{}s and the bloated \name{groupware}. Those programs may be named ``real \MTA{}s'', or ``proper \MTA{}s'', though there is no common name. They are what is meant with the term ``\mta''---programs that transfer mail between hosts.
    5.15  
    5.16 -Common to them is their focus on transferring email, while being able to act as \name{smart host}. Their variety ranges from ones mostly restricted to mail transfer (\name{qmail}) to others already having interfaces for adding further mail processing modules (\name{postfix}). They cover everything in between the other two groups.  %FIXME: are postfix and qmail good examples?
    5.17 +Common to them is their focus on transferring email, while being able to act as \name{smart host}. Their variety ranges from ones mostly restricted to mail transfer (\qmail) to others already having interfaces for adding further mail processing modules (\postfix). They cover everything in between the other two groups.  %FIXME: are postfix and qmail good examples?
    5.18  
    5.19  This group is of importance in this document. All programs selected for the comparison in the following section are ``real \MTA{}s''. \masqmail\ is one too.
    5.20  
    5.21 @@ -69,9 +69,9 @@
    5.22  
    5.23  This section introduces a selection of popular \MTA{}s; they are the most likely substitutes for \masqmail. All are \emph{sendmail-compatible} ``smart'' \freesw\ \MTA{}s that focus on mail transfer, as is \masqmail.
    5.24  
    5.25 -The programs chosen are: \sendmail, \name{exim}, \name{qmail}, and \name{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.
    5.26 +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.
    5.27  
    5.28 -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 \textsc{Daniel~J.\ Bernstein} (the author of \name{qmail}) done in 2001 \citeweb{djb:mta-stats}.
    5.29 +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}.
    5.30  
    5.31  \begin{table}
    5.32  	\begin{center}
    5.33 @@ -81,10 +81,10 @@
    5.34  	\label{tab:mta-market-share}
    5.35  \end{table}
    5.36  
    5.37 -Other members of the same group are: \name{smail}, \name{zmailer}, \name{mmdf}, and \name{courier-mta}. They all are less important and rarely used, thus ommited here.
    5.38 +Other members of the same group are: \name{smail}, \name{zmailer}, \name{MMDF}, and \name{courier-mta}. They all are less important and rarely used, thus ommited here.
    5.39  
    5.40  
    5.41 -Now follows a small introduction to the five programs chosen for comparison, except \masqmail\ which already was introduced in chapter \ref{chap:introduction}. Longer introductions, including analysis and comparison, were written by \textsc{Jonathan de Boyne Pollard} \citeweb{jdebp}.
    5.42 +Now follows a small introduction to the five programs chosen for comparison, except \masqmail\ which already was introduced in chapter \ref{chap:introduction}. Longer introductions, including analysis and comparison, were written by \person{Jonathan de Boyne Pollard} \citeweb{jdebp}.
    5.43  
    5.44  
    5.45  
    5.46 @@ -92,7 +92,7 @@
    5.47  \label{sec:sendmail}
    5.48  \sendmail\ is the most popular \mta, since it was one of the first and was shipped as default \MTA{}s by many vendors of \unix\ systems. %fixme: ref
    5.49  
    5.50 -The program was written by Eric Allman as the successor of his program \name{delivermail}. \sendmail\ was first released with \NAME{BSD} 4.1c in 1983. Allman was not the only one working on the program. Other people developed own versions of it and a variety of flavors came up, especially in the late eighties when Allman was inactive. %fixme: ref
    5.51 +The program was written by \person{Eric Allman} as the successor of his program \name{delivermail}. \sendmail\ was first released with \NAME{BSD} 4.1c in 1983. Allman was not the only one working on the program. Other people developed own versions of it and a variety of flavors came up, especially in the late eighties when Allman was inactive. %fixme: ref
    5.52  
    5.53  \sendmail\ is focused on transferring mails between different protocols and networks, this lead to a very flexible (though complex) configuration.
    5.54  
    5.55 @@ -106,39 +106,39 @@
    5.56  
    5.57  \subsubsection*{exim}
    5.58  \label{sec:exim}
    5.59 -\name{exim} was started in 1995 by Philip Hazel at the \name{University of Cambridge}. It is forked of \name{smail-3}, and inherited the monolithic architecture, similar to \sendmail's. But having no separation of the individual components of the system, like \name{qmail} and \name{postfix} have, did not hurt. Its security is comparably good. %fixme: ref
    5.60 +\exim\ was started in 1995 by \person{Philip Hazel} at the \name{University of Cambridge}. It is forked of \name{smail-3}, and inherited the monolithic architecture, similar to \sendmail's. But having no separation of the individual components of the system, like \qmail\ and \postfix\ have, did not hurt. Its security is comparably good. %fixme: ref
    5.61  
    5.62 -\name{exim} is highly configurable, especially in the field of mail policies. This makes it easy to specify how mail is routed through the system and who is allowed to send email to whom. Also interfaces for integration of virus and spam check programs are provided by design. %fixme: ref
    5.63 +\exim\ is highly configurable, especially in the field of mail policies. This makes it easy to specify how mail is routed through the system and who is allowed to send email to whom. Also interfaces for integration of virus and spam check programs are provided by design. %fixme: ref
    5.64  
    5.65  The program is \freesw, released under the \GPL. The latest stable version is 4.69 from December 2007.
    5.66  
    5.67 -One finds \name{exim} on its homepage \citeweb{exim:homepage}.
    5.68 +One finds \exim\ on its homepage \citeweb{exim:homepage}.
    5.69  
    5.70  
    5.71  
    5.72  \subsubsection*{qmail}
    5.73  \label{sec:qmail}
    5.74 -\name{qmail} is seen by its community as ``a modern SMTP server which makes sendmail obsolete''.%fixme: ref
    5.75 -It was written by Daniel~J.\ Bernstein starting in 1995. His primary goal was to create a secure \MTA\ to replace the popular, but vulnerable, \sendmail. %fixme: ref
    5.76 +\qmail\ is seen by its community as ``a modern SMTP server which makes sendmail obsolete''.%fixme: ref
    5.77 +It was written by \person{Daniel~J.\ Bernstein} starting in 1995. His primary goal was to create a secure \MTA\ to replace the popular, but vulnerable, \sendmail. %fixme: ref
    5.78  
    5.79 -\name{qmail} first introduced many innovative concepts in \mta\ design and is generally seen as the first security-aware \MTA\ developed. %fixme:ref
    5.80 +\qmail\ first introduced many innovative concepts in \mta\ design and is generally seen as the first security-aware \MTA\ developed. %fixme:ref
    5.81  %fixme: what about mmdf?
    5.82  
    5.83 -Since November 2007, \name{qmail} is released in the \name{public domain} which makes it \freesw. The latest release is 1.03 from July 1998.
    5.84 +Since November 2007, \qmail\ is released in the \name{public domain} which makes it \freesw. The latest release is 1.03 from July 1998.
    5.85  
    5.86 -The programs homepages are \citeweb{qmail:homepage1} and \citeweb{qmail:homepage2}. Further information about \name{qmail} is available with Dave Sill's ``Life with qmail'' \citeweb{lifewithqmail}.
    5.87 +The programs homepages are \citeweb{qmail:homepage1} and \citeweb{qmail:homepage2}. Further information about \qmail\ is available with \person{Dave Sill}'s ``Life with qmail'' \citeweb{lifewithqmail}.
    5.88  
    5.89  
    5.90  
    5.91  \subsubsection*{postfix}
    5.92  \label{sec:postfix}
    5.93 -The \name{postfix} project was started in 1999 at \name{IBM research}, then called \name{VMailer} or \name{IBM Secure Mailer}. Wietse Venema's program ``attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.''\citeweb{postfix:homepage} In fact, \name{postfix} was mainly designed after qmail's architecture to gain security. But in contrast to \name{qmail} it aims much more on being fast and full-featured.
    5.94 +The \postfix\ project was started in 1999 at \name{IBM research}, then called \name{VMailer} or \name{IBM Secure Mailer}. \person{Wietse Venema}'s program ``attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.''\citeweb{postfix:homepage} In fact, \postfix\ was mainly designed after qmail's architecture to gain security. But in contrast to \qmail\ it aims much more on being fast and full-featured.
    5.95  
    5.96 -Today \name{postfix} is taken by many \unix\ systems and \gnulinux\ distributions as default \MTA.
    5.97 +Today \postfix\ is taken by many \unix\ systems and \gnulinux\ distributions as default \MTA.
    5.98  
    5.99 -The latest stable version is numbered 2.5.5 from August 2008. \name{postfix} is covered by the \name{IBM Public License 1.0} which is a \freesw\ license.
   5.100 +The latest stable version is numbered 2.5.5 from August 2008. \postfix\ is covered by the \name{IBM Public License 1.0} which is a \freesw\ license.
   5.101  
   5.102 -Additional information is available on the program's homepage \citeweb{postfix:homepage}.
   5.103 +Additional information can be retrieved from the program's homepage \citeweb{postfix:homepage}.
   5.104  
   5.105  
   5.106  
   5.107 @@ -147,12 +147,10 @@
   5.108  
   5.109  \section{Comparison of MTAs}
   5.110  
   5.111 -This section tries not to provide an overall \MTA\ comparison, because this is already done by others. Remarkable are the one by Shearer \cite{shearer06} and an email discussion on the mailing list \name{plug@lists.q-linux.com} \citeweb{plug:mtas}. Tabulary overviews may be found at \citeweb{mailsoftware42} and \citeweb{wikipedia:comparison-of-mail-servers}.
   5.112 +This section does not try to provide an overall \MTA\ comparison, because this is already done by others. Remarkable comparisons are the one by \person{Dan Shearer} \cite{shearer06} and a discussion on the mailing list \name{plug@lists.q-linux.com} \citeweb{plug:mtas}. Tabulary overviews may be found at \citeweb{mailsoftware42}, \citeweb{wikipedia:comparison-of-mail-servers}, and \citeweb[section 1.9]{lifewithqmail}.
   5.113  
   5.114  Here provided is an overview on a selection of important properties, covering the four previously introduced programs. The data comes from the above stated sources and is collected in table \ref{tab:mta-comparison}.
   5.115  
   5.116 -
   5.117 -
   5.118  \begin{table}
   5.119  	\begin{center}
   5.120  		\input{input/mta-comparison.tex}
   5.121 @@ -162,51 +160,48 @@
   5.122  \end{table}
   5.123  
   5.124  
   5.125 +\subsection{Architecture}
   5.126  
   5.127 -\subsection{About architecture}
   5.128 +Architecture is most important when comparing \MTA{}s. Many other properties of a program depend on its architecture. %fixme: add ref?
   5.129 +\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 \citeweb{jdebp} is a source too.
   5.130  
   5.131 -Hafiz \cite{hafiz05} discusses in detail on \mta\ architecture (comparing \sendmail, \name{qmail}, \name{postfix}, and \name{sendmail X}).
   5.132 +Two different architecture types show off: monolithic and modular \mta{}s.
   5.133  
   5.134 +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 a security risk.} binary which does all the work.
   5.135  
   5.136 -\url{http://archives.neohapsis.com/archives/postfix/2006-07/1762.html} %sloc evolution of postfix, sendmail, qmail
   5.137 +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.
   5.138  
   5.139 +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. It, however, takes more effort and makes it very hard to keep the security up, as the program growth. \person{Wietse Venema} (the author of \postfix) sees in modularity the FIXME(vorraussetzung) to let \postfix\ grow without running into security problems. \citeweb{venema:postfix-growth}
   5.140  
   5.141 +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
   5.142  
   5.143 -\subsection{Security comparison}
   5.144 +Today modular \mta\ architectures are the state-of-the-art.
   5.145  
   5.146  
   5.147  
   5.148 +\subsection{With focus on the future}
   5.149  
   5.150 +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.
   5.151  
   5.152 +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
   5.153 + 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.
   5.154  
   5.155 -\paragraph{Ref back to \ref{sec:what-will-be-important}}
   5.156 +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.
   5.157  
   5.158 -provider indepencence -> easy config:
   5.159 -\sendmail\ and \name{qmail} appear to have bad positions at this point. Their configuration is complex, thus they would need simplification wrappers around them to provide easy configuration.
   5.160 +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
   5.161 +The modular architecture, used by \qmail\ and \postfix, is generally seen to be conceptually more secure, however.%fixme: ref
   5.162 +\sendmail's creators have started \name{MeTA1}, a modular \MTA\ merging the best of \qmail\ and \postfix, to replace the old \sendmail. It will be interesting to watch \exim's future---will it become modular too?
   5.163  
   5.164 -performance not so important:
   5.165 -\name{postfix} focuses much on performance, this might not be an important point then.
   5.166  
   5.167 -security:
   5.168 -It seems as if all widely used \mta{}s provide good security nowadays. \name{qmail}'s architecture, also used in \name{postfix}, is generally seen to be conceptually more secure, however.
   5.169  
   5.170  
   5.171  
   5.172 -\paragraph{local mail delivery}
   5.173 -But for example delivery of mail to local users is \emph{not} what \mta{}s should care about, although most \MTA\ are able to deliver mail, and many do. (\name{mail delivery agents}, like \name{procmail} and \name{maildrop}, are the right programs for this job.)
   5.174  
   5.175  
   5.176 -\paragraph{various protocols}
   5.177 -protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transferred.\footnote{\sendmail{}'s initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.}
   5.178 +%todo: my own poll (?)
   5.179  
   5.180  
   5.181 +%<< 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 >>
   5.182  
   5.183  
   5.184 -
   5.185 -
   5.186 -
   5.187 -
   5.188 -<< 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 >>
   5.189 -
   5.190 -
   5.191 -<< quality criteria >> << standards of any kind >> << how to compare? >> << (bewertungsmatrix) objectivity >> << how many criteria for ``good''? >>
   5.192 +%<< quality criteria >> << standards of any kind >> << how to compare? >> << (bewertungsmatrix) objectivity >> << how many criteria for ``good''? >>

     6.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Wed Dec 10 08:32:12 2008 +0100
     6.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Wed Dec 10 16:48:41 2008 +0100
     6.3 @@ -1,29 +1,9 @@
     6.4  \chapter{\masqmail's present and future}
     6.5  
     6.6 -<<  plans to get masqmail more popular again (if that is the goal) >> %FIXME
     6.7 -
     6.8 -architecture:
     6.9 -(ssl) -> msg-in (local or remote protocol handlers) -> spam-filter (and more) -> queue -> msg-out (local-delivery by MDA, or remote-protocol-handlers) -> (ssl)
    6.10 -
    6.11 -
    6.12 -http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command
    6.13 -http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security
    6.14 -http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery
    6.15 -http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format
    6.16 -http://fanf.livejournal.com/65203.html %how not to design an mta - spool file logistics
    6.17 -http://fanf.livejournal.com/65911.html %how not to design an mta -   more about log-structured MTA queues
    6.18 -http://fanf.livejournal.com/67297.html %how not to design an mta -   more log-structured MTA queues
    6.19 -http://fanf.livejournal.com/70432.html %how not to design an mta - address verification
    6.20 -http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning
    6.21 -
    6.22 -
    6.23 -
    6.24 -<<  concrete decisions based on results of the last 2 chapters >> %FIXME
    6.25 -
    6.26  \section{Existing features}
    6.27  This overview regards \masqmail\ version 0.2.21, the state this document starts off.
    6.28  
    6.29 -First of all \masqmail\ is an \MTA. Therefor it accepts mail on the command line and via \SMTP. Mail queueing and alias expansion is supported. \masqmail\ is able to deliver mail to local mailboxes (in \name{mbox} or \name{maildir} format) or pass it to a \name{mail delivery agent} (like \name{procmail}). Mail destinated to remote locations is sent via \SMTP. Outgoing \SMTP\ connections feature \name{SMTP-Auth} and \name{SMTP-after-POP} authentication, but incoming \SMTP\ does not.
    6.30 +\masqmail\ is an \MTA, therefor it accepts mail on the command line and via \SMTP. Mail queueing and alias expansion is supported. \masqmail\ is able to deliver mail to local mailboxes (in \name{mbox} or \name{maildir} format) or pass it to a \name{mail delivery agent} (like \name{procmail}). Mail destinated to remote locations is sent via \SMTP. Outgoing \SMTP\ connections feature \name{SMTP-Auth} and \name{SMTP-after-POP} authentication, but incoming \SMTP\ does not.
    6.31  
    6.32  As \masqmail\ is focused on non-permanent Internet connections, online state can be queried by three methods: reading from a file, reading the output of a command, or by asking an \name{mserver}. Each method may return a string indicating one of the available routes being online, or returning nothing to indicate offline state.
    6.33  
    6.34 @@ -32,7 +12,6 @@
    6.35  Additional to the \mta\ job, \masqmail\ also offers mail retrieval services with being a \NAME{POP3} client. Thus it can fetch mail from remote locations, dependent on the active online route.
    6.36  
    6.37  
    6.38 -\subsubsection*{masqmail stuff}
    6.39  
    6.40  The \masqmail\ executable can be called under various names for \name{sendmail-compatibility} reasons. This is commonly organized by creating symbolic links with with different names to the \masqmail\ executable. These are \path{/usr/lib/sendmail} and \path{/usr/sbin/sendmail} because many programs expect a \mta\ to be located there. Further more \sendmail\ provides shortcuts by calling it with a different name instead of supplying command line arguments. The best known of it is \path{mailq}, which is equivilent to calling the \MTA\ with the argument \verb+-bq+. \masqmail\ reacts to the names \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The last four are an addition to \sendmail. Not implemented is the name \path{newaliases} because it is not relevant to \masqmail. To provide the command nonetheless, one may write a shell script located at \path{/usr/bin/newaliases}, that simply invokes \verb+masqmail -bi+.
    6.41  
    6.42 @@ -48,6 +27,63 @@
    6.43  \masqmail\ does not provide an interface for modules with additional functionality. There exists no add-on or module system. But the code is separated by function to the various source files, and some functional parts can be included or excluded by defining symbols. This means adding some argument (like \verb+--enable-maildir+) to the \verb+configure+ call. Thus the concerning code gets not removed by the preprocessor.
    6.44  
    6.45  
    6.46 +
    6.47 +
    6.48 +
    6.49 +\section{Discussion/Ideas}
    6.50 +
    6.51 +
    6.52 +<<  plans to get masqmail more popular again (if that is the goal) >> %FIXME
    6.53 +
    6.54 +
    6.55 +\subsection{Architecture}
    6.56 +
    6.57 +<< architecture diagram >>
    6.58 +
    6.59 +(ssl) -> msg-in (local or remote protocol handlers) -> spam-filter (and more) -> queue -> msg-out (local-delivery by MDA, or remote-protocol-handlers) -> (ssl)
    6.60 +
    6.61 +A design from scratch?
    6.62 +
    6.63 +<< what would be needed (effort) >> %FIXME
    6.64 +
    6.65 +<< would one create it at all? >> %FIXME
    6.66 +
    6.67 +<< should it be done? >> %FIXME
    6.68 +
    6.69 +
    6.70 +
    6.71 +\subsection{local mail delivery}
    6.72 +But for example delivery of mail to local users is \emph{not} what \mta{}s should care about, although most \MTA\ are able to deliver mail, and many do. (\name{mail delivery agents}, like \name{procmail} and \name{maildrop}, are the right programs for this job.)
    6.73 +
    6.74 +
    6.75 +
    6.76 +\subsection{various protocols}
    6.77 +protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transferred.\footnote{\sendmail{}'s initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.}
    6.78 +
    6.79 +
    6.80 +
    6.81 +
    6.82 +
    6.83 +
    6.84 +http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command
    6.85 +http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security
    6.86 +http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery
    6.87 +http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format
    6.88 +http://fanf.livejournal.com/65203.html %how not to design an mta - spool file logistics
    6.89 +http://fanf.livejournal.com/65911.html %how not to design an mta -   more about log-structured MTA queues
    6.90 +http://fanf.livejournal.com/67297.html %how not to design an mta -   more log-structured MTA queues
    6.91 +http://fanf.livejournal.com/70432.html %how not to design an mta - address verification
    6.92 +http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning
    6.93 +
    6.94 +
    6.95 +
    6.96 +<<  concrete decisions based on results of the last 2 chapters >> %FIXME
    6.97 +
    6.98 +
    6.99 +
   6.100 +
   6.101 +
   6.102 +
   6.103  \section{Directions to go}
   6.104  
   6.105  \subsection{\masqmail\ in five years}
   6.106 @@ -67,13 +103,7 @@
   6.107  << why is it worth to revive masqmail? >> %FIXME
   6.108  
   6.109  
   6.110 -\subsection{A design from scratch}
   6.111  
   6.112 -<< what would be needed (effort) >> %FIXME
   6.113 -
   6.114 -<< would one create it at all? >> %FIXME
   6.115 -
   6.116 -<< should it be done? >> %FIXME
   6.117  
   6.118  
   6.119  

     7.1 --- a/thesis/thesis.sty	Wed Dec 10 08:32:12 2008 +0100
     7.2 +++ b/thesis/thesis.sty	Wed Dec 10 16:48:41 2008 +0100
     7.3 @@ -30,6 +30,7 @@
     7.4  	\renewcommand{\path}[1]{\textit{#1}}
     7.5  	\newcommand{\name}[1]{\emph{#1}\index{#1}}
     7.6  	\newcommand{\NAME}[1]{{\smaller\textsc{#1}}\index{#1}}
     7.7 +	\newcommand{\person}[1]{\textsc{#1}}
     7.8  
     7.9  	% \newcommand{\source}[1]{\hspace{1em}\textit{\scriptsize(Quelle: #1)}}
    7.10  	\let\OLDcleardoublepage\cleardoublepage
    7.11 @@ -38,6 +39,9 @@
    7.12  	% shortcuts
    7.13  	\newcommand{\masqmail}{\name{masqmail}}
    7.14  	\newcommand{\sendmail}{\name{sendmail}}
    7.15 +	\newcommand{\qmail}{\name{qmail}}
    7.16 +	\newcommand{\exim}{\name{exim}}
    7.17 +	\newcommand{\postfix}{\name{postfix}}
    7.18  	\newcommand{\mta}{mail transfer agent}
    7.19  	\newcommand{\email}{email}
    7.20  	\newcommand{\debian}{\name{Debian}}