docs/diploma: thesis/tex/4-MasqmailsFuture.tex comparison

comparison thesis/tex/4-MasqmailsFuture.tex @ 182:e35c7962d84f

wrote about spool file and permissions

author	meillo@marmaro.de
date	Sun, 28 Dec 2008 18:50:23 +0100
parents	d75bd7a72d8b
children	1611abd5443b

comparison

equal deleted inserted replaced

-:5dc8ad30760e
+:e35c7962d84f
 \sendmail, \exim, \qmail, \name{sendmail X}, and \masqmail\ feature one single mail queue. \postfix\ has three of them: \name{incoming}, \name{active}, and \name{deferred}. (The \name{maildrop} queue is excluded, as it is only used for the \texttt{sendmail} command.)
 \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, running. \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} takes yet another different approach in suggesting to store the whole queue in one single file with pointers to separating positions \cite{finchFIXME}.
+%fixme: check, cite, and think about
 \subsubsection*{Sanitize mail}
 Mail coming into the system often lacks important header lines. At least the required ones must be added from the \MTA. A good example is the \texttt{Message-Id:} header.
 The new architecture consists of several modules and two queues. They are defined in more detail now, and the jobs, identified above, are assigned to them. First the three main modules, then the queues, and afterwards the modules for incoming and outgoing transfer.
 The \name{queue-in} module creates new spool files in the \name{incoming} queue for incoming messages. It is a process running in background, waiting for connections from one of the receiver modules. When one of them requests for a new spool file, the \name{queue-in} module opens one and returns a positive result. The receiver module then sends the envelope and message, which is written into the spool file by \name{queue-in}. If all went well, another positive result is returend.
+%fixme: should be no daemon
 The \name{scanning} module is the central part of the system. It takes spooled messages from the \name{incoming} queue, works on them, and writes them to the \name{outgoing} queue afterwards (the message is then removed from the \name{incoming} queue, of course). The main job is the processing done on the message. Headers are fixed and missing ones are added if necessary, aliasing is done, and external processing of any kind is triggered. The \name{scanning} module can run in background and look for new mail in regular intvals or signals may be sent to it by \name{queue-in}. Alternatively it can be called by \name{cron}, for example, to do single runs.
 	\label{fig:ipc-protocol}
 \end{figure}
 % timing
 One dialog consists of the four phases: connection attempt, acceptance reply, data transfer, success reply. The order is always the same. The connection attempt and data transfer are sent by the client process; replies are sent by the server process.
+%fixme: split between header and data
 % semantics
 The connection attempt is simply opening the connection. This starts the dialog. A positive reply by the server leads to the data transfer, but a negative reply refuses the connection and resets both client and server to the state before the connection attempt. If the connection attempt was accepted, the client sends the data ending with a terminator sequence. When this terminator appears, the server process knows the complete data was transfered. The server process takes responsibility of the data in sending a positive success reply. A negative success reply resets both client and server to the state before the connection attempt.
 The data transfered needs to be of specific format. Used is the same format in which messages are spooled in the mail queues. See the following section for details. %fixme: check if it is the following section
+%fixme: split between header and data
 % syntax
 Data transfer is done sending plain text data. %fixme: utf8 ?
-The terminator sequence used to indicate the end of the data transfer is a single dot on a line on its own. Line separators are the combination of \name{New Line} and \name{Carriage Return}, as it is used in various Internet protocols like \SMTP. Replys are one-digit numbers with \texttt{0} meaning success and any other number (\texttt{1}--\texttt{9}) indicate failure. %fixme: is it NL-CR or CR-NL? What are the octal values?
+The terminator sequence used to indicate the end of the data transfer is a single dot on a line on its own. Line separators are the combination of \name{Carriage Return} and \name{Line Feed}, as it is used in various Internet protocols like \SMTP. Replys are one-digit numbers with \texttt{0} meaning success and any other number (\texttt{1}--\texttt{9}) indicate failure. %fixme: What are the octal values?
+%fixme: split between header and data
 Figure \ref{fig:ipc-protocol} is a state diagram for the protocol.
 \subsection{Spool file format}
