1.1 --- a/thesis/tex/5-Improvements.tex	Fri Feb 06 21:09:21 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Sat Feb 07 11:42:45 2009 +0100
     1.3 @@ -80,7 +80,7 @@
     1.4  \hfill\cite[page~44]{dent04}
     1.5  \end{quote}
     1.6  
     1.7 -These days \NAME{SMTP-AUTH}---defined in \RFC\,2554---is supported by most email clients. If encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
     1.8 +These days \NAME{SMTP-AUTH}---defined in \RFC\,2554---is supported by almost all email clients. If encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
     1.9  
    1.10  
    1.11  \subsubsection*{Simple Authentication and Security Layer}
    1.12 @@ -136,7 +136,7 @@
    1.13  \index{inetd}
    1.14  \index{proxy}
    1.15  
    1.16 -Mail from outside would then come through the proxy into the system. Mail from the local host and from the local network could be directly accepted by the normal \masqmail, if those locations are considered trusted. But it seems better to have them use the proxy too, or maybe a second proxy instance with different policy.
    1.17 +Mail from outside would then come through the proxy into the system. Mail from the local host and from the local network could be directly accepted by the normal \masqmail, if those locations are considered trusted. But it seems better to have them use the proxy, too, or maybe a second proxy instance with different policy.
    1.18  \index{policy}
    1.19  
    1.20  The here described setup comes close to the structure of the incoming channels in the new design which is described in section~\ref{sec:new-design}. This shows the capabilities of the here chosen approach.
    1.21 @@ -144,7 +144,7 @@
    1.22  
    1.23  \subsubsection*{A concrete setup}
    1.24  
    1.25 -A stripped down proxy needs to be created. It should only be able to receive mail via \SMTP, encrypt the communication, authenticate clients, and send mail out via \SMTP\ to an internal socket (named ``X'' in the figure). This is a straight forward task. The normal \masqmail\ instance runs on the system too. It takes input from \name{stdin} (when the \path{sendmail} command is invoked) and via \SMTP\ where it listens on an internal socket (named ``X'' in the figure). Outgoing mail is handled without difference to a regular setup. Figure~\ref{fig:proxy-setup} depicts the setup.
    1.26 +A stripped down proxy needs to be created. It should only be able to receive mail via \SMTP, encrypt the communication, authenticate clients, and send mail out via \SMTP\ to an internal socket (named ``X'' in the figure). This is a straight forward task. The normal \masqmail\ instance runs on the system, too. It takes input from \name{stdin} (when the \path{sendmail} command is invoked) and via \SMTP\ where it listens on an internal socket (named ``X'' in the figure). Outgoing mail is handled without difference to a regular setup. Figure~\ref{fig:proxy-setup} depicts the setup.
    1.27  \index{auth}
    1.28  \index{enc}
    1.29  
    1.30 @@ -219,7 +219,7 @@
    1.31  \index{smtp}
    1.32  \index{setuid}
    1.33  
    1.34 -But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP. To \qmail\ and \postfix\ new protocol handlers may be added without change in other parts of the system. The \SMTP\ modules can even be removed if it is not needed. It is better to have a larger number of independent modules if each one is simpler then. The need to implement \SMTP\ clients in every module for internal communication makes them more complicated.
    1.35 +But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP. To \qmail\ and \postfix\ new protocol handlers may be added without change in other parts of the system. The \SMTP\ modules can even get removed if it is not needed. It is better to have a larger number of independent modules if each one is simpler then. The need to implement \SMTP\ clients in every module for internal communication makes them more complicated.
    1.36  \index{qmail}
    1.37  \index{postfix}
    1.38  
    1.39 @@ -288,7 +288,7 @@
    1.40  
    1.41  The mail body will never get modified, except for removing and adding transfer protocol specific requirements like dot stuffing or special line ending characters. These translations are only done in receiving and sending modules.
    1.42  
    1.43 -\person{Jon Postel}'s robustness principle (``Be liberal in what you accept, and conservative in what you send.''), which can be found in this wording in \RFC\,1122 and in different wordings in numerous \RFC{}s, should be respected in the \name{scanning} module. The module should parse the given input in a liberal way and generate clean output. \person{Raymond}'s \name{Rule of Repair} (``Repair what you can -- but when you must fail, fail noisily and as soon as possible.'') \cite[page~18]{raymond03} can be applied too. But it is important to repair only obvious problems, because repairing functionality is likely a target for attacks.
    1.44 +\person{Jon Postel}'s robustness principle\footnote{``Be liberal in what you accept, and conservative in what you send.''. In this wording in \RFC\,1122 and in different wordings in numerous \RFC{}s} should be respected in the \name{scanning} module. The module should parse the given input in a liberal way and generate clean output. \person{Raymond}'s \name{Rule of Repair}\footnote{``Repair what you can -- but when you must fail, fail noisily and as soon as possible.'' \cite[page~18]{raymond03}} can be applied, too. But it is important to repair only obvious problems, because repairing functionality is likely a target for attacks.
    1.45  \index{robustness!principle of}
    1.46  
    1.47  
    1.48 @@ -484,6 +484,12 @@
    1.49  
    1.50  Left is only the communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Suggested for this communication is a simple protocol with data exchange through \unix\ pipes. Figure~\ref{fig:ipc-protocol} shows a state diagram for the protocol.
    1.51  
    1.52 +The protocol is described in more detail now:
    1.53 +\index{protocol}
    1.54 +
    1.55 +\paragraph{Timing}
    1.56 +One dialog consists of exactly three phases: (1) The connection attempt, (2) The envelope and header transfer, and (3) The transfer of the message body. The order is always the same. The three phases are all initiated by the client process. After each phase the server process sends a success or failure reply. Timeouts for each phase need to be implemented.
    1.57 +
    1.58  \begin{figure}
    1.59  	\begin{center}
    1.60  		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
    1.61 @@ -493,12 +499,6 @@
    1.62  	\label{fig:ipc-protocol}
    1.63  \end{figure}
    1.64  
    1.65 -The protocol is described in more detail now:
    1.66 -\index{protocol}
    1.67 -
    1.68 -\paragraph{Timing}
    1.69 -One dialog consists of exactly three phases: (1) The connection attempt, (2) The envelope and header transfer, and (3) The transfer of the message body. The order is always the same. The three phases are all initiated by the client process. After each phase the server process sends a success or failure reply. Timeouts for each phase need to be implemented.
    1.70 -
    1.71  \paragraph{Semantics}
    1.72  The connection attempt is simply opening the connection. This starts the dialog. A positive reply by the server leads to the transfer of the envelope and the message header. If the server again sends a positive reply, the message data is transferred. A last server reply ends the dialog.
    1.73