1.1 --- a/thesis/tex/5-Improvements.tex	Fri Jan 23 11:22:15 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Fri Jan 23 11:23:17 2009 +0100
     1.3 @@ -15,7 +15,7 @@
     1.4  
     1.5  
     1.6  
     1.7 -\subsubsection*{Encryption}
     1.8 +\subsection{Encryption}
     1.9  
    1.10  Encryption should be the first funtionality to add to the current code. This requirement was already discussed on page \pageref{requirement-encryption}. As explained there, \NAME{STARTTLS} encryption---as defined in \RFC\,2487---should be added to \masqmail.
    1.11  
    1.12 @@ -51,7 +51,7 @@
    1.13  
    1.14  
    1.15  
    1.16 -\subsubsection*{Authentication}
    1.17 +\subsection{Authentication}
    1.18  
    1.19  Authentication is the second function to add; it is important to restrict the access to \masqmail, especially for mail relay. The requirements for authentication where identified on page \pageref{requirement-authentication}.
    1.20  
    1.21 @@ -95,7 +95,7 @@
    1.22  
    1.23  
    1.24  
    1.25 -\subsubsection*{Security}
    1.26 +\subsection{Security}
    1.27  
    1.28  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.29  
    1.30 @@ -109,37 +109,36 @@
    1.31  
    1.32  \name{smap} is non-free software and thus no general choice for \masqmail. A way to achieve a similar setup would be to copy \masqmail\ and strip one copy to the bare minimum what is needed for the proxy job. \name{setuid} could be removed and root privilege too if \name{inetd} is used. This hardens the proxy instance.
    1.33  
    1.34 +Mail from extern 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.35  
    1.36 +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.37  
    1.38 -split masqmail into two instances
    1.39  
    1.40 -\begin{verbatim}
    1.41 -     +--------+ ext ||||| int +--------+
    1.42 ----> |stripped|---> inter --->|normal  |
    1.43 -     |masqmail|     pos       |masqmail|
    1.44 -     +--------+     |||||     +--------+
    1.45 -\end{verbatim}
    1.46 +\subsubsection*{A concrete setup}
    1.47  
    1.48 -<< refer back to enc and auth >>
    1.49 +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.50  
    1.51 -<< conditional compilation >>
    1.52 -
    1.53 -
    1.54 -\subsubsection*{Reliability}
    1.55 -
    1.56 -discuss persistence through using databases
    1.57 -
    1.58 +\begin{figure}
    1.59 +	\begin{center}
    1.60 +		\includegraphics[scale=0.75]{img/proxy-setup.eps}
    1.61 +	\end{center}
    1.62 +	\caption{A setup with a proxy}
    1.63 +	\label{fig:proxy-setup}
    1.64 +\end{figure}
    1.65  
    1.66  
    1.67  \subsubsection*{Spam and malware handling}
    1.68  
    1.69 -discuss the MTA->scanner->MTA approach
    1.70 +The presented setup is the same as the one with two \MTA\ instances and a scanner application in between, which was suggested to add spam and malware scanner afterwards to an \MTA. This is a fortunate conincidence, because a scanner like \name{amavis} can simply be put in replace for the internal socket ``X''.
    1.71  
    1.72  
    1.73  
    1.74 -\subsubsection*{Bug fixes}
    1.75  
    1.76 -already fixed bugs
    1.77 +\subsubsection*{Conditional compilation}
    1.78 +<< conditional compilation >>
    1.79 +
    1.80 +
    1.81 +
    1.82  
    1.83  
    1.84  
    1.85 @@ -155,16 +154,14 @@
    1.86  
    1.87  
    1.88  \section{A new design}
    1.89 +\label{sec:new-design}
    1.90  
    1.91  The last chapter identified the requirements for a modern and securt \masqmail. Now the various jobs of an \MTA\ get assigned to modules, of which the new architecture is created. It is inspired by existing \MTA{}s and driven by the identified requirements.
    1.92  
    1.93  One wise experience was kept in mind during the design: ``Many times in life, getting off to the right start makes all the difference.'' \cite[page~32]{graff03}.
    1.94  
    1.95  
    1.96 -
    1.97 -\subsection{Design decisions}
    1.98 -
    1.99 -One major design idea of the design were:
   1.100 +Major design ideas of the design were:
   1.101  \begin{itemize}
   1.102  	\item free the internal system from in and out channels
   1.103  	\item arbitrary protocol handlers have to be addable afterwards
   1.104 @@ -173,6 +170,9 @@
   1.105  \end{itemize}
   1.106  
   1.107  
   1.108 +
   1.109 +\subsection{Architectural design}
   1.110 +
   1.111  \subsubsection*{Incoming channels}
   1.112  
   1.113  \sendmail-compatible \mta{}s must support at least two incoming channels: mail submitted using the \sendmail\ command, and mail received via the \SMTP\ daemon. It is therefor common to split the incoming channel into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view.
   1.114 @@ -213,18 +213,10 @@
   1.115  %fixme: discuss: filesystem vs. database
   1.116  << \masqmail\ uses the filesytem to store the queue, storing the queue in a databases might improve the reliability through better persistence. >> %fixme
   1.117  
   1.118 -
   1.119  %fixme: what about the ``rule of repair''?
   1.120  
   1.121  
   1.122 -\subsubsection*{Sanitize mail}
   1.123 -
   1.124 -Mail coming into the system often lacks important header lines. At least the required ones must be added from the \MTA. A good example is the \texttt{Message-Id:} header.
   1.125 -
   1.126 -In \postfix, this is done by the \name{cleanup} module, which invokes \name{rewrite}. The position in the message flow is after coming from one of the several incoming channels and before the message is stored into the \name{incoming} queue. Modules that handle incoming channels may also add headers, for example the \texttt{From:} and \texttt{Date:} headers. \name{cleanup}, however, does a complete check to make the mail header complete and valid.
   1.127 -
   1.128 -Apart from deciding where to sanitize the mail header, is the question where to generate the envelope. The envelope specifies the actual recipient of the mail, no matter what the \texttt{To:}, \texttt{Cc:}, and \texttt{Bcc:} headers tell. Multiple reciptients lead to multiple different envelopes, containing all the same mail message.
   1.129 -
   1.130 +\subsection{Functional design}
   1.131  
   1.132  
   1.133  \subsubsection*{Aliasing}
   1.134 @@ -373,6 +365,24 @@
   1.135  
   1.136  
   1.137  
   1.138 +\subsection{Security design}
   1.139 +
   1.140 +\subsubsection*{Sanitize mail}
   1.141 +
   1.142 +Mail coming into the system often lacks important header lines. At least the required ones must be added from the \MTA. A good example is the \texttt{Message-Id:} header.
   1.143 +
   1.144 +In \postfix, this is done by the \name{cleanup} module, which invokes \name{rewrite}. The position in the message flow is after coming from one of the several incoming channels and before the message is stored into the \name{incoming} queue. Modules that handle incoming channels may also add headers, for example the \texttt{From:} and \texttt{Date:} headers. \name{cleanup}, however, does a complete check to make the mail header complete and valid.
   1.145 +
   1.146 +Apart from deciding where to sanitize the mail header, is the question where to generate the envelope. The envelope specifies the actual recipient of the mail, no matter what the \texttt{To:}, \texttt{Cc:}, and \texttt{Bcc:} headers tell. Multiple reciptients lead to multiple different envelopes, containing all the same mail message.
   1.147 +
   1.148 +
   1.149 +
   1.150 +
   1.151 +
   1.152 +
   1.153 +
   1.154 +
   1.155 +
   1.156  
   1.157  \subsection{The resulting architecture}
   1.158