1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Mon Jan 26 13:35:01 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Mon Jan 26 13:36:18 2009 +0100
     1.3 @@ -1,4 +1,5 @@
     1.4  \chapter{\masqmail's present and future}
     1.5 +\label{chap:present-and-future}
     1.6  
     1.7  This chapter identifies requirements for \masqmail\ which are compared against the current code to see what is already fulfilled and what is missing. Then the outstanding work is ordered by relevance and a list of tasks to do is created. The end of this chapter is the evaluation of the best development strategy to get the work done in order to achieve the requirements.
     1.8  
     1.9 @@ -38,6 +39,7 @@
    1.10  
    1.11  
    1.12  \paragraph{\RF1: Incoming and outgoing channels}
    1.13 +\label{rf1}
    1.14  \sendmail-compatible \mta{}s must support at least two incoming channels: mail submitted using the \sendmail\ command, and mail received on a \NAME{TCP} port. Thus it is common to split the incoming channels into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view \cite{hafiz05}.
    1.15  
    1.16  \SMTP\ is the primary mail transport protocol today, but with the increasing need for new protocols (see section \ref{sec:what-will-be-important}) in mind, support for more than just \SMTP\ is good to have. New protocols will show up, maybe multiple protocols need to be supported then. This leads to multiple remote channels, one for each supported protocol as it was done in other \MTA{}s. Best would be interfaces to add further protocols as modules.
    1.17 @@ -66,6 +68,7 @@
    1.18  
    1.19  
    1.20  \paragraph{\RF2: Mail queuing}
    1.21 +\label{rf2}
    1.22  Mail queuing removes the need to deliver instantly as a message is received. The queue provides fail-safe storage of mails until they are delivered. Mail queues are probably used in all \mta{}s, even in some simple forwarders. The mail queue is essential for \masqmail, as \masqmail\ is used for non-permanent online connections. This means, mail must be queued until a online connection is available to send the message. This may be after a reboot. Hence the mail queue must provide persistence.
    1.23  
    1.24  The mail queue and the module(s) to manage it are the central part of the whole system. This demands especially for robustness and reliability, as a failure here can lead to loosing mail. An \MTA\ takes over responsibility for mail in accepting it, hence loosing mail messages is absolutely to avoid. This covers any kind of crash situation too. The worst thing acceptable to happen is an already sent mail to be sent again.
    1.25 @@ -74,6 +77,7 @@
    1.26  
    1.27  
    1.28  \paragraph{\RF3: Header sanitizing}
    1.29 +\label{rf3}
    1.30  Mail coming into the system often lacks important header lines. At least the required ones must be added by the \MTA. One example is the \texttt{Date:} header, another is the, not required but recommended, \texttt{Message-ID:} header. Apart from adding missing headers, rewriting headers is important too. Changing the locally known domain part of email addresses to globally known ones is an example. \masqmail\ needs to be able to rewrite the domain part dependent on the route used to send the message, to prevent messages to get classified as spam.
    1.31  
    1.32  Generating the envelope is a related job. The envelope specifies the actual recipient of the mail, no matter what the \texttt{To:}, \texttt{Cc:}, and \texttt{Bcc:} headers contain. Multiple recipients lead to multiple different envelopes, containing all the same mail message.
    1.33 @@ -82,18 +86,21 @@
    1.34  
    1.35  
    1.36  \paragraph{\RF4: Aliasing}
    1.37 +\label{rf4}
    1.38  Email addresses can have aliases, thus they need to be expanded. Aliases can be of different kind: another local user, a remote user, a list containing local and remote users, or a command. Most important are the aliases in the \path{aliases} file, usually located at \path{/etc/aliases}. Addresses expanding to lists of users lead to more envelopes. Aliases changing the recipient's domain part may require a different route to be used.
    1.39  
    1.40  
    1.41  
    1.42  
    1.43  \paragraph{\RF5: Route management}
    1.44 +\label{rf5}
    1.45  One key feature of \masqmail\ is its ability to send mail out over different routes. The online state defines the active route to be used. A specific route may not be suited for all messages, thus these messages are hold back until a suiting route is active. For more information on this concept see section \ref{sec:masqmail-routes}.
    1.46  
    1.47  
    1.48  
    1.49  
    1.50  \paragraph{\RF6: Authentication}
    1.51 +\label{rf6}
    1.52  \label{requirement-authentication}
    1.53  One thing to avoid is being an \name{open relay}. Open relays allow to relay mail from everywhere to everywhere. This is a source of spam. The solution is restricting relay\footnote{Relaying is passing mail, that is not from and not for the own system, through it.} access. It may also be wanted to refuse all connections to the \MTA\ except ones from a specific set of hosts.
    1.54  
    1.55 @@ -118,6 +125,7 @@
    1.56  
    1.57  
    1.58  \paragraph{\RF7: Encryption}
    1.59 +\label{rf7}
    1.60  \label{requirement-encryption}
    1.61  Electronic mail is vulnerable to sniffing attacks, because in generic \SMTP\ all data transfer is unencrypted. The message's body, the header, and envelope are all unencrypted, but also authentication dialogs that transfer plain text passwords (e.g.\ \NAME{PLAIN} and \NAME{LOGIN}). Hence encryption is throughout important.
    1.62  
    1.63 @@ -140,6 +148,7 @@
    1.64  
    1.65  
    1.66  \paragraph{\RF8: Spam handling}
    1.67 +\label{rf8}
    1.68  Spam is a major threat nowadays, but it is a war that is hard to win. The goal is to provide state-of-the-art spam protection, but not more (see section \ref{sec:swot-analysis}).
    1.69  
    1.70  As spam is, by increasing the amount of mail messages, not just a nuisance for end users, but also for the infrastructure---the \mta{}s---they need to protect themselves.
    1.71 @@ -157,6 +166,7 @@
    1.72  
    1.73  
    1.74  \paragraph{\RF9: Malware handling}
    1.75 +\label{rf9}
    1.76  Related to spam is malicious content (short: \name{malware}) like viruses, worms, trojan horses. They, in contrast to spam, do not affect the \MTA\ itself, as they are in the mail's body. \MTA{}s searching for malware is equal to real world's post offices opening letters to check if they contain something that could harm the recipient. This is not a mail transport job. But by many people the \MTA\ which is responsible for the recipient is seen to be at a good position to do this work, so it is often done there.
    1.77  
    1.78  In any way should malware checking be performed by external programs that may be invoked by the \mta. But \NAME{MDA}s are better points to invoke content scanners.
    1.79 @@ -166,9 +176,8 @@
    1.80  
    1.81  
    1.82  \paragraph{\RF10: Archiving}
    1.83 -Mail archiving and auditability become more important as email establishes as technology for serious business communication. It is also a must for companies in many countries.
    1.84 -
    1.85 -<< \textbf{SOX} >> %fixme: cite SOX
    1.86 +\label{rf10}
    1.87 +Mail archiving and auditability become more important as email establishes as technology for serious business communication. It is also a must for companies in many countries. In the United States, the \name{Sarbanes-Oxley Act} \cite{sox} covers this topic. But a dedicated archiving solution is advisable if archiving is of high importance.
    1.88  
    1.89  The ability to archive verbatim copies of every mail coming into and every mail going out of the system, with relation between them, appears to be a goal to achieve.
    1.90  
    1.91 @@ -248,16 +257,15 @@
    1.92  \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
    1.93  
    1.94  Figure \ref{fig:masqmail-arch} is a call graph generated from \masqmail's source code, excluding logging functions. It gives a impression of how interweaved the internals are. There are no compartments existent.
    1.95 -%fixme: what is included, what not?
    1.96  
    1.97  \begin{figure}
    1.98  	\begin{center}
    1.99  		\vspace*{2ex}
   1.100  		%\includegraphics[scale=0.75]{img/callgraph.eps}
   1.101 -		\includegraphics[scale=0.75]{img/masqmail-3-omitlog5.eps}
   1.102 +		%\includegraphics[scale=0.75]{img/masqmail-3-omitlog5.eps}
   1.103 +		\includegraphics[scale=0.75]{img/bb.eps}
   1.104  	\end{center}
   1.105 -	\caption{Internal structure of \masqmail, showed by a call graph. (Logging functions are excluded.)}
   1.106 -	%fixme: what else is excluded
   1.107 +	\caption{Internal structure of \masqmail, showed by a call graph. (Logging functions are ignored; test and \NAME{POP3} code is excluded.)}
   1.108  	\label{fig:masqmail-arch}
   1.109  \end{figure}
   1.110  
   1.111 @@ -297,13 +305,11 @@
   1.112  \paragraph{\RF1: In/out channels}
   1.113  The incoming and outgoing channels that \masqmail\ already has (depicted in figure \ref{fig:masqmail-channels} on page \pageref{fig:masqmail-channels}) are the ones required for an \MTA{}s at the moment. Support for other protocols seems not to be necessary at the moment, although new protocols and mailing concepts are likely to appear (see section \ref{sec:email-trends}). Today, other protocols are not needed, so \masqmail\ is regarded to fulfill \RF1. But as \masqmail\ has no support for adding further protocols, delaying the work to support them until they are widely used, appears to be the best strategy anyway.
   1.114  
   1.115 -<< smtp submission >> %fixme
   1.116 +%fixme: << smtp submission >> %fixme
   1.117  
   1.118  \paragraph{\RF2: Queuing}
   1.119  One single mail queue is used in \masqmail; it satisfies all current requirements.
   1.120  
   1.121 -<< persistence: DB >> %fixme
   1.122 -
   1.123  \paragraph{\RF3: Header sanitizing}
   1.124  The envelope and mail headers are generated when the mail is put into the queue. The requirements are fulfilled.
   1.125  
   1.126 @@ -358,10 +364,11 @@
   1.127  
   1.128  
   1.129  \paragraph{\RG6: Testability}
   1.130 -The testability suffers from missing modularity. Testing program parts is hard to do. Nevertheless, it is done by compiling parts of the source to special test programs. %fixme: what are the names? what do they test?
   1.131 +The testability suffers from missing modularity. Testing program parts is hard to do. Nevertheless, it is done by compiling parts of the source to two special test programs: One tests reading input from a socket, the other tests constructing messages and sending it directly. Neither is designed for automated testing of source parts, they are rather to help the programmer during development.
   1.132  
   1.133 -This kind of testing is only clean-room testing, so .... %fixme
   1.134 - % XXX
   1.135 +Two additional scripts exist to send a set of mails to differend kinds of recipients. They can be used for automated testing, but both test only the complete system's function.
   1.136 +
   1.137 +%fixme: think about clean-room testing
   1.138  
   1.139  \paragraph{\RG7: Performance}
   1.140  The performance---efficiency---of \masqmail\ is good enough for its target field of operation, where this is a minor goal.