1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Fri Feb 06 21:09:21 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 11:42:45 2009 +0100
     1.3 @@ -87,7 +87,7 @@
     1.4  \index{forwarder}
     1.5  \index{non-permanent}
     1.6  
     1.7 -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 mail loss. An \MTA\ takes over responsibility for mail by 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.8 +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 mail loss. An \MTA\ takes over responsibility for mail by 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.9  \index{reliability}
    1.10  
    1.11  
    1.12 @@ -96,7 +96,7 @@
    1.13  \paragraph{\RF3: Header sanitizing}
    1.14  \label{rf3}
    1.15  \index{header sanitizing}
    1.16 -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.17 +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.18  \index{masqmail!online routes}
    1.19  
    1.20  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, all containing the same mail message.
    1.21 @@ -134,8 +134,8 @@
    1.22  This authentication based on \NAME{IP} addresses is impossible in situations where hosts with changing \NAME{IP} addresses, that are not part of a known sub net, need access. Then a authentication mechanism based on some \emph{secret} is required. Three common approaches exist:
    1.23  
    1.24  \begin{enumerate}
    1.25 -	\item \SMTP-after-\NAME{POP}: Uses authentication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards. The variant \SMTP-after-\NAME{IMAP} exists too.
    1.26 -\index{auth!smtp-after-pop}
    1.27 +	\item \SMTP-after-\NAME{POP}: Uses authentication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards. The variant \SMTP-after-\NAME{IMAP} exists, too.
    1.28 +	\index{auth!smtp-after-pop}
    1.29  	\item \SMTP\ authentication: An extension to \SMTP. It allows to request authentication before mail is accepted. Here no helper protocols are needed.
    1.30  \index{auth!smtp-auth}
    1.31  	\item Certificates: The identity of a user or a host is confirmed by certificates that are signed by trusted authorities. Certificates are closely related to encryption, they do normally satisfy both needs: encrypt the data transmission and identify the remote user/host.
    1.32 @@ -147,7 +147,7 @@
    1.33  If the \MTA\ does its job in an untrusted network, if it can be expected that forged \NAME{IP} addresses will appear, or if mobile clients need access, then dynamic authentication should be used.
    1.34  \index{untrusted environment}
    1.35  
    1.36 -Any combination is possible too. For example, it is preferred to allow relay access only to authenticated users. Either clients in local networks which are authenticated by their \NAME{IP} addresses or remote clients that authenticate by a secret-based method.
    1.37 +Any combination is possible, too. For example, it is preferred to allow relay access only to authenticated users. Either clients in local networks which are authenticated by their \NAME{IP} addresses or remote clients that authenticate by a secret-based method.
    1.38  
    1.39  Static authentication is simpler and requires less administration work but it has limitations. Dynamic authentication should be used if static authentication reaches its limits. At least one of the secret-based mechanisms should be supported.
    1.40  
    1.41 @@ -257,10 +257,10 @@
    1.42  
    1.43  \paragraph{\RG2: Reliability}
    1.44  \index{reliability}
    1.45 -Reliability is the second essential quality property for an \MTA. Mail for which the \MTA\ took responsibility must never get lost while it is within the \MTA's responsibility. The \MTA\ must not be \emph{the cause} of any mail loss, no matter what happens. Unreliable \MTA{}s are of no value. However, as the mail transport infrastructure is a distributed system, one of the communication partners or the transport medium may crash at any time during mail transfer. Thus reliability is needed for mail transfer communication too.
    1.46 +Reliability is the second essential quality property for an \MTA. Mail for which the \MTA\ took responsibility must never get lost while it is within the \MTA's responsibility. The \MTA\ must not be \emph{the cause} of any mail loss, no matter what happens. Unreliable \MTA{}s are of no value. However, as the mail transport infrastructure is a distributed system, one of the communication partners or the transport medium may crash at any time during mail transfer. Thus reliability is needed for mail transfer communication, too.
    1.47  \index{mail loss}
    1.48  
    1.49 -The goal is to transfer exactly one copy of the message. \person{Tanenbaum} evaluates the situation and comes to the conclusion that ``in general, there is no way to arrange this.'' \cite[pages~377--379]{tanenbaum02}. Only strategies where no mail gets lost are acceptable; he identifies three of them, but one generates more duplicates than the others, so two strategies remain. (1) The client always reissues the transfer. The server first sends an acknowledgment and then handles the transfer. (2) The client reissues the transfer only if no acknowledgment was received. The server first handles the transfer and sends the acknowledgment afterwards. The first strategy does not need acknowledgments at all, however, it will lose mail if the second transfer fails too.
    1.50 +The goal is to transfer exactly one copy of the message. \person{Tanenbaum} evaluates the situation and comes to the conclusion that ``in general, there is no way to arrange this.'' \cite[pages~377--379]{tanenbaum02}. Only strategies where no mail gets lost are acceptable; he identifies three of them, but one generates more duplicates than the others, so two strategies remain. (1) The client always reissues the transfer. The server first sends an acknowledgment and then handles the transfer. (2) The client reissues the transfer only if no acknowledgment was received. The server first handles the transfer and sends the acknowledgment afterwards. The first strategy does not need acknowledgments at all, however, it will lose mail if the second transfer fails, too.
    1.51  
    1.52  Hence, mail transfer between two processes should use the strategy: The client reissues if it receives no acknowledgment. The server first handles the message and then sends the acknowledgment. This strategy only leads to duplicates if a crash happens in the time between the message is fully transferred to the server and the acknowledgment is received by the client. No mail will get lost.
    1.53  \index{duplicates}
    1.54 @@ -273,7 +273,7 @@
    1.55  
    1.56  \paragraph{\RG4: Extendability}
    1.57  \index{extendability}
    1.58 -\masqmail's architecture needs to be extendable to allow new features to be added afterwards. The reasons for this need are the changing requirements. New requirements will appear, like more efficient mail transfer of large messages or a final solution for spam problem. Extendability is the ability of software to include new function with little work.
    1.59 +\masqmail's architecture needs to be extendable to allow new features to be added afterwards. The reasons for this need are the changing requirements. New requirements will appear, like more efficient mail transfer of large messages or a final solution to the spam problem. Extendability is the ability of software to include new function with little work.
    1.60  
    1.61  
    1.62  \paragraph{\RG5: Maintainability}
    1.63 @@ -405,7 +405,7 @@
    1.64  
    1.65  \paragraph{\RF6: Authentication}
    1.66  \index{auth}
    1.67 -Static authentication, based on \NAME{IP} addresses, can be achieved with \person{Venema}'s \NAME{TCP} \name{Wrapper} \cite{venema92}, by editing the \path{hosts.allow} and \path{hosts.deny} files. This is only relevant to authenticate host that try to submit mail into the system. Dynamic (secret-based) \SMTP\ authentication is already supported in form of \NAME{SMTP-AUTH} and \SMTP-after-\NAME{POP}, but only for outgoing connections. For incoming connections only address-based authentication is supported.
    1.68 +Static authentication, based on \NAME{IP} addresses, can be achieved with \person{Venema}'s \NAME{TCP} \name{Wrapper} \cite{venema92}, by editing the \path{hosts.allow} and \path{hosts.deny} files. This is only relevant to authenticate hosts that try to submit mail into the system. Dynamic (secret-based) \SMTP\ authentication is already supported in form of \NAME{SMTP-AUTH} and \SMTP-after-\NAME{POP}, but only for outgoing connections. For incoming connections only address-based authentication is supported.
    1.69  \index{auth!smtp-after-pop}
    1.70  \index{auth!smtp-auth}
    1.71  
    1.72 @@ -433,7 +433,7 @@
    1.73  \masqmail's current security is bad. However, it seems acceptable for using \masqmail\ on workstations and private networks, if the environment is trustable and \masqmail\ is protected against remote attacks. In environments where untrusted components or persons have access to \masqmail, its security is too low. Its author states that \masqmail\ ``is not designed to'' such usage \citeweb{masqmail:homepage2}. This is a clear indicator for being careful. Issues like high memory consumption, low performance, and denial-of-service attacks---things not regarded by design---may cause serious problems. In any way, a security report that confirms \masqmail's security level is missing.
    1.74  \index{masqmail!security}
    1.75  
    1.76 -\masqmail\ uses conditional compilation to exclude unneeded functionality from the executable at compile time. Excluding code means excluding all bugs and weaknesses within this code too. Excluding unused code is a good concept to improve security.
    1.77 +\masqmail\ uses conditional compilation to exclude unneeded functionality from the executable at compile time. Excluding code means excluding all bugs and weaknesses within this code, too. Excluding unused code is a good concept to improve security.
    1.78  \index{conditional compilation}
    1.79  
    1.80  \paragraph{\RG2: Reliability}
    1.81 @@ -529,7 +529,7 @@
    1.82  
    1.83  \subsubsection*{\TODO3: Security (\RG1)}
    1.84  \index{security}
    1.85 -\masqmail's security is bad, thus the program is forced into a limited field of operation. This field of operation even shrinks as security becomes more important and networking and interaction increases. Secure and trusted environment become rare, thus improving security is an important thing to do. The focus should be on adding compartments to split \masqmail\ into separate modules. (See section~\ref{sec:discussion-mta-arch}.) Further more should \masqmail's security be tested throughout to get a definitive view how good it really is and where the weak spots are.
    1.86 +\masqmail's security is bad, thus the program is forced into a limited field of operation. This field of operation even shrinks as security becomes more important and networking and interaction increases. Secure and trusted environment become rare, thus improving security is an important thing to do. The focus should be on adding compartments to split \masqmail\ into separate modules. (See section~\ref{sec:discussion-mta-arch}.) Furthermore, \masqmail's security should be tested throughout to get a definitive view how good it really is and where the weak spots are.
    1.87  \index{modularity}
    1.88  
    1.89  
    1.90 @@ -598,7 +598,7 @@
    1.91  
    1.92  This leads to the conclusion that S\,3 (A new design) is probably the best strategy for further development.
    1.93  
    1.94 -But this result respects only the view on requirements and their relevance. Other factors like development effort and risks are important to think about too. These issues are discussed in the following sections, comparing S\,3 against the combination S\,1+2.
    1.95 +But this result respects only the view on requirements and their relevance. Other factors like development effort and risks are important to think about, too. These issues are discussed in the following sections, comparing S\,3 against the combination S\,1+2.
    1.96  
    1.97  
    1.98  
    1.99 @@ -614,7 +614,7 @@
   1.100  \subsubsection*{Quality improvements}
   1.101  \index{quality improvement}
   1.102  
   1.103 -Most quality properties can hardly be added afterwards. Hence, if reliability, extendability, or maintainability shall be improved, a redesign of \masqmail\ is the best way to take. The wish to improve quality inevitably point towards a modular architecture. Modularity with internal and external interfaces is highly preferred from the architectural point of view (see section~\ref{sec:discussion-mta-arch}). The need for further features, especially ones that require changes in \masqmail's structure, support the decision for a new design, too. Hence a rewrite is favored if \masqmail\ should become a modern \MTA\ with good quality properties.
   1.104 +Most quality properties can hardly be added afterwards. Hence, if reliability, extendability, or maintainability shall be improved, a redesign of \masqmail\ is the best way to take. The wish to improve quality, inevitably point towards a modular architecture. Modularity with internal and external interfaces is highly preferred from the architectural point of view (see section~\ref{sec:discussion-mta-arch}). The need for further features, especially ones that require changes in \masqmail's structure, support the decision for a new design, too. Hence a rewrite is favored if \masqmail\ should become a modern \MTA\ with good quality properties.
   1.105  \index{modularity}
   1.106  
   1.107  
   1.108 @@ -654,7 +654,7 @@
   1.109  
   1.110  The development costs in money are not relevant for a Free Software project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by \person{Oliver Kurth} within four years in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer not as an employee with eight work-hours per day.
   1.111  
   1.112 -Given the assumptions that (1) an equal amount of code needs to be produced for a new designed \masqmail, (2) a third of the existing code can be reused plus concepts and knowledge, and (3) development speed is like \person{Kurth}'s, then it would take between two and three years for one programmer to produce a redesigned new \masqmail\ with the same features that \masqmail\ now has. Less time would be needed if a simpler architecture allows faster development, better testing, and less bugs. Of course more developers would speed it up too.
   1.113 +Given the assumptions that (1) an equal amount of code needs to be produced for a new designed \masqmail, (2) a third of the existing code can be reused plus concepts and knowledge, and (3) development speed is like \person{Kurth}'s, then it would take between two and three years for one programmer to produce a redesigned new \masqmail\ with the same features that \masqmail\ now has. Less time would be needed if a simpler architecture allows faster development, better testing, and less bugs. Of course, more developers would speed it up, too.
   1.114  
   1.115  
   1.116  
   1.117 @@ -691,7 +691,7 @@
   1.118  \subsubsection*{Repairing}
   1.119  \index{reparing}
   1.120  
   1.121 -Besides these advantages of existing code, one must not forget that further work on it is often repair work. Small bug fixes are not the problem, but adding something for which the software originally was not designed will cause problems. Such work often destroys the clear concepts of the software, especially in interweaved monolithic code.
   1.122 +Besides these advantages of existing code, one must not forget that further work on it is often repair work. Small bug fixes are not the problem, but adding something for which the software originally was not designed, will cause problems. Such work often destroys the clear concepts of the software, especially in interweaved monolithic code.
   1.123  
   1.124  \person{Doug McIlroy}, a person with important influence on Unix especially by inventing the Unix pipe, demands: ``To do a new job, build afresh rather than complicate old programs by adding new features.'' \cite{mcilroy78}.
   1.125  
   1.126 @@ -702,7 +702,7 @@
   1.127  
   1.128  %Clinging to much to existing code will be no help, it is an indicator for fear. Having the courage to through bad code away to make it better, shows the view forward.
   1.129  
   1.130 -Anyway, further development on base of current code needs to improve the quality properties too. Some quality requirements can be satisfied by adding wrappers or interposition filters to the outside. For those is the development effort approximately equal to a solution with a new design. But for adding quality requirements like extendability or maintainability which affect the source code throughout, the effort does increase with exponential rate as development proceeds. In case these properties get not improved, development will likely come to a dead end sooner or later.
   1.131 +Anyway, further development on base of current code needs to improve the quality properties, too. Some quality requirements can be satisfied by adding wrappers or interposition filters to the outside. For those is the development effort approximately equal to a solution with a new design. But for adding quality requirements like extendability or maintainability which affect the source code throughout, the effort does increase with exponential rate as development proceeds. In case these properties get not improved, development will likely come to a dead end sooner or later.
   1.132  \index{quality improvement}
   1.133  
   1.134  
   1.135 @@ -730,7 +730,7 @@
   1.136  \subsubsection*{Modularity}
   1.137  \index{modularity}
   1.138  
   1.139 -The avoidance of dead ends is essential for further development on current code too. Hence it is mandatory to refactor the existing code base sooner or later. Most important is the intention to modularize it, as modularity improves many quality properties, eases further development, and essentially improves security.
   1.140 +The avoidance of dead ends is essential for further development on current code, too. Hence it is mandatory to refactor the existing code base sooner or later. Most important is the intention to modularize it, as modularity improves many quality properties, eases further development, and essentially improves security.
   1.141  
   1.142  One example how modular structure makes it easy to add further functionality is described by \person{Sill}: He says that integrating the \name{amavis} filter framework into the \qmail\ system can be done by simply renaming the \path{qmail-queue} module to \path{qmail-queue-real} and renaming the \path{amavis} executable to \path{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable ability which is only possible in a modular system that consists of independent executables.
   1.143  \index{modularity}