1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Dec 20 20:51:48 2008 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Mon Dec 22 20:42:33 2008 +0100
     1.3 @@ -193,15 +193,9 @@
     1.4  	\item a list of users (e.g.\ ``\texttt{bob: alice, john@example.com}'')
     1.5  	\item a command (e.g.\ ``\texttt{bob: |foo}'')
     1.6  \end{itemize}
     1.7 -Aliases can be cascaded like in the following example:
     1.8 -\begin{verbatim}
     1.9 -team:   alice, bob
    1.10 -bob:    bob@example.com
    1.11 -\end{verbatim}
    1.12 -
    1.13  Addresses expanding to lists of users lead to more envelopes. Aliases changing the reciptients domain part may require a different route to use.
    1.14  
    1.15 -Aliasing is often handled in expanding the alias and reinjecting the mail into the system. Unfortunately, the mail is processed twice using this approach; also does the system need to handle more mail this way. Is it needed to check the new recipient address for acceptance, or should it be accepted generally? (The aliase actually came from inside the system.) A second point for access control seems to be no choice.
    1.16 +Aliasing is often handled in expanding the alias and reinjecting the mail into the system. Unfortunately, the mail is processed twice then; additionally does the system have to handle more mail this way. If it is wanted to check the new recipient address for acceptance and do all processing again, then reinjecting it is the best choice.
    1.17  
    1.18  
    1.19  
    1.20 @@ -242,85 +236,50 @@
    1.21  
    1.22  \subsubsection*{Encryption}
    1.23  
    1.24 -TLS/SSL prevents attackers to listen on the cable
    1.25 -but it does not prevent man-in-the-middle attacks
    1.26 -signed certificates help here
    1.27 +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.28  
    1.29 +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.30  
    1.31 -ch /usr/share/ssl/misc
    1.32 +\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.33  
    1.34 -create new CA:
    1.35 -\begin{verbatim}
    1.36 -	CA.pl -newca
    1.37 -		country: DE
    1.38 -		state: schwaben
    1.39 -		city: Ulm
    1.40 -		company:
    1.41 -		section:
    1.42 -		name:
    1.43 -		emailaddress:
    1.44 -\end{verbatim}
    1.45 +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.46  
    1.47 -generate ssl key:
    1.48 -\begin{verbatim}
    1.49 -	CA.pl -newreq
    1.50 -		... the same questions
    1.51 -\end{verbatim}
    1.52 +\begin{figure}
    1.53 +	\begin{center}
    1.54 +		\input{input/stunnel.tex}
    1.55 +	\end{center}
    1.56 +	\caption{Data flow using \name{stunnel}}
    1.57 +	\label{fig:stunnel}
    1.58 +\end{figure}
    1.59  
    1.60 -sign request with CA:
    1.61 -\begin{verbatim}
    1.62 -	CA.pl -sign
    1.63 -\end{verbatim}
    1.64 +For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement.
    1.65  
    1.66 -remove passphrase from private key:
    1.67 -\begin{verbatim}
    1.68 -	openssl rsa <newreq.pem >key.pem
    1.69 -	(to be used by programs automaticly)
    1.70 -\end{verbatim}
    1.71 +\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.72  
    1.73 -secure:
    1.74 -\begin{verbatim}
    1.75 -	chmod 400 *.pem
    1.76 -	cp newcert.pem /etc/postfix/cert.pem
    1.77 -	cp key.pem /etc/postfix/key.pem
    1.78 -	cp demoCA/cacert.pem /etc/postfix/CAcert.pem
    1.79 -	chmode 400 /etc/postfix/*.pem
    1.80 +%TLS/SSL prevents attackers to listen on the cable
    1.81 +%but it does not prevent man-in-the-middle attacks
    1.82 +%signed certificates help here
    1.83 +%   or PGP encryption
    1.84  
    1.85 -	mkdir /etc/stunnel
    1.86 -	cat newcert.pem key.pem >/etc/stunnel/stunnel.pem
    1.87 -	chmod 400 /etc/stunnel/stunnel.pem
    1.88 -	(check /etc/stunnel with `stunnel -V')
    1.89 -\end{verbatim}
    1.90  
    1.91 +%do not use stunnel wit SMTP:
    1.92 +%because all incoming mail would be from 127.0.0.1 !!
    1.93 +%use STARTTLS instead
    1.94  
    1.95 -set up stunnels for POP, etc:
    1.96 -\begin{verbatim}
    1.97 -	nmap localhost
    1.98 -	stunnel -d pop3s -r localhost:pop3 -p /etc/stunnel/stunnel.pem
    1.99 -	stunnel -d imaps -r localhost:imap -p /etc/stunnel/stunnel.pem
   1.100 -	nmap localhost
   1.101 -		pop3s 995
   1.102 -		imaps 993
   1.103 -\end{verbatim}
   1.104 -
   1.105 -do not use stunnel wit SMTP:
   1.106 -because all incoming mail would be from 127.0.0.1 !!
   1.107 -use STARTTLS instead
   1.108 -
   1.109 -postfix: main.cf
   1.110 -\begin{verbatim}
   1.111 -	smtpd_use_tls = yes
   1.112 -	smtpd_tls_received_header = no (does not log in received headers)
   1.113 -
   1.114 -	smtpd_tls_key_file = /etc/postfix/key.pem
   1.115 -	smtpd_tls_cert_file = /etc/postfix/cert.pem
   1.116 -	smtpd_tls_CA_file = /etc/postfix/CAcert.pem
   1.117 -
   1.118 -	smtp_use_tls = yes  (use TLS for sending)
   1.119 -	smtp_tls_key_file = /etc/postfix/key.pem
   1.120 -	smtp_tls_cert_file = /etc/postfix/cert.pem
   1.121 -	smtp_tls_CA_file = /etc/postfix/CAcert.pem
   1.122 -\end{verbatim}
   1.123 +%postfix: main.cf
   1.124 +%\begin{verbatim}
   1.125 +%	smtpd_use_tls = yes
   1.126 +%	smtpd_tls_received_header = no (does not log in received headers)
   1.127 +%
   1.128 +%	smtpd_tls_key_file = /etc/postfix/key.pem
   1.129 +%	smtpd_tls_cert_file = /etc/postfix/cert.pem
   1.130 +%	smtpd_tls_CA_file = /etc/postfix/CAcert.pem
   1.131 +%
   1.132 +%	smtp_use_tls = yes  (use TLS for sending)
   1.133 +%	smtp_tls_key_file = /etc/postfix/key.pem
   1.134 +%	smtp_tls_cert_file = /etc/postfix/cert.pem
   1.135 +%	smtp_tls_CA_file = /etc/postfix/CAcert.pem
   1.136 +%\end{verbatim}
   1.137  
   1.138  
   1.139