1.1 --- a/thesis/tex/5-Improvements.tex	Thu Jan 15 22:45:13 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Thu Jan 15 22:45:51 2009 +0100
     1.3 @@ -132,7 +132,7 @@
     1.4  
     1.5  
     1.6  
     1.7 -\section{The new design}
     1.8 +\section{A new design}
     1.9  
    1.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.
    1.11  
    1.12 @@ -206,12 +206,12 @@
    1.13  \subsubsection*{Aliasing}
    1.14  
    1.15  Where should aliases get expanded? They appear in different kind. Important are the ones available in the \path{aliases} file. Aliases can be:
    1.16 -\begin{itemize}
    1.17 +\begin{enumerate}
    1.18  	\item a different local user (e.g.\ ``\texttt{bob: alice}'')
    1.19  	\item a remote user (e.g.\ ``\texttt{bob: john@example.com}'')
    1.20  	\item a list of users (e.g.\ ``\texttt{bob: alice, john@example.com}'')
    1.21  	\item a command (e.g.\ ``\texttt{bob: |foo}'')
    1.22 -\end{itemize}
    1.23 +\end{enumerate}
    1.24  Addresses expanding to lists of users lead to more envelopes. Aliases changing the reciptients domain part may require a different route to use.
    1.25  
    1.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.