# HG changeset patch
# User meillo@marmaro.de
# Date 1231543651 -3600
# Node ID adb7ecbc92da310621ab6af7c6ba35a6776f3e4d
# Parent  35b0dfefd2c4e3ae98a5bf275c48b6dfbd37aeb5
removed obsolete figure

diff -r 35b0dfefd2c4 -r adb7ecbc92da thesis/tex/5-Improvements.tex
--- a/thesis/tex/5-Improvements.tex	Sat Jan 10 00:27:06 2009 +0100
+++ b/thesis/tex/5-Improvements.tex	Sat Jan 10 00:27:31 2009 +0100
@@ -59,14 +59,6 @@
 
 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.
 
-\begin{figure}
-	\begin{center}
-		\input{input/stunnel.tex}
-	\end{center}
-	\caption{Data flow using \name{stunnel}}
-	\label{fig:stunnel}
-\end{figure}
-
 For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement.
 
 \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.