docs/diploma: thesis/tex/5-Improvements.tex comparison

comparison thesis/tex/5-Improvements.tex @ 340:a13392b4fee8

some rework and fixes

author	meillo@marmaro.de
date	Mon, 26 Jan 2009 13:36:51 +0100
parents	3f5088841807
children	a5f167ca2a01

comparison

equal deleted inserted replaced

-:f9f925c5e2d1
+:a13392b4fee8
 The presented setup is the same as the one with two \MTA\ instances and a scanner application in between, which was suggested to add spam and malware scanner afterwards to an \MTA. This is a fortunate coincidence, because a scanner like \name{amavis} can simply be put in replace for the internal socket ``X''.
-\subsubsection*{Conditional compilation}
-<< conditional compilation >>
 \subsection{Design decisions}
-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.
+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.
 A number of major design ideas lead the development of the new architecture:
 \begin{enumerate}
 	\item compartmentalization throughout
 	\item free the internal system from the in and out channels
 	\item have a single point where all mail goes through for scanning
 	\item concentrate on the mail transfer job; use specialized external programs for other jobs
 	\item keep it simple, clear, and general
 \end{enumerate}
+%fixme: << conditional compilation >>
 \subsubsection*{Incoming channels}
-\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
+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.
-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?
+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?
-\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.
+\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.
 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.
 With the increasing need for new protocols in mind, it seems better to have single modules for each incoming channel, although this leads to duplicated acceptance checks. Independent checks in different modules, however, have also the advantage to simply apply different policies. Thus it is possible to run two \SMTP\ modules that listen on different ports; one accessible from the Internet but requires authentication, the other only accessible from the local network but does not require authentication.
 \subsubsection*{The mail queue}
-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.
+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}.)
-%\sendmail, \exim, \qmail, \name{sendmail X}, and \masqmail\ feature one single mail queue. \postfix\ has more of them.
 Common \MTA{}s feature one or more mail queues, they sometimes have effectively several queues within one physical representation.
 \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}.
-\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
+\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}.
 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.
 Hence here the choice is having a directory with simple text files in it. This is straight forward, simple, clear, and general \dots\ and thus a good basis for reliability. It is additionally always of advantage if data is stored in the operation system's natural form, which in the case of \unix\ is plain text.
 \subsubsection*{Aliasing}
-The main question about aliasing is: Where should aliases get expanded?
+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?
 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.
 Aliasing is often handled in expanding the alias and re-injecting 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 re-injecting it is the best choice. But already accepted messages may get rejected in the second go, because of an replacement address from within the system. This seems not to be wanted.
 The best point to archive copies of every incoming mail is the \name{queue-in} module, respectively the \name{queue-out} module for copies outgoing mail. But not respected with this approach are the changes that are made by the receiving modules (adding further headers) and sending modules (address rewrites).
 \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.
+Archiving's functional requirements were described as \RF\,10 on page \pageref{rf10}.
 \subsubsection*{Authentication and Encryption}
-Both topics were discussed several time throughout this thesis, among other places on page \pageref{} and \pageref{}.
+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}.
 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.
 In order to avoid code duplicates, the actual implementation of both functions should be provided by a central source which gets invoked by the various modules.
 \subsubsection*{Spam and malware handling}
-The two approaches for spam handling were already presented to the reader in section \ref{}. Here they are described in more detail:
+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:
 \begin{enumerate}
 \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.
 \item Checking for spam after the mail was accepted and queued. Here more processing time can be invested, so more detailed checks can be done. But, as responsibility for messages was taken by accepting them, it is no choice to simply delete spam mail. Checks for spam do not lead to sure results, they just indicate the possibility the message is unwanted mail. \person{Eisentraut} indicates actions to take after a message is recognized as probably spam \cite[pages 18--20]{eisentraut05}. The only acceptable one, for mail the \MTA\ is responsible for, is adding further or rewriting existent header lines. Thus all further work on the message is the same as for non-spam messages.
 \subsubsection*{The scanning module}
-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.
+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.
-<< fixme >> %fixme
+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.
 The connections between \name{queue-in} and \name{scanning}, as well as between \name{scanning} and \name{queue-out} is provided by the queues, only sending signals to trigger runs may be useful. Communication between receiving and transport modules and the outside world are done using the specific protocol they do handle.
 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.
-\begin{figure}
+\begin{figure}[hbt]
 	\begin{center}
 		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
 	\end{center}
 	\caption{State diagram of the \NAME{IPC} protocol}
 	\label{fig:ipc-protocol}

Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 340:a13392b4fee8