1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Fri Dec 26 22:38:07 2008 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Dec 27 12:37:27 2008 +0100
     1.3 @@ -198,6 +198,7 @@
     1.4  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).
     1.5  
     1.6  \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.
     1.7 +%fixme: see hafiz05 page 57: maybe put the rewriting into the sending module (like smx, exim, courier) (problem with archiving of all outgoing mail?)
     1.8  
     1.9  
    1.10  
    1.11 @@ -390,7 +391,7 @@
    1.12  	\item concentrate on mail transfer
    1.13  \end{itemize}
    1.14  
    1.15 -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.
    1.16 +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.
    1.17  
    1.18  \begin{figure}
    1.19  	\begin{center}
    1.20 @@ -400,19 +401,35 @@
    1.21  	\label{fig:masqmail-arch-new}
    1.22  \end{figure}
    1.23  
    1.24 +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.
    1.25 +
    1.26 +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.
    1.27 +%fixme: do i need all this ``quesses''??
    1.28  
    1.29  
    1.30  \subsection{Modules and queues}
    1.31  
    1.32 -\subsubsection*{queue-in}
    1.33 -\subsubsection*{scanning}
    1.34 -\subsubsection*{queue-out}
    1.35 +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.
    1.36  
    1.37 -\subsubsection*{incoming queue}
    1.38 -\subsubsection*{outgoing queue}
    1.39  
    1.40 -\subsubsection*{receiver modules}
    1.41 -\subsubsection*{transport modules}
    1.42 +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.
    1.43 +
    1.44 +
    1.45 +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.
    1.46 +
    1.47 +
    1.48 +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.
    1.49 +
    1.50 +
    1.51 +The \name{incoming} queue stores messages received via one of the incoming channels. The messages are in unprocessed form; only envelope data is prepended.
    1.52 +
    1.53 +
    1.54 +The \name{outgoing} queue contains processed messages. The header and envelope information is complete and in valid form.
    1.55 +
    1.56 +\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.
    1.57 +
    1.58 +\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
    1.59 +Thus a \name{mail delivery agent} (like \name{procmail}) is to be used with the \name{pipe} module.
    1.60  
    1.61  
    1.62