-<< talk about fanf >>
+The spool file format is basically the same as the one in current \masqmail: one file for the message body, the other for envelope and header information. The data file is stored in a separate data pool. It is written by \name{queue-in}, \name{scanning} can read it if necessary, \name{queue-out} reads it to generate the outgoing message, and deletes it after successful transfer. The header file (including the envelope) is written into the \name{incoming} queue. The \name{scanning} modules reads it, processes it, and writes a modified copy into the \name{outgoing} queue; the file in \name{incoming} is deleted then. \name{queue-out} finally takes the header file from \name{outgoing} to generate the resulting message. This data flow is shown in figure \ref{fig:queue-data-flow}.
-<< inode stuff of qmail >>
+\begin{figure}
+	\begin{center}
-<< keep it simple! >>
+		\input{input/queue-data-flow.tex}
+	\end{center}
+	\caption{Data flow of messages in the queue}
+	\label{fig:queue-data-flow}
+\end{figure}
+The queue consists of three directories within the queue path. Two, named \name{incoming} and \name{outgoing}, for storing the header files; one, called \name{pool}, to store the message bodies. The files being part of one message share the same unique name. The header files internal structure can be the same as the one of current \masqmail.
+Messages in queues are a header file in \name{incoming} or \name{outgoing} and a data file in \name{pool}. The header file owner's executable bit indicates if the file is ready for further processing: the module that writes the file into the queue sets the bit as last action. Modules that read from the queue can process messages with the bit set.
+No spool files are modified after they are written to disk. Modifications to header files can be made by the \name{scanning} module in the ``move'' from \name{incoming} to \name{outgoing}---it is a create and remove, actually. Further rewriting can happen in \name{queue-out}, as well without altering the file.
+Data files do not change at all within the system. They are written in default local plain text format. Required translation is done in the receiver and transport modules.
+%\begin{verbatim}
+%s f /          envelope data
+%p i |          NL
+%o l |       /  header lines
+%o e |  mail |  NL
+%l   \       \  mail body
+%\end{verbatim}
+A sample header file.
 \begin{verbatim}
-s f /          envelope data
+1LGtYh-0ut-00                (backup copy of the file name)
-p i |          NL
+MF:<meillo@dream>            (envelope: sender)
-o l |       /  header lines
+RT: <user@example.org>       (envelope: recipient)
-o e |  mail |  NL
+PR:local                     (meta info: protocol)
-l   \       \  mail body
+ID:meillo                    (meta info: id/user/ip)
+DS: 18                       (meta info: size)
+TR: 1230462707               (meta info: timestamp)
+(following: headers)
+HD:Received: from meillo by dream with local (masqmail 0.2.21) id
+1LGtYh-0ut-00 for <user@example.org>; Sun, 28 Dec 2008 12:11:47 +0100
+HD:To: user@example.org
+HD:Subject: test mail
+HD:From: <meillo@dream>
+HD:Date: Sun, 28 Dec 2008 12:11:47 +0100
+HD:Message-ID: <1LGtYh-0ut-00@dream>
 \end{verbatim}
 \subsection{Rights and permission}
+The user set required for \qmail\ seems to be too complex. One special user, like \postfix\ uses, is more appropriate. \name{root} privilege and \name{setuid} permission is avoided as much as possible.
+Table \ref{tab:new-masqmail-permissions} shows the suggested ownership and permissions of the modules. Figure \ref{fig:new-masqmail-queue} shows the permissions and ownership used for the queue.
+\begin{table}
+	\begin{center}
+		\input{input/new-masqmail-permissions.tex}
+	\end{center}
+	\caption{Ownership and permissions of the modules}
+	\label{tab:new-masqmail-permission}
+\end{table}
+\begin{figure}
+	\begin{center}
+		\input{input/new-masqmail-queue.tex}
+	\end{center}
+	\caption{Ownership and permissions of the queue}
+	\label{fig:new-masqmail-queue}
+\end{figure}
 setuid/setgid or not?
-how many system users?
-what permission where?
 what can crash if an attacker succeeds?
-which process runs with what rights?
 where to drop privelege?
 how is which process invoked?

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 182:e35c7962d84f