1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Jan 10 00:27:31 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Jan 10 00:29:21 2009 +0100
     1.3 @@ -18,7 +18,7 @@
     1.4  
     1.5  With \masqmail\ comes the small tool \path{mservdetect}; it helps setting up a configuration that uses the \name{mserver} system to detect the online state. Two other binaries get compiled for testing purposes: \path{readtest} and \path{smtpsend}. All three programs use \masqmail\ source code; they only add a file with a \verb+main()+ function each.
     1.6  
     1.7 -\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 code that is hard to read.
     1.8 +\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.
     1.9  %fixme: refer to ifdef-considered-harmful ?
    1.10  
    1.11  
    1.12 @@ -26,14 +26,15 @@
    1.13  \subsubsection*{Features}
    1.14  \label{sec:masqmail-features}
    1.15  
    1.16 -\masqmail\ accepts mail on the command line and via \SMTP. Mail queuing and alias expansion is supported. \masqmail\ is able to deliver mail to local mailboxes (in \name{mbox} or \name{maildir} format) or pass it to a \name{mail delivery agent} (like \name{procmail}). Mail for remote destinations is sent using \SMTP\ or can be piped to commands, that are gateways to \NAME{UUCP} or telefax for example.
    1.17 +\masqmail\ supports two channels for incoming mail: (1) Standard input, used when \path{masqmail} is executed on the command line and (2) a \NAME{TCP} socket, used by local or remote clients that talk \SMTP. The outgoing channels for mail are: (1) direct delivery to local mailboxes (in \name{mbox} or \name{maildir} format), (2) local pipes to pass mail to a program (e.g.\ gateways to \NAME{UUCP}, gateways to fax, or \NAME{MDA}s), and (3) \NAME{TCP} sockets to transfer mail to other \MTA{}s using the \SMTP\ protocol.
    1.18  
    1.19 -Outgoing \SMTP\ connections feature \SMTP-\NAME{AUTH} and \SMTP-after-\NAME{POP} authentication, but incoming connections do not. Using wrappers for outgoing connections is supported. This allows encrypted communication through a wrapper application like \name{openssl}.
    1.20 -%todo: what about SSL/TLS encryption?
    1.21 +Outgoing \SMTP\ connections feature \SMTP-\NAME{AUTH} and \SMTP-after-\NAME{POP} authentication, but incoming connections do not. Using wrappers for outgoing connections is supported. This allows encrypted communication through a gateway application like \name{openssl}.
    1.22  
    1.23 -\masqmail\ focuses on non-permanent online connections, thus a concept of online routes is used. One may configure any number of routes to send mail. Each route can have criteria, like matching \texttt{From:} or \texttt{To:} headers, to determine if some message is allowed to be sent over it. Mail to destinations outside the local network gets queued until an online connections is available.
    1.24 +Mail queuing and alias expansion is both supported.
    1.25  
    1.26 -The \masqmail\ executable can be called under various names for sendmail-compatibility reasons. This is organized by symbolic links with different names pointing to the \masqmail\ executable. The \sendmail\ names are \path{/usr/lib/sendmail} and \path{/usr/sbin/sendmail} because many programs expect the \mta\ to be located there. Further more \sendmail\ supports calling it with a different name instead of supplying command line arguments. The best known of this shortcuts is \path{mailq}, which is equivalent to calling it with the argument \verb+-bq+. \masqmail\ recognizes the names \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The first two are inspired by \sendmail. Not implemented is the name \path{newaliases} because \masqmail\ does not generate binary representations of the alias file.\footnote{A shell script named \path{newaliases}, that invokes \texttt{masqmail -bi}, can provide the command to satisfy other software needing it.} \path{hoststat} and \path{purgestat} are missing for complete sendmail-compatibility.
    1.27 +\masqmail\ focuses on non-permanent online connections, thus a concept of online routes is used. One may configure any number of routes to send mail. Each route can have criteria to determine if some message is allowed to be sent over it. This concept is explained in section \ref{sec:masqmail-routes} in detail. Mail to destinations outside the local network gets queued until an online connections is available.
    1.28 +
    1.29 +The \masqmail\ executable can be called under various names for sendmail-compatibility reasons. This is organized by symbolic links with different names pointing to the \masqmail\ executable. The \sendmail\ names are \path{/usr/lib/sendmail} and \path{/usr/sbin/sendmail} because many programs expect the \mta\ to be located there. Further more \sendmail\ supports calling it with a different name instead of supplying command line arguments. The best known of this shortcuts is \path{mailq}, which is equivalent to calling it with the argument \verb+-bq+. \masqmail\ recognizes the shortcuts \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The first two are inspired by \sendmail. Not implemented is the shortcut \path{newaliases} because \masqmail\ does not generate binary representations of the alias file.\footnote{A shell script named \path{newaliases}, that invokes \texttt{masqmail -bi}, can provide the command to satisfy other software needing it.} \path{hoststat} and \path{purgestat} are missing for complete sendmail-compatibility.
    1.30  %masqmail: mailq, mailrm, runq, rmail, smtpd/in.smtpd
    1.31  %sendmail: hoststat, mailq, newaliases, purgestat, smtpd
    1.32  
    1.33 @@ -54,40 +55,48 @@
    1.34  
    1.35  \subsection{Functional requirements}
    1.36  
    1.37 -The basic job of a \mta\ is to transport mail from senders to recipients. This is the definition of such kind of software, and this is how \MTA{}s are generally seen \cite[page 19]{dent04} \cite[pages 3-5]{hafiz05}.
    1.38 +Functional requirements are about the function of the software. They define what the program can do and in what way.
    1.39 +%fixme: add ref
    1.40 +The requirements are named ``RF'' for ``requirement, functional''.
    1.41  
    1.42 -An \MTA\ therefore needs at least a mail receiving facility and a mail sending facility.
    1.43  
    1.44 +\subsubsection*{RF1: Incoming and outgoing channels}
    1.45  
    1.46 +\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.47  
    1.48 -\subsubsection*{Incoming channels}
    1.49 +\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.50  
    1.51 -\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. \SMTP\ is the primary mail transport protocol today, but with the increasing need for new protocols\ref{FIXME} in mind, support for more than just \SMTP\ is good to have. This leads to multiple remote channels.
    1.52  
    1.53 +Outgoing mail is commonly either sent using \SMTP, piped into local commands (for example \path{uucp}), or delivered locally by appending to a mailbox. Outgoing channels are similar for \qmail, \postfix, and \name{sendmail X}: All of them have a module to send mail using \SMTP, and one for writing into a local mailbox.
    1.54  
    1.55 -\subsubsection*{Outgoing channels}
    1.56 +%todo: is the def of MTA: transfer between machines, or transfer between users?
    1.57 +Local mail delivery is a job that uses root privilege to be able to switch to any user in order to write to his mailbox. It is possible to deliver without being root privilege, but delivery to user's home folders is not generally possible then. Thus even the modular \MTA{}s \qmail\ and \postfix\ use root privilege for it. As mail delivery to local users is \emph{not} included in the basic job of an \MTA{} and introduces a lot of new complexity, why should the \MTA\ bother? In order to keep the system simple, reduce privilege, and to have programs that do one job well, the local delivery job should be handed over to a specialist: the \NAME{MDA}. \NAME{MDA}s know about the various mailbox formats and are aware of the problems of concurrent write access and the like. Hence passing the message, and the responsibility for it, over to an \NAME{MDA} seems to be best.
    1.58  
    1.59 -Outgoing mail is commonly either sent using \SMTP, piped into local commands (for example \path{uucp}), or delivered locally by appending to a mailbox.
    1.60 +This means an outgoing connection that pipes mail into local commands is required. To other outgoing channels applies what was already said about incoming channels.
    1.61  
    1.62 -Outgoing channels are similar for \qmail, \postfix, and \name{sendmail X}: All of them have a module to send mail using \SMTP, and one for writing into a local mailbox.
    1.63 +\begin{figure}
    1.64 +	\begin{center}
    1.65 +		\includegraphics[scale=0.75]{img/mta-channels.eps}
    1.66 +	\end{center}
    1.67 +	\caption{Incoming and outgoing channels required}
    1.68 +	\label{fig:mta-channels}
    1.69 +\end{figure}
    1.70  
    1.71 -% is the def of MTA: transfer between machines, or transfer between users?
    1.72 -Local mail delivery is a job that requires root privilege to be able to switch to any user in order to write to his mailbox. As mail delivery to local users, is \emph{not} included in the basic job of an \MTA{}, why should it care about it? In order to reduce root privilege, to keep the system simple, and to have programs that do one job well, the local delivery job should be handed over to a specialist: a \name{mail delivery agent}. \NAME{MDA}s know about the various mailbox formats and are aware of the problems of concurrent write access and the like. Hence passing the message, and the responsibility for it, over to an \NAME{MDA}, like \name{procmail} or \name{maildrop}, seems to be best.
    1.73 +An overview on in and outgoing channels required for an \MTA, gives figure \ref{fig:mta-channels}.
    1.74  
    1.75 -This means an outgoing connection that pipes mail into local commands is required. Other outgoing channels, one for each supported protocol, may be designed like it was done in other \MTA{}s.
    1.76  
    1.77  
    1.78  
    1.79 -\subsubsection*{Mail queue}
    1.80 +\subsubsection*{RF2: Mail queuing}
    1.81  
    1.82 -Additionally to the mail receiving and sending facilities, mail queuing is a basic feature. A mail queue removes the need to deliver instantly as a message is received. It provides fail-safe storage of mails until they are delivered. Mail queues are probably used in all \mta{}s, excluding the 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.
    1.83 +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, excluding the 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.84  
    1.85  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.86  
    1.87  
    1.88  
    1.89  
    1.90 -\subsubsection*{Header sanitizing}
    1.91 +\subsubsection*{RF3: Header sanitizing}
    1.92  
    1.93  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.94  
    1.95 @@ -96,46 +105,61 @@
    1.96  
    1.97  
    1.98  
    1.99 -\subsubsection*{Aliasing}
   1.100 +\subsubsection*{RF4: Aliasing}
   1.101  
   1.102  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.103  
   1.104  
   1.105  
   1.106  
   1.107 -\subsubsection*{Selecting a route}
   1.108 +\subsubsection*{RF5: Selecting a route}
   1.109  
   1.110 -One key feature of \masqmail\ is its ability to send mail out over different routes. The decision, which route to take, 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 is chosen by checking every available route for being able to transfer the current message, until one matches.
   1.111 +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.112  
   1.113  
   1.114  
   1.115  
   1.116 -\subsubsection*{Authentication}
   1.117 +\subsubsection*{RF6: Authentication}
   1.118  
   1.119 -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.
   1.120 +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 be also wanted to refuse all connections to the \MTA\ except ones from a specific set of hosts.
   1.121  
   1.122 -Several ways to restrict access are available. The most simple one is restriction by the \NAME{IP} address. No extra complexity is added this way, but static \NAME{IP} addresses are required.
   1.123 +Several ways to restrict access are available. The most simple one is restriction by the \NAME{IP} address. No extra complexity is added this way, but the \NAME{IP} addresses have to be static or within known ranges. This approach is often used to allow relaying for local nets. The access check can be done by the \MTA\ or by a guard (e.g.\ \NAME{TCP} \name{Wrappers}) before. The main advantage here is the minimal setup and maintainence work needed. This kind of access restriction is important to be implemented.
   1.124  
   1.125 -If static access restriction is not possible, some kind of authentication mechanism is required. Three common kinds exist:
   1.126 +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 subnet, need access. Then a authentication mechanism based on some \emph{secret} is required. Three common approaches exist:
   1.127  \begin{itemize}
   1.128 -	\item \SMTP-after-\NAME{POP}: Uses authentication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards.
   1.129 -	\item \SMTP\ authentication: An extension to \SMTP. It allows to request authentication before mail is accepted.
   1.130 -	\item Certificates: The identity is confirmed by certificates that are signed by trusted authorities.
   1.131 +	\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.132 +	\item \SMTP\ authentication: An extension to \SMTP. It allows to request authentication before mail is accepted. Here no helper protocols are needed.
   1.133 +	\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: \NAME{SSL} tunnels encrypt the data transmission and allow to identify the remote user/host by his certificate.
   1.134  \end{itemize}
   1.135 +At least one of the secret-based mechanisms should be supported.
   1.136  
   1.137  
   1.138  
   1.139 -\subsubsection*{Encryption}
   1.140 +\subsubsection*{RF7: Encryption}
   1.141  
   1.142 -Electronic mail is very weak to sniffing attacks, because all data transfer is unencrypted. This concerns the message's content, as well as the email addresses in header and envelope, but also authentication dialogs that transfer plain text passwords (\NAME{PLAIN} and \NAME{LOGIN} are examples). Hence encryption is wanted.
   1.143 +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.
   1.144  
   1.145  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}.
   1.146  
   1.147 -Outgoing \SMTP\ connections can get encrypted using a secure tunnel, created by an external application. Incoming connections, can not use this technique because the remote \NAME{IP} address is hidden then; \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s usually implement.
   1.148 +Using secure tunnels, that are provided by external applications, is prefered as 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.
   1.149  
   1.150 +\begin{figure}
   1.151 +	\begin{center}
   1.152 +		\includegraphics[scale=0.75]{img/stunnel.eps}
   1.153 +	\end{center}
   1.154 +	\caption{Using \name{stunnel} for incoming connections}
   1.155 +	\label{fig:stunnel}
   1.156 +\end{figure}
   1.157  
   1.158 +\NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s usually implement.
   1.159  
   1.160 -\subsubsection*{Spam prevention}
   1.161 +
   1.162 +smtps on 465 (obsolete)
   1.163 +
   1.164 +starttls on port 25 (state-of-the-art)
   1.165 +
   1.166 +
   1.167 +\subsubsection*{RF8: Spam prevention}
   1.168  
   1.169  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.170  
   1.171 @@ -147,7 +171,7 @@
   1.172  
   1.173  
   1.174  
   1.175 -\subsubsection*{Virus checking}
   1.176 +\subsubsection*{RF9: Virus checking}
   1.177  
   1.178  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.
   1.179  
   1.180 @@ -157,7 +181,7 @@
   1.181  
   1.182  
   1.183  
   1.184 -\subsubsection*{Archiving}
   1.185 +\subsubsection*{RF10: Archiving}
   1.186  
   1.187  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.
   1.188  
   1.189 @@ -171,45 +195,46 @@
   1.190  
   1.191  Here follows a list of non-functional requirements for \masqmail. These requirements specify the quality properties of software. The list is based on \person{Hafiz} \cite[page~2]{hafiz05}, with inspiration from \person{Spinellis} \cite[page~6]{spinellis06} and \person{Kan} \cite{kan03}.
   1.192  %fixme: refer to ch01 and ch02
   1.193 +These non-functional requirements are named ``RG'' for ``requirement, general''.
   1.194  
   1.195  
   1.196 -\subsubsection*{Security}
   1.197 +\subsubsection*{RG1: Security}
   1.198  \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. \masqmail\ needs to be secure enough for its target field of operation.
   1.199  
   1.200  
   1.201 -\subsubsection*{Reliability}
   1.202 +\subsubsection*{RG2: Reliability}
   1.203  Reliability is the second essential quality property for an \MTA. Mail for which the \MTA\ took responsibility must never get lost. The \MTA\ must not be \emph{the cause} of any mail loss, no matter what happens. Unreliable \mta{}s are of no value.
   1.204  
   1.205  
   1.206 -\subsubsection*{Robustness}
   1.207 +\subsubsection*{RG3: Robustness}
   1.208  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}.
   1.209  
   1.210  
   1.211 -\subsubsection*{Extendability}
   1.212 +\subsubsection*{RG4: Extendability}
   1.213  \masqmail's architecture needs to be extendable, to allow new features to be added afterwards. The reason for this need are changing requirements. New requirements 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.214  
   1.215  
   1.216 -\subsubsection*{Maintainability}
   1.217 +\subsubsection*{RG5: Maintainability}
   1.218  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.
   1.219  
   1.220  
   1.221 -\subsubsection*{Testability}
   1.222 +\subsubsection*{RG6: Testability}
   1.223  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.
   1.224  
   1.225  
   1.226 -\subsubsection*{Performance}
   1.227 +\subsubsection*{RG7: Performance}
   1.228  Also called ``efficiency''. Efficient software requires few time and few resources. The merge of communication hardware and its move from service providers to homes and to mobile devices, demand smaller and more resource-friendly software. The amount of mail will be lower, even if much more mail will be sent. More important will be the energy consumption and heat emission. These topics increased in relevance during the past years and they are expected to become more central.
   1.229  
   1.230  
   1.231 -\subsubsection*{Availability}
   1.232 +\subsubsection*{RG8: Availability}
   1.233  Availability is important for server programs. They must stay operational by blocking \name{denial of service} attacks and the like.
   1.234  
   1.235  
   1.236 -\subsubsection*{Portability}
   1.237 +\subsubsection*{RG9: Portability}
   1.238  Source code that compiles and runs on various operation systems is called portable. Portability can be achieved by using standard features of the programming language and common libraries. Basic rules to achieve portable code are defined by \person{Kernighan} and \person{Pike} \cite{kernighan99}. Portable code lets software spread faster.
   1.239  
   1.240  
   1.241 -\subsubsection*{Usability}
   1.242 +\subsubsection*{RG10: Usability}
   1.243  Usability, not mentioned by \person{Hafiz} (he focuses on architecture) but by \person{Spinellis} and \person{Kan}, is a property very important from the user's point of view. Software with bad usability is rarely used, no matter how good it is. If substitutes with better usability exist, the user will switch to one of them. Here, usability includes setting up and configuring; and the term ``users'' includes administrators. Having \mta{}s on home servers and workstations requires easy and standardized configuration. The common setups should be configurable with little action by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several common setups.
   1.244  
   1.245