1.1 --- a/thesis/tex/5-Improvements.tex	Mon Jan 26 13:36:18 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Mon Jan 26 13:36:51 2009 +0100
     1.3 @@ -131,12 +131,6 @@
     1.4  
     1.5  
     1.6  
     1.7 -\subsubsection*{Conditional compilation}
     1.8 -<< conditional compilation >>
     1.9 -
    1.10 -
    1.11 -
    1.12 -
    1.13  
    1.14  
    1.15  
    1.16 @@ -161,7 +155,7 @@
    1.17  
    1.18  \subsection{Design decisions}
    1.19  
    1.20 -This section describes and discusses architectural decision that were made for the new design. At some points function is of matter too, but it is mostly about architecture.
    1.21 +This section describes and discusses architectural decision that were made for the new design. To functional requirements is refered to, as they were already identified in chapter \ref{chap:present-and-future}. %fixme: At some points function is of matter too, but it is mostly about architecture.
    1.22  
    1.23  A number of major design ideas lead the development of the new architecture:
    1.24  \begin{enumerate}
    1.25 @@ -173,14 +167,15 @@
    1.26  	\item keep it simple, clear, and general
    1.27  \end{enumerate}
    1.28  
    1.29 +%fixme: << conditional compilation >>
    1.30  
    1.31  
    1.32  \subsubsection*{Incoming channels}
    1.33  
    1.34 -\sendmail-compatible \mta{}s must support at least two incoming channels: mail submitted using the \sendmail\ command, and mail received via the \SMTP\ daemon. It is therefore common to split the incoming channel into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view \cite{hafiz05}. %fixme: specify page
    1.35 +The functional requirements were already discussed as \RF\,1 on page \pageref{rf1}. At least two incoming channels were identified: the \path{sendmail} command for local mail submission and the \SMTP\ daemon for remote connections.
    1.36  
    1.37 -In contrast is \name{sendmail X}: Its locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a back door?
    1.38 -\person{Finch} proposes a similar approach. He wants the \texttt{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA\ like it is done by connections from remote. The advantage here is one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid} because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
    1.39 +A bit different is the structure of \name{sendmail X} at that point: Locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a back door?
    1.40 +\person{Finch} proposes a similar approach \cite{finch-sendmail}. He wants the \texttt{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA\ like it is done by connections from remote. The advantage here is one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid} because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
    1.41  
    1.42  But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP. To \qmail\ and \postfix\ new modules to support other ways of message reception may be added without change of other parts of the system. Also the \SMTP\ modules can be removed if it is not needed. And it is better to have more independent modules if each one is simpler then---it makes the modules more complicated if each one needs to implement an \SMTP\ client.
    1.43  
    1.44 @@ -206,14 +201,13 @@
    1.45  
    1.46  \subsubsection*{The mail queue}
    1.47  
    1.48 -The mail queue is the central part of an \MTA. This demands especially for robustness and reliability as a failure here can lead to loosing mail.
    1.49 +The mail queue is the central part of an \MTA. This demands especially for robustness and reliability as a failure here can lead to loosing mail. (See \RF\,2 on page \pageref{rf2}.)
    1.50  
    1.51 -%\sendmail, \exim, \qmail, \name{sendmail X}, and \masqmail\ feature one single mail queue. \postfix\ has more of them.
    1.52  Common \MTA{}s feature one or more mail queues, they sometimes have effectively several queues within one physical representation.
    1.53  
    1.54  \MTA\ setups that include content scanning tend to require two separate queues. To use \sendmail\ in such setups requires two independent instances with two separate queues. \exim\ can handle it with special \name{router} and \name{transport} rules but the data flow gets complicated. Hence an idea is to use two queues, \name{incoming} and \name{active} in \postfix's terminology, with the content scanning within the move from \name{incoming} to \name{active}.
    1.55  
    1.56 -\sendmail, \exim, \qmail, and \masqmail\ all use at least two files to store one message in the queue: one file contains the message body, another the envelope and header information. The one containing the mail body is not modified at all. \postfix\ takes a different approach in storing queued messages in an internal format within one file. \person{Finch} suggest yet another approach: storing the whole queue in one single file with pointers to separating positions \cite{finchFIXME}. %fixme: check, cite, and think about
    1.57 +\sendmail, \exim, \qmail, and \masqmail\ all use at least two files to store one message in the queue: one file contains the message body, another the envelope and header information. The one containing the mail body is not modified at all. \postfix\ takes a different approach in storing queued messages in an internal format within one file. \person{Finch} suggest yet another approach: storing the whole queue in one single file with pointers to separating positions \cite{finch-queue}.
    1.58  
    1.59  All of the presented \MTA{}s use the file system to hold the queue; none uses a database to hold it. A database could improve the reliability of the queue through better persistence. This might be a choice for larger \MTA{}s but is none for \masqmail\ which should be kept small and simple. A running database system does likely require much more resources than \masqmail\ itself does. And as the queue's job is more storing data than running data selection queries, a database does not gain so much that it outweighs its costs.
    1.60  
    1.61 @@ -242,7 +236,7 @@
    1.62  
    1.63  \subsubsection*{Aliasing}
    1.64  
    1.65 -The main question about aliasing is: Where should aliases get expanded?
    1.66 +The functional requirements were identified under \RF\,4 on page \pageref{rf4}. From the architectural point of view, the main question about aliasing is: Where should aliases get expanded?
    1.67  
    1.68  Two facts are important to consider: Addresses expanding to lists of users lead to more envelopes. And aliases changing the recipient's domain part may make the message unsuitable for a specific online route.
    1.69  
    1.70 @@ -265,13 +259,15 @@
    1.71  
    1.72  \qmail\ has the ability to log complete \SMTP\ dialogs. Logging the complete data transaction into and out of the system into a separate log file is a great feature which should be implemented into each receiving and sending module. But as it will produce a huge amount of output, it should be cared to disabled it by default.
    1.73  
    1.74 +Archiving's functional requirements were described as \RF\,10 on page \pageref{rf10}.
    1.75 +
    1.76  
    1.77  
    1.78  
    1.79  
    1.80  \subsubsection*{Authentication and Encryption}
    1.81  
    1.82 -Both topics were discussed several time throughout this thesis, among other places on page \pageref{} and \pageref{}.
    1.83 +Both topics were discussed as \RF\,6 and \RF\,7 on several places throughout this thesis remarkable ones are on page \pageref{rf6} and \pageref{rf7}.
    1.84  
    1.85  Authentication should be done within the receiving modules. Similar should authentication for outgoing connections be handled by the sending modules. To encryption applies the same as to authentication here. Only receiving and sending modules should come in contact with it.
    1.86  
    1.87 @@ -284,7 +280,7 @@
    1.88  
    1.89  \subsubsection*{Spam and malware handling}
    1.90  
    1.91 -The two approaches for spam handling were already presented to the reader in section \ref{}. Here they are described in more detail:
    1.92 +The two approaches for spam handling were already presented to the reader in section \ref{sec:functional-requirements} as \RF\,8 and \RF\,9. Here they are described in more detail:
    1.93  
    1.94  \begin{enumerate}
    1.95  \item Refusing spam during the \SMTP\ dialog. This is the way it was meant by the designers of the \SMTP\ protocol. They thought checking the sender and recipient mail addresses would be enough, but as they are forgeable it is not. More and more complex checks need to be done. Checking needs time, but \SMTP\ dialogs time out if it takes too long. Thus only limited time can be used, during the \SMTP\ dialog, for checking if a message seems to be spam. The advantage is that acceptance of bad messages can be simply refused---no responsibility for the message is taken and no further system load is added. See \RFC2505 (especially section 1.5) for detail.
    1.96 @@ -307,9 +303,10 @@
    1.97  
    1.98  \subsubsection*{The scanning module}
    1.99  
   1.100 -A lot of work was put onto the \name{scanning} module. This is not what is desired. Thus splitting it up into single parts appears to be necessary. But the decision how to split is left up to the time of prototyping.
   1.101 +A problem, which gets probably noticed by a attentive reader, is the lot of work that was put onto the \name{scanning} module. This is not what is desired. Thus splitting this module into a set of single modules appears to be necessary.
   1.102  
   1.103 -<< fixme >> %fixme
   1.104 +The decision how to split shall not be discussed here. It is left up to the time of prototyping, because trying different approaches is good in such situations.
   1.105 +
   1.106  
   1.107  
   1.108  
   1.109 @@ -408,7 +405,7 @@
   1.110  
   1.111  Left is only communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Data is exchanged using \unix\ pipes and a simple protocol. Figure \ref{fig:ipc-protocol} shows a state diagram for the protocol. Solid lines indicate client actions, dashed lines indicate server responses.
   1.112  
   1.113 -\begin{figure}
   1.114 +\begin{figure}[hbt]
   1.115  	\begin{center}
   1.116  		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
   1.117  	\end{center}