1.1 --- a/thesis/tex/5-Improvements.tex	Tue Feb 03 17:53:03 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Tue Feb 03 18:01:33 2009 +0100
     1.3 @@ -92,11 +92,11 @@
     1.4  \subsection{Security}
     1.5  \label{sec:current-code-security}
     1.6  
     1.7 -Improvements to \masqmail's security are an important requirement and are the third task to work on. Retrofitting security \emph{into} \masqmail\ is not or hardly possible as it was explained in section \ref{sec:discussion-further-devel}. But adding wrappers and interposition filters can be a large step towards security.
     1.8 +Improvements to \masqmail's security are an important requirement and are the third task to work on. Retrofitting security \emph{into} \masqmail\ is not or hardly possible as it was explained in section~\ref{sec:discussion-further-devel}. But adding wrappers and interposition filters can be a large step towards security.
     1.9  
    1.10  \subsubsection*{Mail security layers}
    1.11  
    1.12 -At first mail security layers like \name{smap} come to mind. The market share analysis in section \ref{sec:market-share} identified such software. This is an interposition filter that stands between the untrusted network and the \MTA. It accepts mail in replacement for the \MTA\ (also called \name{proxy}) in order to separate the \MTA\ from the untrusted network.
    1.13 +At first mail security layers like \name{smap} come to mind. The market share analysis in section~\ref{sec:market-share} identified such software. This is an interposition filter that stands between the untrusted network and the \MTA. It accepts mail in replacement for the \MTA\ (also called \name{proxy}) in order to separate the \MTA\ from the untrusted network.
    1.14  
    1.15  The work \name{smap} does is described in \cite{cabral01}: \name{smap} accepts messages as proxy for the \MTA\ and puts it into a queue. \name{smapd} a brother program runs as daemon and watches for new messages in the queue which it submits into the \MTA\ then.
    1.16  
    1.17 @@ -108,12 +108,12 @@
    1.18  
    1.19  Mail from outside would then come through the proxy into the system. Mail from the local host and from the local network could be directly accepted by the normal \masqmail, if those locations are considered trusted. But it seems better to have them use the proxy too, or maybe a second proxy instance with different policy.
    1.20  
    1.21 -The here described setup comes close to the structure of the incoming channels in the new design which is described in \ref{sec:new-design}. This shows the possibilities of the here chosen approach. %fixme: rethink this sentence
    1.22 +The here described setup comes close to the structure of the incoming channels in the new design which is described in section~\ref{sec:new-design}. This shows the possibilities of the here chosen approach. %fixme: rethink this sentence
    1.23  
    1.24  
    1.25  \subsubsection*{A concrete setup}
    1.26  
    1.27 -A stripped down proxy needs to be created. It should only be able to receive mail via \SMTP, encrypt the communication, authenticate clients, and send mail out via \SMTP\ to an internal socket (named ``X'' in the figure). This is a straight forward task. The normal \masqmail\ instance runs on the system too. It takes input from \name{stdin} (by calling the \path{sendmail} command) and via \SMTP\ where it listens on an internal socket (named ``X'' in the figure). Outgoing mail is handled without difference to a regular setup. Figure \ref{fig:proxy-setup} depicts the setup.
    1.28 +A stripped down proxy needs to be created. It should only be able to receive mail via \SMTP, encrypt the communication, authenticate clients, and send mail out via \SMTP\ to an internal socket (named ``X'' in the figure). This is a straight forward task. The normal \masqmail\ instance runs on the system too. It takes input from \name{stdin} (by calling the \path{sendmail} command) and via \SMTP\ where it listens on an internal socket (named ``X'' in the figure). Outgoing mail is handled without difference to a regular setup. Figure~\ref{fig:proxy-setup} depicts the setup.
    1.29  
    1.30  \begin{figure}
    1.31  	\begin{center}
    1.32 @@ -155,7 +155,7 @@
    1.33  
    1.34  \subsection{Design decisions}
    1.35  
    1.36 -This section describes and discusses architectural decision that were made for the new design. To functional requirements is in most times only refered as they were already discussed in chapter \ref{chap:present-and-future}.
    1.37 +This section describes and discusses architectural decision that were made for the new design. To functional requirements is in most times only refered as they were already discussed in chapter~\ref{chap:present-and-future}.
    1.38  
    1.39  A number of major design ideas lead the development of the new architecture:
    1.40  \begin{enumerate}
    1.41 @@ -173,7 +173,7 @@
    1.42  
    1.43  The functional requirements for incoming and outgoing channels were already discussed as \RF\,1 on page \pageref{rf1}. Two required incoming channels were identified: the \path{sendmail} command for local mail submission and the \SMTP\ daemon for remote connections.
    1.44  
    1.45 -A bit different is the structure of \name{sendmail X} at that point: Locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a back door?
    1.46 +A bit different is the structure of \name{sendmail~X} at that point: Locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a back door?
    1.47  \person{Finch} proposes a similar approach \cite{finch-sendmail}. He wants the \texttt{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA\ like it is done by connections from remote. The advantage here is one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid} because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
    1.48  
    1.49  But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP. To \qmail\ and \postfix\ new protocol handlers may be added without change in other parts of the system. Also the \SMTP\ modules can be removed if it is not needed. It is better to have more independent modules if each one is simpler then. The need to implement an \SMTP\ client in each one makes the modules more complicated.
    1.50 @@ -190,9 +190,9 @@
    1.51  
    1.52  Outgoing mail is commonly either sent using \SMTP, piped into local commands (for example \path{uucp}), or delivered locally by appending to a mailbox.
    1.53  
    1.54 -Outgoing channels are similar for \qmail, \postfix, and \name{sendmail X}: All of them have a module to send mail using \SMTP\ and one for writing into a local mailbox. Local mail delivery is a job that should have root privilege to be able to switch to any user in order to write to his mailbox. Modular \MTA{}s do not require \name{setuid root} but the local delivery process (or its parent) should run as root. root privilege is not a mandatory requirement but any other approach has some disadvantages thus commonly root privilege is used.
    1.55 +Outgoing channels are similar for \qmail, \postfix, and \name{sendmail~X}: All of them have a module to send mail using \SMTP\ and one for writing into a local mailbox. Local mail delivery is a job that should have root privilege to be able to switch to any user in order to write to his mailbox. Modular \MTA{}s do not require \name{setuid root} but the local delivery process (or its parent) should run as root. root privilege is not a mandatory requirement but any other approach has some disadvantages thus commonly root privilege is used.
    1.56  
    1.57 -Local mail delivery should not be done by the \MTA, but by an \NAME{MDA} instead. This decision was discussed in section \ref{sec:functional-requirements}. This means only an outgoing channel that pipes mail into a local command is required for local delivery.
    1.58 +Local mail delivery should not be done by the \MTA, but by an \NAME{MDA} instead. This decision was discussed in section~\ref{sec:functional-requirements}. This means only an outgoing channel that pipes mail into a local command is required for local delivery.
    1.59  
    1.60  Other outgoing channels, one for each supported protocol, should be designed like it was done in other \MTA{}s.
    1.61  
    1.62 @@ -279,7 +279,7 @@
    1.63  
    1.64  \subsubsection*{Spam and malware handling}
    1.65  
    1.66 -The two approaches for spam handling were already presented to the reader in section \ref{sec:functional-requirements} as \RF\,8 and \RF\,9. Here they are described in more detail:
    1.67 +The two approaches for spam handling were already presented to the reader in section~\ref{sec:functional-requirements} as \RF\,8 and \RF\,9. Here they are described in more detail:
    1.68  
    1.69  \begin{enumerate}
    1.70  \item Refusing spam during the \SMTP\ dialog. This is the way it was meant by the designers of the \SMTP\ protocol. They thought checking the sender and recipient mail addresses would be enough, but as they are forgeable it is not. More and more complex checks need to be done. Checking needs time, but \SMTP\ dialogs time out if it takes too long. Thus only limited time during the \SMTP\ dialog can be used for checking if a message seems to be spam. The advantage is that bad messages can simply get refused---no responsibility for the message is taken and no further system load is added. See \RFC\,2505 (especially section 1.5) for detail.
    1.71 @@ -321,7 +321,7 @@
    1.72  
    1.73  \subsection{The resulting architecture}
    1.74  
    1.75 -The result is a symmetric design, featuring the following parts: Any number of handlers for incoming connections to receive mail. A module that stores the received mail into a first queue. A central scanning module take mail from the first queue, processes it in various ways, and puts it afterwards into a second queue. A module that takes it out of the second queue and passes it to a matching transport module. A set of transport modules that transfers the message to the destination. In other words three main modules (\name{queue-in}, \name{scanning}, \name{queue-out}) are connected by two queues (\name{incoming}, \name{outgoing}). On each end is a set of modules to receive or send mail---one for each protocol. The \name{pool} is part of the queue; it is the place where the bodies of the queued messages are stored. Figure \ref{fig:masqmail-arch-new} depicts the new designed architecture.
    1.76 +The result is a symmetric design, featuring the following parts: Any number of handlers for incoming connections to receive mail. A module that stores the received mail into a first queue. A central scanning module take mail from the first queue, processes it in various ways, and puts it afterwards into a second queue. A module that takes it out of the second queue and passes it to a matching transport module. A set of transport modules that transfers the message to the destination. In other words three main modules (\name{queue-in}, \name{scanning}, \name{queue-out}) are connected by two queues (\name{incoming}, \name{outgoing}). On each end is a set of modules to receive or send mail---one for each protocol. The \name{pool} is part of the queue; it is the place where the bodies of the queued messages are stored. Figure~\ref{fig:masqmail-arch-new} depicts the new designed architecture.
    1.77  
    1.78  \begin{figure}
    1.79  	\begin{center}
    1.80 @@ -331,7 +331,7 @@
    1.81  	\label{fig:masqmail-arch-new}
    1.82  \end{figure}
    1.83  
    1.84 -This architecture is heavily influenced by the ones of \qmail\ and \postfix. Both have different incoming channels that merge in the module that puts mail into the queue; central is the queue (or more of them); and one module takes mail from the queue and passes it to one of the outgoing channels. Mail processing is built into the architecture in a more explicit way than it was done in \qmail\ and \postfix. It is more similar to the \NAME{AR} module of \name{sendmail X}, which is the central point for spam checking.
    1.85 +This architecture is heavily influenced by the ones of \qmail\ and \postfix. Both have different incoming channels that merge in the module that puts mail into the queue; central is the queue (or more of them); and one module takes mail from the queue and passes it to one of the outgoing channels. Mail processing is built into the architecture in a more explicit way than it was done in \qmail\ and \postfix. It is more similar to the \NAME{AR} module of \name{sendmail~X}, which is the central point for spam checking.
    1.86  
    1.87  Special regard was put on addable support for further mail transfer protocols. This appears to be most similar to \qmail, which was designed to handle multiple protocols.
    1.88  
    1.89 @@ -352,7 +352,7 @@
    1.90  
    1.91  \name{Receiver modules} are the communication interface between external senders and the \name{queue-in} module. Each protocol needs a corresponding \name{receiver module} to be supported. Most popular is the \name{sendmail} module which is a command to be called from the local host and the \name{smtpd} module which usually listens on port 25. Other modules to support other protocols may be added as needed. Receiving modules that need to listen on ports should get invoked by \name{inetd} or a more secure replacement like \person{Bernstein}'s \name{ucspi-tcp}. This makes it possible to run them with least privilege.
    1.92  
    1.93 -\name{Transport modules}, on the opposite side of the system, are the modules that send outgoing mail. They are the interface between \name{queue-out} and remote hosts or local commands for further processing. The most popular ones are the \name{smtp} module which acts as an \SMTP\ client and the \name{pipe} module to interface gateways to other systems or networks like fax and \NAME{UUCP}. A module for local delivery is not included, \masqmail\ passes this job to an \NAME{MDA} (like \name{procmail}) (see section \ref{sec:functional-requirements} for reasons). The \NAME{MDA} gets invoked through the \name{pipe} module.
    1.94 +\name{Transport modules}, on the opposite side of the system, are the modules that send outgoing mail. They are the interface between \name{queue-out} and remote hosts or local commands for further processing. The most popular ones are the \name{smtp} module which acts as an \SMTP\ client and the \name{pipe} module to interface gateways to other systems or networks like fax and \NAME{UUCP}. A module for local delivery is not included, \masqmail\ passes this job to an \NAME{MDA} (like \name{procmail}) (see section~\ref{sec:functional-requirements} for reasons). The \NAME{MDA} gets invoked through the \name{pipe} module.
    1.95  
    1.96  
    1.97  
    1.98 @@ -383,7 +383,7 @@
    1.99  
   1.100  The connections between \name{queue-in} and \name{scanning}, as well as between \name{scanning} and \name{queue-out} is provided by the queues, only sending signals to trigger runs may be useful. Communication between receiving and transport modules and the outside world are done using the specific protocol they do handle.
   1.101  
   1.102 -Left is only communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Data is exchanged using \unix\ pipes and a simple protocol. Figure \ref{fig:ipc-protocol} shows a state diagram for the protocol. Solid lines indicate client actions, dashed lines indicate server responses.
   1.103 +Left is only communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Data is exchanged using \unix\ pipes and a simple protocol. Figure~\ref{fig:ipc-protocol} shows a state diagram for the protocol. Solid lines indicate client actions, dashed lines indicate server responses.
   1.104  
   1.105  \begin{figure}
   1.106  	\begin{center}