1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Thu Jan 15 22:45:13 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Thu Jan 15 22:45:51 2009 +0100
     1.3 @@ -98,11 +98,11 @@
     1.4  Several ways to restrict access are available. The most simple one is restriction by the \NAME{IP} address. No extra complexity is added this way, but the \NAME{IP} addresses have to be static or within known ranges. This approach is often used to allow relaying for local nets. The access check can be done by the \MTA\ or by a guard (e.g.\ \NAME{TCP} \name{Wrappers}) before. The main advantage here is the minimal setup and maintainence work needed. This kind of access restriction is important to be implemented.
     1.5  
     1.6  This authentication based on \NAME{IP} addresses is impossible in situations where hosts with changing \NAME{IP} addresses, that are not part of a known subnet, need access. Then a authentication mechanism based on some \emph{secret} is required. Three common approaches exist:
     1.7 -\begin{itemize}
     1.8 +\begin{enumerate}
     1.9  	\item \SMTP-after-\NAME{POP}: Uses authentication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards. The variant \SMTP-after-\NAME{IMAP} exists too.
    1.10  	\item \SMTP\ authentication: An extension to \SMTP. It allows to request authentication before mail is accepted. Here no helper protocols are needed.
    1.11  	\item Certificates: The identity of a user or a host is confirmed by certificates that are signed by trusted authorities. Certificates are closely related to encryption, they do normally satisfy both needs: \NAME{SSL} tunnels encrypt the data transmission and allow to identify the remote user/host by his certificate.
    1.12 -\end{itemize}
    1.13 +\end{enumerate}
    1.14  At least one of the secret-based mechanisms should be supported.
    1.15  
    1.16  

     2.1 --- a/thesis/tex/5-Improvements.tex	Thu Jan 15 22:45:13 2009 +0100
     2.2 +++ b/thesis/tex/5-Improvements.tex	Thu Jan 15 22:45:51 2009 +0100
     2.3 @@ -132,7 +132,7 @@
     2.4  
     2.5  
     2.6  
     2.7 -\section{The new design}
     2.8 +\section{A new design}
     2.9  
    2.10  The last chapter identified the requirements for a modern and securt \masqmail. Now the various jobs of an \MTA\ get assigned to modules, of which the new architecture is created. It is inspired by existing \MTA{}s and driven by the identified requirements.
    2.11  
    2.12 @@ -206,12 +206,12 @@
    2.13  \subsubsection*{Aliasing}
    2.14  
    2.15  Where should aliases get expanded? They appear in different kind. Important are the ones available in the \path{aliases} file. Aliases can be:
    2.16 -\begin{itemize}
    2.17 +\begin{enumerate}
    2.18  	\item a different local user (e.g.\ ``\texttt{bob: alice}'')
    2.19  	\item a remote user (e.g.\ ``\texttt{bob: john@example.com}'')
    2.20  	\item a list of users (e.g.\ ``\texttt{bob: alice, john@example.com}'')
    2.21  	\item a command (e.g.\ ``\texttt{bob: |foo}'')
    2.22 -\end{itemize}
    2.23 +\end{enumerate}
    2.24  Addresses expanding to lists of users lead to more envelopes. Aliases changing the reciptients domain part may require a different route to use.
    2.25  
    2.26  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.