1.1 --- a/thesis/tex/5-Improvements.tex	Thu Jan 15 15:27:41 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Thu Jan 15 15:44:31 2009 +0100
     1.3 @@ -62,11 +62,13 @@
     1.4  Several ways to restrict access are available. The most simple one is restrictiction by the \NAME{IP} address. No extra complexity is added this way, but static \NAME{IP} addresses are mandatory. This kind of restriction may be enabled using the operating system's \path{hosts.allow} and \path{hosts.deny} files. To allow only connections to port 25 from localhost or the local network \texttt{192.168.100.0/24} insert the line ``\texttt{25: ALL}'' into \path{hosts.deny} and ``\texttt{25: 127.0.0.1, 192.168.100.}'' into \path{hosts.allow}.
     1.5  
     1.6  If static access restriction is not possible, for example if mail from locations with changing \NAME{IP} addresses wants to be accepted, some kind of authentication mechanism is required. Three common kinds exist:
     1.7 +
     1.8  \begin{enumerate}
     1.9  	\item \SMTP-after-\NAME{POP}: uses authenication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards.
    1.10  	\item \SMTP authentication: is an extension to \SMTP. Authentication can be requested before mail is accepted.
    1.11  	\item Certificates: confirm the identity of someone.
    1.12  \end{enumerate}
    1.13 +
    1.14  The first mechanism requires a \NAME{POP} (or \NAME{IMAP}) server running on the same host (or a trusted one), to enable the \SMTP\ server to use the login dates on the \NAME{POP} server. This is a common practice used by mail service providers, but is not adequate for the environments \masqmail\ is designed for.
    1.15  
    1.16  Certificate based authentication, like provided by \NAME{TLS}, suffers from the overhead of certificate management. But \NAME{TLS} provides encryption too, so is useful anyway.
    1.17 @@ -78,6 +80,8 @@
    1.18  \hfill\cite[page 44]{dent04}
    1.19  \end{quote}
    1.20  
    1.21 +
    1.22 +Compare static with dynamic authentication: pros and cons; usecases: when to use what; how could this be covered by architecture (e.g. smtp submission).
    1.23  %either by
    1.24  %- network/ip address
    1.25  %	easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
    1.26 @@ -96,9 +100,20 @@
    1.27  
    1.28  split masqmail into two instances
    1.29  
    1.30 +\begin{verbatim}
    1.31 +     +--------+ ext ||||| int +--------+
    1.32 +---> |stripped|---> inter --->|normal  |
    1.33 +     |masqmail|     pos       |masqmail|
    1.34 +     +--------+     |||||     +--------+
    1.35 +\end{verbatim}
    1.36  
    1.37  
    1.38  
    1.39 +\subsection{Spam and malware handling}
    1.40 +
    1.41 +discuss the MTA->scanner->MTA approach
    1.42 +
    1.43 +
    1.44  
    1.45  \subsection{Bug fixes}
    1.46  
    1.47 @@ -173,6 +188,9 @@
    1.48  \sendmail, \exim, \qmail, and \masqmail\ all use at least two files to store one message in the queue: one file contains the message body, another the envelope and header information. The one containing the mail body is not modified at all. \postfix\ takes a different approach in storing queued messages in an internal format within one file. \person{Finch} takes yet another different approach in suggesting to store the whole queue in one single file with pointers to separating positions \cite{finchFIXME}.
    1.49  %fixme: check, cite, and think about
    1.50  
    1.51 +%fixme: discuss: filesystem vs. database
    1.52 +
    1.53 +%fixme: what about the ``rule of repair''?
    1.54  
    1.55  
    1.56  \subsubsection*{Sanitize mail}