1.1 --- a/thesis/tbl/requirements.tbl	Fri Jan 16 10:35:48 2009 +0100
     1.2 +++ b/thesis/tbl/requirements.tbl	Fri Jan 16 14:51:08 2009 +0100
     1.3 @@ -9,7 +9,7 @@
     1.4  	\RF5: Route management   & + & - & 0 \\
     1.5  	\RF6: Authentication     & ++ & + & +++ \\
     1.6  	\RF7: Encryption         & ++ & + & +++ \\
     1.7 -	\RF8: Spam prevention    & + & ++ & +++ \\
     1.8 +	\RF8: Spam handling      & + & ++ & +++ \\
     1.9  	\RF9: Malware handling   & - & + & 0 \\
    1.10  	\RF10: Archiving         & - & + & 0 \\
    1.11  	\hline

     2.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Fri Jan 16 10:35:48 2009 +0100
     2.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Fri Jan 16 14:51:08 2009 +0100
     2.3 @@ -108,11 +108,11 @@
     2.4  
     2.5  
     2.6  \paragraph{\RF7: Encryption}
     2.7 -Electronic mail is vulnerable to sniffing attacks, because in generic \SMTP\ all data transfer is unencrypted. Unencrypted is the message's content, the email addresses in header and envelope, but also authentication dialogs that transfer plain text passwords (e.g.\ \NAME{PLAIN} and \NAME{LOGIN}). Hence encryption is important.
     2.8 +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.
     2.9  
    2.10 -The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \TLS, successor of \NAME{SSL}). \TLS\ encrypts the datagrams of the \name{transport layer}. This means it works below the application protocols and can be used by any of them \citeweb{wikipedia:tls}.
    2.11 +The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \TLS, the successor of \NAME{SSL}). \TLS\ encrypts the datagrams of the \name{transport layer}. This means it works below the application protocols and can be used with any of them \citeweb{wikipedia:tls}.
    2.12  
    2.13 -Using secure tunnels, that are provided by external applications, is prefered because the \MTA\ needs not to bother with encryption then. Outgoing \SMTP\ connections can get encrypted using a secure tunnel, created by an external application (like \name{openssl}). But incoming connections can not use external secure tunnels, because the remote \NAME{IP} address is hidden then; all connections appear to come from localhost instead. Figure \ref{fig:stunnel} depicts the situation of using an application like \name{stunnel} for incoming connections. The connection to port 25 comes from localhost, and that is the information the \MTA\ gets. Authentication based on \NAME{IP} addresses and many spam prevention methods are useless then.
    2.14 +Using secure tunnels that are provided by external programs, should be prefered over including encryption into the application, because the application needs not to bother with encryption then. Outgoing \SMTP\ connections can get encrypted using a secure tunnel, created by an external application (like \name{openssl}). But incoming connections can not use external secure tunnels, because the remote \NAME{IP} address is hidden then; all connections would appear to come from localhost instead. Figure \ref{fig:stunnel} depicts the situation of using an application like \name{stunnel} for incoming connections. The connection to port 25 comes from localhost and this information reaches the \MTA. Authentication based on \NAME{IP} addresses and many spam prevention methods are useless then.
    2.15  
    2.16  \begin{figure}
    2.17  	\begin{center}
    2.18 @@ -122,22 +122,22 @@
    2.19  	\label{fig:stunnel}
    2.20  \end{figure}
    2.21  
    2.22 -To provide encrypted incoming channels, the \MTA\ could implement encryption and listen on a port that is dedicated to encrypted \SMTP\ (\NAME{SMTPS}). This approach would be possible, but it is deprecated in favor for \NAME{STARTTLS}. \RFC3207 ``\SMTP\ Service Extension for Secure \SMTP\ over Transport Layer Security'' shows this in not mentioning \NAME{SMTPS} on port 465. Also port 465 is not even reserved for \NAME{SMTPS} anymore \citeweb{iana:port-numbers}.
    2.23 +To provide encrypted incoming channels, the \MTA\ could implement encryption and listen on a port that is dedicated to encrypted \SMTP\ (\NAME{SMTPS}). This approach would be possible, but it is deprecated in favor for \NAME{STARTTLS}. \RFC3207 ``\SMTP\ Service Extension for Secure \SMTP\ over Transport Layer Security'' shows this by not mentioning \NAME{SMTPS} on port 465. Also port 465 is not even reserved for \NAME{SMTPS} anymore \citeweb{iana:port-numbers}.
    2.24  
    2.25 -\NAME{STARTTLS}---defined in \RFC2487---is what \RFC3207 recommends to use for secure \SMTP. The connection then goes over port 25 (or the submission port 587), but gets encrypted as the \NAME{STARTTLS} keyword is issued.
    2.26 +\NAME{STARTTLS}---defined in \RFC2487---is what \RFC3207 recommends to use for secure \SMTP. The connection then goes over port 25 (or the submission port 587), but gets encrypted as the \NAME{STARTTLS} keyword is issued. Email depends on compatibility---only encryption methods that client and server support can be used. Hence it is best to act after the recommendations of the \RFC\ documents. This means \NAME{STARTTLS} encryption should be supported for incoming and for outgoing connections.
    2.27  
    2.28 -\NAME{STARTTLS} encryption should be supported.
    2.29  
    2.30  
    2.31 -
    2.32 -\paragraph{\RF8: Spam prevention}
    2.33 +\paragraph{\RF8: Spam handling}
    2.34  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}).
    2.35  
    2.36 -As spam is not just a nuisance for end users, but also for the infrastructure---the \mta{}s---by increasing the amount of mail messages, \MTA{}s need to protect themselves.
    2.37 +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.
    2.38  
    2.39 -Filtering spam can be done in two ways: Refusing spam during the \SMTP\ dialog or checking for spam after the mail was accepted and queued. Both ways have advantages and disadvantages, so modern \MTA{}s use them in combination. Spam is identified by the results of a set of checks. Static rules, querying databases (\NAME{DNS} blacklists \cite{cole07} \cite{levine08}), requesting special client behavior (\name{greylisting} \cite{harris03}, \name{hashcash} \cite{back02}), or statistical analysis (\name{bayesian filters} \cite{graham02}) are checks that may be used. Running more checks leads to better results, but takes more system resources and more time.
    2.40 +Filtering spam can be done by either refusing spam during the \SMTP\ dialog or by checking for spam after the mail was accepted and queued. Both ways have advantages and disadvantages, so modern \MTA{}s use them in combination.
    2.41  
    2.42 -Doing some basic checks during the \SMTP\ dialog seems to be a must \cite[page~25]{eisentraut05}. They should best be included into the \MTA, because they need to be fast to avoid \SMTP\ dialog timeouts. Internal interfaces to specialized modules seem to be best.
    2.43 +Spam is identified by the results of a set of checks. Static rules, querying databases (\NAME{DNS} blacklists \cite{cole07} \cite{levine08}), requesting special client behavior (\name{greylisting} \cite{harris03}, \name{hashcash} \cite{back02}), or statistical analysis (\name{bayesian filters} \cite{graham02}) are checks that may be used. Running more checks leads to better results, but takes more system resources and more time.
    2.44 +
    2.45 +Doing some basic checks during the \SMTP\ dialog seems to be a must \cite[page~25]{eisentraut05}. Including them into the \MTA\ makes them fast to avoid \SMTP\ dialog timeouts. For modularity and reusability reasons internal interfaces to specialized modules seem to be best.
    2.46  
    2.47  More detailed checks after the message is queued should be done using external scanners. Interfaces to invoke them need to be defined. (See also the remarks about \name{amavis} in the next section.)
    2.48  
    2.49 @@ -146,20 +146,18 @@
    2.50  
    2.51  
    2.52  \paragraph{\RF9: Malware handling}
    2.53 -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 the \MTA\ responsible for the recipient seems to be at a good position to do this work, so it is often done there.
    2.54 +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.
    2.55  
    2.56 -In any way should malware checking be performed by external programs that may be invoked by the \mta. But using mail deliver agents, like \name{procmail}, are better suited locations to invoke content scanners.
    2.57 +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.
    2.58  
    2.59 -A popular email filter framework is \name{amavis} which integrates various spam and malware scanners. The common setup includes a receiving \MTA\ which sends it to \name{amavis} using \SMTP, \name{amavis} processes the mail and sends it then to a second \MTA\ that does the outgoing transfer. Having interfaces to such scanners is nice to have, though.
    2.60 +A popular email filter framework is \name{amavis} which integrates various spam and malware scanners. The common setup includes a receiving \MTA\ which sends it to \name{amavis} using \SMTP, \name{amavis} processes the mail and sends it then to a second \MTA\ that does the outgoing transfer. Having interfaces to such scanners is nice to have, though. (This setup with two \MTA\ instances is discussed in more detail in section \ref{sec:double-mta-setup}).
    2.61  
    2.62  
    2.63  
    2.64  \paragraph{\RF10: Archiving}
    2.65  Mail archiving and auditability become more important as email establishes as technology for serious business communication. 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.
    2.66  
    2.67 -\postfix\ for example has a \texttt{always\_bcc} feature, to send a copy of every outgoing mail to a definable recipient. At least this functionality should be given, although a more complete approach is preferable.
    2.68 -
    2.69 -\qmail\ is able to save copies of all sent and received messages and additionally complete \SMTP\ dialogs \cite[page~12]{sill02}.
    2.70 +\postfix\ for example has a \texttt{always\_bcc} feature, to send a copy of every outgoing mail to a definable recipient. At least this functionality should be given, although a more complete approach, like \qmail\ provides, is preferable. \qmail\ is able to save copies of all sent and received messages and additionally complete \SMTP\ dialogs \cite[page~12]{sill02}.
    2.71  
    2.72  << refer to SOX >> %fixme
    2.73  
    2.74 @@ -176,8 +174,6 @@
    2.75  \paragraph{\RG1: Security}
    2.76  \MTA{}s are critical points for computer security, as they are accessible from external networks. They must be secured with high effort. Properties like the need for high privilege level, from outside influenced work load, work on unsafe data, and demand for reliability, increase the need for security. This is best done by modularization, also called \name{compartementalization}, as described in section \ref{sec:discussion-mta-arch}. \masqmail\ needs to be secure enough for its target field of operation. \masqmail\ is targeted to workstations and private networks, with explicit warning to not use it on permanent online hosts \citeweb{masqmail:homepage2}. But as non-permanent online connections and trustable environments become rare, \masqmail's security should be so good, that it is usable with permanent online connections and in unsafe environments. For example should mails with bad content not break \masqmail.
    2.77  
    2.78 -<< conditional compilation >>
    2.79 -
    2.80  
    2.81  \paragraph{\RG2: Reliability}
    2.82  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 are distributed systems, one of the communication partners or the transport medium may crash at any time during mail tranfer. Thus reliability is needed for mail transfer communication too.
    2.83 @@ -186,9 +182,6 @@
    2.84  
    2.85  Hence, mail transfer between two processes must use the strategy: The client reissues if it receives no acknowledgement; the server first handles the message and then sends the acknowledgement. This strategy only leads to duplicates if a crash happens in the time between the message is fully transfered to the server and the acknowlegement is received by the client. No mail will get lost.
    2.86  
    2.87 -<< DB as queue >>
    2.88 -
    2.89 -<< exactly one copy of a message at one time >>
    2.90  
    2.91  \paragraph{\RG3: Robustness}
    2.92  Being robust means handling errors properly. Small errors may get corrected, large errors may kill a process. Killed processes should restarted automatically and lead to a clean state again. Log messages should be written in every case. Robust software does not need a special environment, it creates a friendly environment itself. \person{Raymond}'s \name{Rule of Robustness} and his \name{Rule of Repair} are good descriptions \cite[pages~18--21]{raymond03}.
    2.93 @@ -201,8 +194,6 @@
    2.94  \paragraph{\RG5: Maintainability}
    2.95  Maintaining software takes much time and effort. \person{Spinellis} guesses ``40\,\% to 70\,\% of the effort that goes into a software system is expended after the system is written first time.'' \cite[page~1]{spinellis03}. This work is called \emph{maintaining}. Hence making software good to maintain will ease work afterwards.
    2.96  
    2.97 -<< conditional compilation >>
    2.98 -
    2.99  
   2.100  \paragraph{\RG6: Testability}
   2.101  Good testability make maintenance easier too, because functionality is directly verifiable when changes are done, thus removing uncertainty. Modularized software makes testing easier, because parts can be tested without external influences. \person{Spinellis} sees testability as a sub-quality of maintainability.
   2.102 @@ -269,6 +260,12 @@
   2.103  
   2.104  
   2.105  
   2.106 +
   2.107 +
   2.108 +
   2.109 +
   2.110 +
   2.111 +
   2.112  \section{Fulfilled requirements}
   2.113  \label{sec:fulfilled-requirements}
   2.114  
   2.115 @@ -278,12 +275,12 @@
   2.116  \paragraph{\RF1: In/out channels}
   2.117  \masqmail's incoming and outgoing channels are the ones required for an \MTA{}s at the moment. They are depicted in figure \ref{fig:masqmail-in-out} on page \pageref{fig:masqmail-in-out}. This is all what is currently needed. But new protocols and mailing concepts are likely to appear (see section \ref{sec:electronic-mail}). \masqmail\ has no support for adding further protocols. Thus modifications at many places in the source are needed to add them though. Today, support for further protocols is not needed, so \masqmail\ is regarded to fulfill \RF1, but the probable future need should be kept in mind.
   2.118  
   2.119 -<< smtp submission >>
   2.120 +<< smtp submission >> %fixme
   2.121  
   2.122  \paragraph{\RF2: Queueing}
   2.123  One single mail queue is used in \masqmail; it satisfies all current requirements.
   2.124  
   2.125 -<< persistence: DB >>
   2.126 +<< persistence: DB >> %fixme
   2.127  
   2.128  \paragraph{\RF3: Header sanitizing}
   2.129  The envelope and mail headers are generated when the mail is put into the queue. The requirements are fulfilled.
   2.130 @@ -310,13 +307,12 @@
   2.131  There is currently no way of archiving every message going through \masqmail.
   2.132  
   2.133  
   2.134 -%Non-functional requirements are not so easy to be marked as fulfilled or not. Instead they are discussed here.
   2.135  
   2.136  \paragraph{\RG1: Security}
   2.137  \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 attackers. In environments where untrusted components or persons have access to \masqmail, its security is too low.
   2.138  Its author states it ``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, is a security report missing that confirms \masqmail's security level.
   2.139  
   2.140 -<< conditional compilation >>
   2.141 +\masqmail\ uses conditional compilation to exclude unneeded functionality from the executable at complile time. Excluding code means excluding all bugs and weaknesses within this code too. This improves security.
   2.142  
   2.143  \paragraph{\RG2: Reliability}
   2.144  Similar is its reliability not good enough. Situations where only one part of sent message was removed from the queue, and the other part remained as garbage, showed off \citeweb{debian:bug245882}. Problems with large mail and small bandwidth were also reported \citeweb{debian:bug216226}. Fortunately, lost email was no big problem yet, but \person{Kurth} warns:
   2.145 @@ -327,7 +323,7 @@
   2.146  In summary: Current reliability needs to be improved.
   2.147  %fixme: state machine
   2.148  
   2.149 -<< persistence: db >>
   2.150 +\masqmail\ uses the filesytem to store the queue, storing the queue in a databases might improve the reliability through better persistence. %fixme
   2.151  
   2.152  \paragraph{\RG3: Robustness}
   2.153  The logging behavior of \masqmail\ is good, although it does not cover all problem situations. For example, if the queue directory is world writeable by accident (or as action of an intruder), any user can remove messages from the queue or replace them with own ones. \masqmail\ does not even write a debug message in this case. The origin of this problem, however, is \masqmail's trust in its environment.
   2.154 @@ -336,9 +332,9 @@
   2.155  \masqmail's extendability is very poor. This is a general problem of monolithic software, but can thus be provided with high effort. \exim\ is an example for good extendability in a monolithic program.
   2.156  
   2.157  \paragraph{\RG5: Maintainability}
   2.158 -The maintainability of \masqmail\ is equivalent to other software of similar kind. Missing modularity and therefore more complexity makes the maintainer's work harder. In summary is \masqmail's maintainability bearable, like in average Free Software projects.
   2.159 +The maintainability of \masqmail\ is equivalent to other software of similar kind. Missing modularity and therefore more complexity makes the maintainer's work harder. Conditional compilation might be good for security, but \name{ifdef}s scattered throughout the source code is a pain for maintainability. In summary is \masqmail's maintainability bearable, like in average Free Software projects.
   2.160  
   2.161 -<< conditional compilation >>
   2.162 +
   2.163  
   2.164  \paragraph{\RG6: Testability}
   2.165  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?
   2.166 @@ -357,17 +353,12 @@
   2.167  
   2.168  
   2.169  
   2.170 -\paragraph{Modularity}
   2.171 -Modularity---the important architectural goal---is currently not existent in \masqmail's code. The whole source is interweaved.
   2.172 -
   2.173 -
   2.174 -
   2.175  
   2.176  
   2.177  
   2.178  \section{Work to do}
   2.179  
   2.180 -After the requirements for modern \mta{}s were identified in section \ref{sec:mta-requirements} and \masqmail's features were set against them in section \ref{sec:fulfilled-requirements}, here the the work that is left to do is identified. Table \ref{tab:requirements} lists all requirements with importance and the work needed to achieve them. The attention a work task should receive---the focus---depends on its importance and the amount of work it includes.
   2.181 +After the requirements for modern \mta{}s were identified in section \ref{sec:mta-requirements} and \masqmail's features were set against them in section \ref{sec:fulfilled-requirements}, here the work that is left to do is identified. Table \ref{tab:requirements} lists all requirements with importance and the work needed to achieve them. The column ``Focus'' shows the attention a work task should get. The focus depends on the task's importance and the amount of work it includes.
   2.182  
   2.183  \begin{table}
   2.184  	\begin{center}
   2.185 @@ -377,39 +368,35 @@
   2.186  	\label{tab:requirements}
   2.187  \end{table}
   2.188  
   2.189 -The importance is ranked from `-{}-' (not important) to `++' (very important). The pending work is ranked from `-{}-' (nothing) to `++' (very much). Large work tasks with high importance need to receive much attention, they are in focus. In contrast should small low importance work receive few attention. Here the attention/focus a task should get is calculated by summing up the importance and the pending work with equal weight. Normally, tasks with high focus are the ones of high priority and should be done first.
   2.190 +The importance is ranked from `-{}-' (not important) to `++' (very important). The pending work is ranked from `-{}-' (nothing) to `++' (very much). Large work tasks with high importance need to receive much attention, they need to be in focus. In contrast should small low importance work receive few attention. Here the focus for a task is calculated by summing up the importance and the pending work with equal weight. Normally, tasks with high focus are the ones of high priority and should be done first.
   2.191  
   2.192  The functional requirements that receive highest attention are \RF6: authentication, \RF7: encryption, and \RF8: spam handling. Of the non-functional requirements, \RG1: security, \RG2: reliability, and \RG4: Extendability, rank highest.
   2.193  
   2.194 -These tasks are presented in more detail now. They are sorted in the suggested order to work on them..
   2.195 +These tasks are presented in more detail in an list of work tasks now. The list is sorted by focus and then by importance.
   2.196  
   2.197  
   2.198  \subsubsection*{\TODO1: Encryption (\RF7)}
   2.199 -Encryption is chosen first, as it is essential to providing privacy. Encryption by using \NAME{STARTTLS} is definitely needed and should be added soon. Without support for it, encrypted email transfer is hardly possible.
   2.200 +Encryption is chosen for number one as it is essential to provide privacy. Encryption by using \NAME{STARTTLS} is definitely needed and should be added first. Encrypted data transfer is hardly possible without support for it.
   2.201 +
   2.202  
   2.203  \subsubsection*{\TODO2: Authentication (\RF6)}
   2.204 -Authentication of incoming \SMTP\ connections also needed and should be added soon. It is important for restricting access to prevent relaying. For workstations and local networks, it has only medium importance and address-based authentication is sufficient in most times. But secret-based authentication is mandatory to receive mail from the internet.
   2.205 +Authentication of incoming \SMTP\ connections is also needed and should be added second. It is important to restrict access and to prevent relaying. For workstations and local networks, it has only medium importance and address-based authentication is sufficient in most times. But secret-based authentication is mandatory to receive mail from the Internet. Additionally it is a guard against spam.
   2.206 +
   2.207  
   2.208  \subsubsection*{\TODO3: Security (\RG1)}
   2.209 -\masqmail's security is bad, thus the program is forced into a limited field of operation. The field of operation even shrinks, as security becomes more important and networking and interaction increases. Save and trusted environment become rare.
   2.210 +\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. Save 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.
   2.211  
   2.212 -Compartementalization, ref secure coding, postfix ...
   2.213 -
   2.214 -Improving security is an important thing to do. Especially, \masqmail's security should be tested throughout to get a definitive view how good it really is and where the weak spots are.
   2.215  
   2.216  \subsubsection*{\TODO4: Reliability (\RG2)}
   2.217 -Reliability is also to improve. It is a key quality property for an \MTA, and not good enough in \masqmail. Reliability is strong related to the queue, thus improvements there are favorable. Applying ideas of \name{crash-only software} \cite{candea03} will be a good step. \person{Candea} and \person{Fox} see in killing the process the best way to stop a running program. Doing so inevitably demands for good reliability of the queue, and the startup inevitably demands for good recovery. The critical situations for reliability are nothing special anymore, they are common. Hence they are regulary tested and will definately work.
   2.218 -% persistence, database
   2.219 +Reliability is also to improve. It is a key quality property for an \MTA, and not good enough in \masqmail. Reliability is strong related to the queue, thus improvements there are favorable. Applying ideas of \name{crash-only software} \cite{candea03} will be a good step. \person{Candea} and \person{Fox} see in killing the process the best way to stop a running program. Doing so inevitably demands for good reliability of the queue, and the startup process inevitably demands for good recovery. The critical situations for reliability are nothing special anymore, they are common. Hence they are regulary tested and will definately work.
   2.220 +
   2.221  
   2.222  \subsubsection*{\TODO5: Spam handling (\RF8)}
   2.223 -As authentication can be a guard against spam, filter facilities have lower priority. But basic spam filtering and interfaces for external tools should be implemented in future.
   2.224 +As authentication can be a guard against spam, filter facilities have lower priority. But basic spam filtering and interfaces for external tools should be implemented in future. Configuration guides for a setup using the approach of two \masqmail\ instances with a spam scanner inbetween should be written. And at least a basic kind of spam prevention during the \SMTP\ dialog should be implemented.
   2.225  
   2.226  
   2.227  \subsubsection*{\TODO6: Extendability (\RG4)}
   2.228 -Extendability does suffer from the monolithic architecture and is nearly impossible to improve without changing the programs structure. This property can hardly be retrofitted into software. Extendability is expected become important in the future as new protocols need to be supported.
   2.229 -
   2.230 -\masqmail\ lacks an interface to plug in modules with additional functionality. There exists no add-on or module system. The code is only separated by function to the various source files. Some functional parts can be included or excluded by defining symbols at compile time. Adding maildir support, means giving the option \verb+--enable-maildir+ to the \path{configure} call. This preserves the concerning code to get removed by the preprocessor. Unfortunately the \verb+#ifdef+s are scattered through all the source, leading to a code that is hard to read.
   2.231 -%fixme: refer to ifdef-considered-harmful ?
   2.232 +\masqmail\ lacks an interface to plug in modules with additional functionality. There exists no add-on or module system. The code is only separated by function to the various source files. Some functional parts can be included or excluded by conditional compilation. But the \name{ifdef}s are scattered through all the code. This situation needs to be improved by collecting related function into single places that interact through clear interfaces with other parts. Also should these interfaces allow efficient adding of further functionality.
   2.233  
   2.234  
   2.235  
   2.236 @@ -479,6 +466,9 @@
   2.237  
   2.238  Quality properties, like security (\TODO3) and reliability (\TODO3), as well as extendability (\TODO6) and maintainability, can hardly be added afterwards---if at all. Only structural changes will improve them. Hence, if security, reliability, extendability (to add support for future mail transfer protocols), or maintainability shall be improved, a redesign of \masqmail\ is the only sane way to go.
   2.239  
   2.240 +%Extendability does suffer from the monolithic architecture and is nearly impossible to improve without changing the programs structure. This property can hardly be retrofitted into software. Extendability is expected become important in the future as new protocols need to be supported.
   2.241 +
   2.242 +
   2.243  However, a redesign and rewrite of software from scratch is hard. It takes time to design a new architecture, which then must prove it is secure and reliable. As well is much time and work needed to implement the design, test it, fix bugs, and so on. If flaws in the design appear during prototype implementation, it is necessary to start again. Thus the gain of a new design must overweight the effort needed.
   2.244  
   2.245  \person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):

     3.1 --- a/thesis/tex/5-Improvements.tex	Fri Jan 16 10:35:48 2009 +0100
     3.2 +++ b/thesis/tex/5-Improvements.tex	Fri Jan 16 14:51:08 2009 +0100
     3.3 @@ -108,6 +108,11 @@
     3.4  \end{verbatim}
     3.5  
     3.6  
     3.7 +\subsection{Reliability}
     3.8 +
     3.9 +discuss persistence through using databases
    3.10 +
    3.11 +
    3.12  
    3.13  \subsection{Spam and malware handling}
    3.14