1.1 --- a/thesis/tex/5-Improvements.tex	Sun Dec 28 18:52:56 2008 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Mon Dec 29 14:05:24 2008 +0100
     1.3 @@ -3,12 +3,103 @@
     1.4  << what to really implement within the thesis >>
     1.5  
     1.6  
     1.7 +
     1.8 +
     1.9 +
    1.10  \section{Implementation}
    1.11  
    1.12 +
    1.13 +
    1.14 +
    1.15 +
    1.16  \subsection{Authentication for SMTP-in}
    1.17  
    1.18 +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.19 +
    1.20 +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.21 +\begin{enumerate}
    1.22 +	\item \SMTP-after-\NAME{POP}: uses authenication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards.
    1.23 +	\item \SMTP authentication: is an extension to \SMTP. Authentication can be requested before mail is accepted.
    1.24 +	\item Certificates: confirm the identity of someone.
    1.25 +\end{enumerate}
    1.26 +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.27 +
    1.28 +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.29 +
    1.30 +\SMTP\ authentication (also refered to as \NAME{SMTP-AUTH}) suppoert is easiest received by using a \name{Simple Authentication and Security Layer} implementation. \person{Dent} sees in \NAME{SASL} the best solution for authenticating dynamic users:
    1.31 +\begin{quote}
    1.32 +%None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.
    1.33 +None of these [authentication methods] is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users.
    1.34 +\cite[page 44]{dent04}
    1.35 +\end{quote}
    1.36 +
    1.37 +%either by
    1.38 +%- network/ip address
    1.39 +%	easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
    1.40 +%or
    1.41 +%- some kind of auth (for dynamic remote hosts)
    1.42 +%	adds complexity
    1.43 +%	- SASL
    1.44 +%	- POP/IMAP: pop-before-smtp, DRAC, WHOSON
    1.45 +%	- TLS (certificates)
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53  \subsection{Encryption}
    1.54  
    1.55 +Electronic mail is very weak to sniffing attacks, because all data transfer is unencrypted. This concerns the message's content, as well as the email addresses in header and envelope, but also authentication dialogs that may transfer plain text passwords (\NAME{PLAIN} and \NAME{LOGIN} are examples). Adding encryption is therefor wanted.
    1.56 +
    1.57 +The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \TLS, successor of \NAME{SSL}). \TLS\ encrypts the datagrams of the \name{transport layer}. This means it works below the application protocols and can be used by any of them\citeweb{wikipedia:tls}.
    1.58 +
    1.59 +\TLS\ allows to create secure tunnels through which arbitrary programs can communicate. Hence one can add secure communication afterwards to programs without changing them. \name{OpenSSL} for example---a free implementation---allows traffic to be piped into a command; a secure tunnel is created and the traffic is forwarded through it. Or a secure tunnel can be set up between a local and a remote port; this tunnel can then be used by any application.
    1.60 +
    1.61 +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.62 +
    1.63 +\begin{figure}
    1.64 +	\begin{center}
    1.65 +		\input{input/stunnel.tex}
    1.66 +	\end{center}
    1.67 +	\caption{Data flow using \name{stunnel}}
    1.68 +	\label{fig:stunnel}
    1.69 +\end{figure}
    1.70 +
    1.71 +For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement.
    1.72 +
    1.73 +\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.
    1.74 +
    1.75 +%TLS/SSL prevents attackers to listen on the cable
    1.76 +%but it does not prevent man-in-the-middle attacks
    1.77 +%signed certificates help here
    1.78 +%   or PGP encryption
    1.79 +
    1.80 +
    1.81 +%do not use stunnel wit SMTP:
    1.82 +%because all incoming mail would be from 127.0.0.1 !!
    1.83 +%use STARTTLS instead
    1.84 +
    1.85 +%postfix: main.cf
    1.86 +%\begin{verbatim}
    1.87 +%	smtpd_use_tls = yes
    1.88 +%	smtpd_tls_received_header = no (does not log in received headers)
    1.89 +%
    1.90 +%	smtpd_tls_key_file = /etc/postfix/key.pem
    1.91 +%	smtpd_tls_cert_file = /etc/postfix/cert.pem
    1.92 +%	smtpd_tls_CA_file = /etc/postfix/CAcert.pem
    1.93 +%
    1.94 +%	smtp_use_tls = yes  (use TLS for sending)
    1.95 +%	smtp_tls_key_file = /etc/postfix/key.pem
    1.96 +%	smtp_tls_cert_file = /etc/postfix/cert.pem
    1.97 +%	smtp_tls_CA_file = /etc/postfix/CAcert.pem
    1.98 +%\end{verbatim}
    1.99 +
   1.100 +
   1.101 +
   1.102 +
   1.103 +
   1.104  
   1.105  
   1.106  \section{Documentation}