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

comparison thesis/tex/4-MasqmailsFuture.tex @ 178:b426a663d5f0

wrote about modules and queues

author	meillo@marmaro.de
date	Sat, 27 Dec 2008 12:37:27 +0100
parents	7781ad0811f7
children	d75bd7a72d8b

comparison

equal deleted inserted replaced

-:7781ad0811f7
+:b426a663d5f0
 One key feature of \masqmail\ is its ability to send mail out in different ways. The decision is based on the current online state and whether a route may be used for a message or not. The online state can be retrieved in tree ways, explained in \ref{sec:fixme}. A route to send is found by checking every available route for being able to transfer the current message, until one matches.
 This functionality should be implemented in the module that is responsible to invoke one of the outgoing channel modules (for example the one for \SMTP\ or the pipe module).
 \masqmail\ can rewrite the envelope's from address and the \texttt{From:} header, dependent on the outgoing route to use. This rewrite must be done \emph{after} it is clear which route a mail will take, of course, so this may be not the module where other header editing is done.
+%fixme: see hafiz05 page 57: maybe put the rewriting into the sending module (like smx, exim, courier) (problem with archiving of all outgoing mail?)
 \subsubsection*{Aliasing}
 	\item arbitrary protocol handlers have to be addable afterwards
 	\item a single facility for scanning (all mail goes through it)
 	\item concentrate on mail transfer
 \end{itemize}
-The result is a symetric design, featuring any number of handlers for incoming connections to receive mail and pass it to the module that stores it into the incoming queue. A central scanning module take mail from the incoming queue, processes it in various ways and puts it afterwards into the outgoing queue. Another module takes it out there and passes it to a matching transport module that transfers it to the destination. In other words, three main modules (queue-in, scanning, queue-out) are connected by the two queues (incoming, outgoing); on each end are more modules to receive and send mail---for each protocol one. Figure \ref{fig:masqmail-arch-new} depicts the new designed architecture.
+The result is a symetric design, featuring the following parts: Any number of handlers for incoming connections to receive mail and pass it to the module that stores it into the incoming queue. A central scanning module take mail from the incoming queue, processes it in various ways and puts it afterwards into the outgoing queue. Another module takes it out there and passes it to a matching transport module that transfers it to the destination. In other words, three main modules (queue-in, scanning, queue-out) are connected by the two queues (incoming, outgoing); on each end are more modules to receive and send mail---for each protocol one. Figure \ref{fig:masqmail-arch-new} depicts the new designed architecture.
 \begin{figure}
 	\begin{center}
 		\input{input/masqmail-arch-new.tex}
 	\end{center}
 	\caption{A new designed architecture for \masqmail}
 	\label{fig:masqmail-arch-new}
 \end{figure}
+This architecture is heavily influenced by the ones of \qmail\ and \postfix. Both have different incoming channels that merge in the module that puts mail into the queue; central is the queue (or more of them); and one module takes mail from the queue and passes it to one of the outgoing channels. Mail processing, in any way, is build in in a more explicit way than done in the other two. It is more similar to the \NAME{AR} module of \name{sendmail X}, which is the central point for spam checking.
+Special regard was put on addable support for further mail transfer protocols. This appears to be most similar to \qmail, which was designed to handle multiple protocols.
+%fixme: do i need all this ``quesses''??
 \subsection{Modules and queues}
-\subsubsection*{queue-in}
+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.
-\subsubsection*{scanning}
-\subsubsection*{queue-out}
+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.
-\subsubsection*{incoming queue}
-\subsubsection*{outgoing queue}
+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.
-\subsubsection*{receiver modules}
-\subsubsection*{transport modules}
+The \name{queue-out} module takes messages from the \name{outgoing} queue, queries information about the online connection, and then selects matching routes, creates envelopes for each recipient and passes the messages to the correct transport module. Successfully transfered messages are removed from the \name{outgoing} queue. This module includes some tasks specific to \masqmail.
+The \name{incoming} queue stores messages received via one of the incoming channels. The messages are in unprocessed form; only envelope data is prepended.
+The \name{outgoing} queue contains processed messages. The header and envelope information is complete and in valid form.
+\name{Receiver modules} are the communication interface between outside senders and the \name{queue-in} module. Each protocol needs a corresponding \name{receiver module} to be supported. Most popular are the \name{sendmail} module (which is a command to be called from the local host) and the \name{smtpd} module (which listens on port 25). Other modules to support other protocols may be added as needed.
+\name{Transport modules}, on the oppersite side of the system, are the modules to send outgoing mail; they are the interface between \name{queue-out} and remote hosts or local commands for further processing. The most popular ones are the \name{smtp} module (which acts as the \SMTP\ client) and the \name{pipe} module (to interface gateways to other systems or networks, like fax or uucp). A module for local delivery is not included, as it is in most other \MTA{}s; the reasons are described in FIXME.%fixme
+Thus a \name{mail delivery agent} (like \name{procmail}) is to be used with the \name{pipe} module.
 \subsection{Intermodule communication}

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 178:b426a663d5f0