docs/diploma: thesis/tex/5-Improvements.tex comparison

comparison thesis/tex/5-Improvements.tex @ 326:802635628c92

various work in ch05

author	meillo@marmaro.de
date	Fri, 23 Jan 2009 11:23:17 +0100
parents	8671d9c0f29a
children	2b1da14922f7

comparison

equal deleted inserted replaced

-:f5225dd052cb
+:802635628c92
 The first three \TODO{}s are implementable by improving the current code or by adding wrappers or interposition filters. The following sections describe solution approaches to do that work.
-\subsubsection*{Encryption}
+\subsection{Encryption}
 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.
 Adding encryption requires changes mainly in three source files: \path{smtp_in.c}, \path{smtp_out.c}, and in \path{conf.c}.
 %	smtp_tls_CA_file = /etc/postfix/CAcert.pem
-\subsubsection*{Authentication}
+\subsection{Authentication}
 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}.
 Static access restriction, based on the \NAME{IP} address is already possible by using \name{TCP Wrappers}. This makes it easy to refuse all connections from outside the local net for example, which is a good prevention of being an open relay. More detailed static restrictions, like splitting between mail for the system and mail to relay, should not be added to the current code. This may be a concern for the new design.
-\subsubsection*{Security}
+\subsection{Security}
 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.
 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.
 The advantage is that the \MTA\ itself needs not to bother much with untrusted environments. And a small proxy cares only about that work.
 \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.
+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.
-split masqmail into two instances
+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
-\begin{verbatim}
-+--------+ ext ||||| int +--------+
+\subsubsection*{A concrete setup}
----> |stripped|---> inter --->|normal  |
-|masqmail|     pos       |masqmail|
+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.
-+--------+     |||||     +--------+
-\end{verbatim}
+\begin{figure}
+	\begin{center}
-<< refer back to enc and auth >>
+		\includegraphics[scale=0.75]{img/proxy-setup.eps}
+	\end{center}
+	\caption{A setup with a proxy}
+	\label{fig:proxy-setup}
+\end{figure}
+\subsubsection*{Spam and malware handling}
+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''.
+\subsubsection*{Conditional compilation}
 << conditional compilation >>
-\subsubsection*{Reliability}
-discuss persistence through using databases
-\subsubsection*{Spam and malware handling}
-discuss the MTA->scanner->MTA approach
-\subsubsection*{Bug fixes}
-already fixed bugs
 \section{A new design}
+\label{sec:new-design}
 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.
 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}.
+Major design ideas of the design were:
-\subsection{Design decisions}
-One major design idea of the design were:
 \begin{itemize}
 	\item free the internal system from in and out channels
 	\item arbitrary protocol handlers have to be addable afterwards
 	\item a single facility for scanning (all mail goes through it)
 	\item concentrate on mail transfer
 \end{itemize}
+\subsection{Architectural design}
 \subsubsection*{Incoming channels}
 \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.
 In contrast is \name{sendmail X}: Its 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 second door?
 %fixme: check, cite, and think about
 %fixme: discuss: filesystem vs. database
 << \masqmail\ uses the filesytem to store the queue, storing the queue in a databases might improve the reliability through better persistence. >> %fixme
 %fixme: what about the ``rule of repair''?
-\subsubsection*{Sanitize mail}
+\subsection{Functional design}
-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.
-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.
-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.
 \subsubsection*{Aliasing}
 Where should aliases get expanded? They appear in different kind. Important are the ones available in the \path{aliases} file. Aliases can be:
 \subsubsection*{Archiving}
 Mail archiving and auditability become more important as electronic mail becomes more important. Ability to archive verbatim copies of every mail coming into and every mail going out of the system, with relation between them, appears to be a goal to achieve.
 \postfix\ for example has a \texttt{always\_bcc} feature, to send a copy of every mail to a definable reciptient. At least this funtionality should be given, although a more complete approach is preferable.
+\subsection{Security design}
+\subsubsection*{Sanitize mail}
+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.
+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.
+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.

Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 326:802635628c92