1.1 --- a/thesis/bib/thesis.bib	Thu Jan 22 21:51:19 2009 +0100
     1.2 +++ b/thesis/bib/thesis.bib	Thu Jan 22 21:54:52 2009 +0100
     1.3 @@ -421,3 +421,12 @@
     1.4  	howpublished = "On the Internet: {\small\url{http://www.oss-watch.ac.uk/resources/postmaster.xml} (2009-01-22)}",
     1.5  }
     1.6  
     1.7 +@techreport{cabral01,
     1.8 +	author = "Jim Cabral",
     1.9 +	title = "\emph{Securing Email Through Proxies: Smap and Stunnel}",
    1.10 +	institution = "SANS Institute",
    1.11 +	year = "2001",
    1.12 +	month = "July",
    1.13 +	howpublished = "On the Internet: {\small\url{http://www.sans.org/reading_room/whitepapers/email/securing_email_through_proxies_smap_and_stunnel_579} (2009-01-22)}",
    1.14 +}
    1.15 +

     2.1 --- a/thesis/tex/5-Improvements.tex	Thu Jan 22 21:51:19 2009 +0100
     2.2 +++ b/thesis/tex/5-Improvements.tex	Thu Jan 22 21:54:52 2009 +0100
     2.3 @@ -68,11 +68,23 @@
     2.4  \hfill\cite[page 44]{dent04}
     2.5  \end{quote}
     2.6  
     2.7 -In the meanwhile is \NAME{SMTP-AUTH} supported by most email clients and if encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
     2.8 +These days is \NAME{SMTP-AUTH}, which is defined in \RFC\,2554, supported by most email clients. If encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
     2.9  
    2.10 -<< what to do in code (same like for enc?) >>
    2.11 +\masqmail\ best uses an available \NAME{SASL} library. \name{Cyrus} \NAME{SASL} is used by \postfix\ and \sendmail. It is a complete framework that makes use of existing authentication concepts like \path{/etc/passwd} or \NAME{PAM}. As advantage it can be included in existing user data bases. \name{gsasl} is an alternative. It comes as a library which helps on deciding for a method and on generating the appropriate dialog data; the actual transmission of the data and the authentication against some database is left open to the programmer. \name{gsasl} is used by \name{msmtp} for example. It seems best to give both concepts a try and decide then which one to use.
    2.12  
    2.13 -<< where to store login data >>
    2.14 +Currently, outgoing connections already feature \SMTP-\NAME{AUTH} but only in a hand-coded way. It is to decide wether it remains as it is or gets replaced by the \NAME{SASL} approach, that is used for incoming connections. The decision should be based on the estimated time until the new design is usable.
    2.15 +
    2.16 +Authentication needs code changes at the same places as encryption. The relevant code files are \path{smtp_in.c}, \path{smtp_out.c}, and \path{conf.c}.
    2.17 +
    2.18 +The server code, to authenticate clients, must be added to \path{smtp_in.c} and the configuration options to \path{conf.c}. Several configuration options should be provided: the authentication policy (no authentication, offer authentication, insist on authentication), the authentication backend (if several are supported), an option to refuse plain text methods (\NAME{PLAIN} and \NAME{LOGIN}), and one to require encryption before authentication.
    2.19 +
    2.20 +If the authentication code for outgoing connects shall be changed too, it must be done in \path{smtp_out.c}. The configuration options are already present.
    2.21 +
    2.22 +
    2.23 +About the authentication backend. For a small \MTA\ like \masqmail, it seems preferrable to store the login data in a text file under \masqmail's control. This is the most simple choice for many usage scenarios. But using a central authentication facility has advantages in larger setups too. \name{Cyrus} \NAME{SASL} supports both, so there is no problem. If \name{gsasl} is chosen, it seems best to start with an authentication file under \masqmail's control.
    2.24 +
    2.25 +
    2.26 +
    2.27  
    2.28  
    2.29  << Compare static with dynamic authentication: pros and cons; usecases: when to use what; >>
    2.30 @@ -81,9 +93,23 @@
    2.31  
    2.32  
    2.33  
    2.34 +
    2.35 +
    2.36  \subsubsection*{Security}
    2.37  
    2.38 -by using wrappers and interposition filters
    2.39 +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.
    2.40 +
    2.41 +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.
    2.42 +
    2.43 +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.
    2.44 +
    2.45 +Because the \MTA\ does not listen for connections from extern now, it is not directly attackable. But the \MTA\ can not react on relaying and spam on itself anymore because it has no direct connection to the mail sender. This job needs to be covered by the proxy now. Similar is the situation for encryption and authentication. However, care must be taken that the proxy stays small and simple as its own security will suffer otherwise.
    2.46 +
    2.47 +The advantage is that the \MTA\ itself needs not to bother much with untrusted environments. And a small proxy cares only about that work.
    2.48 +
    2.49 +\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.
    2.50 +
    2.51 +
    2.52  
    2.53  split masqmail into two instances
    2.54  
    2.55 @@ -96,6 +122,8 @@
    2.56  
    2.57  << refer back to enc and auth >>
    2.58  
    2.59 +<< conditional compilation >>
    2.60 +
    2.61  
    2.62  \subsubsection*{Reliability}
    2.63