1.1 --- a/thesis/tex/5-Improvements.tex	Sat Jan 10 00:27:06 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Sat Jan 10 00:27:31 2009 +0100
     1.3 @@ -59,14 +59,6 @@
     1.4  
     1.5  The \NAME{POP} protocol, for example, is good suited for such tunneling, but \SMTP\ is is not generally. Outgoing \SMTP\ client connections can be tunneled without problem---\masqmail\ already provides a configure option called \texttt{wrapper} to do so. Tunneling incomming connections to a server leads to problems with \SMTP. As data comes encrypted through the tunnel to the receiving host and gets then decrypted and forwarded on local to the port the application listens on. From the \MTA's view, this makes all connections appear to come from localhost, unfortunately. Figure \ref{fig:stunnel} depicts the data flow.
     1.6  
     1.7 -\begin{figure}
     1.8 -	\begin{center}
     1.9 -		\input{input/stunnel.tex}
    1.10 -	\end{center}
    1.11 -	\caption{Data flow using \name{stunnel}}
    1.12 -	\label{fig:stunnel}
    1.13 -\end{figure}
    1.14 -
    1.15  For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement.
    1.16  
    1.17  \masqmail\ is already able to encrypt outgoing connections, but encryption of incoming connections, using \NAME{STARTTLS} should be implemented. This only affects the \SMTP\ server module.