1.1 --- a/thesis/tex/0-preface.tex	Fri Feb 06 21:09:21 2009 +0100
     1.2 +++ b/thesis/tex/0-preface.tex	Sat Feb 07 11:42:45 2009 +0100
     1.3 @@ -18,7 +18,7 @@
     1.4  
     1.5  \quad
     1.6  
     1.7 -This document is primary written with an audience of \masqmail\ developers and developers of other mail transfer agents in mind. But users of \masqmail\ and everyone who is interested in email systems in general may find this thesis an interesting literature too.
     1.8 +This document is primary written with an audience of \masqmail\ developers and developers of other mail transfer agents in mind. But users of \masqmail\ and everyone who is interested in email systems in general may find this thesis an interesting literature, too.
     1.9  
    1.10  However, at least basic knowledge about \unix\ and C programming is a prerequisite for chapters three, four, and five. \person{Kernighan} and \person{Pike}'s ``The \NAME{UNIX} Programming Environment'' \cite{kernighan84} is a valuable source to gain information about \unix. Programming in the C language is best learned from \person{Kernighan} and \person{Ritchie}'s ``The C Programming Language'' \cite{k&r}.
    1.11  
    1.12 @@ -35,7 +35,7 @@
    1.13  
    1.14  Chapter 1 \textbf{introduces} \masqmail\ to the reader. It presents the properties, goals, advantages, and problems of the program. Basic concepts of the email technology are also described and later assumed to be known.
    1.15  
    1.16 -Chapter 2 \textbf{analyzes the market} of electronic communication and email. This chapter gives sound reasons for the sense of future development of \masqmail\ by showing that email will remain an important technology in the future. It tries to identify future trends too.
    1.17 +Chapter 2 \textbf{analyzes the market} of electronic communication and email. This chapter gives sound reasons for the sense of future development of \masqmail\ by showing that email will remain an important technology in the future. It tries to identify future trends, too.
    1.18  
    1.19  Chapter 3 \textbf{deals with mail transfer agents} (\MTA{}s) which are the most important entities of the email transport structure. \MTA{}s are defined, classified, and the most important ones are presented and compared.
    1.20  
    1.21 @@ -95,7 +95,7 @@
    1.22  
    1.23  Not to forget is everyone who discussed with me on mailing lists and in private communication, and my family for backing me.
    1.24  
    1.25 -There is also an institution that needs to be praised: The \name{W\"urttembergische Landesbibliothek} in Stuttgart; it was the most productive place to work and the most impressive one too.
    1.26 +There is also an institution that needs to be praised: The \name{W\"urttembergische Landesbibliothek} in Stuttgart; it was the most productive place to work and the most impressive one, too.
    1.27  
    1.28  \quad
    1.29  

     2.1 --- a/thesis/tex/1-Introduction.tex	Fri Feb 06 21:09:21 2009 +0100
     2.2 +++ b/thesis/tex/1-Introduction.tex	Sat Feb 07 11:42:45 2009 +0100
     2.3 @@ -54,7 +54,7 @@
     2.4  
     2.5  First the \name{store and forward}\index{smtp!store and forward} transfer concept. This means mail messages are sent from \MTA\ to \MTA, until the final \MTA\ (the one which is responsible for the recipient) is reached. The message is stored for some time on each \MTA, until it is forwarded to the next \MTA.
     2.6  
     2.7 -This leads to the concept of \name{responsibility}\index{smtp!responsibility}. A mail message is always in the responsibility of one system. First it is the \MUA\index{mua}. When it is transferred to an \MTA, this \MTA\ takes over the responsibility for the message too. The \MUA{} can then delete its copy of the message. This is the same for each transfer---from \MTA\ to \MTA\ and finally from \MTA\ to the \MDA{}---the message gets transferred and if the transfer was successful, the responsibility for the message is transferred as well. The responsibility chain ends at a user's mailbox where he himself has control on the message.
     2.8 +This leads to the concept of \name{responsibility}\index{smtp!responsibility}. A mail message is always in the responsibility of one system. First it is the \MUA\index{mua}. When it is transferred to an \MTA, this \MTA\ takes over the responsibility for the message, too. The \MUA{} can then delete its copy of the message. This is the same for each transfer---from \MTA\ to \MTA\ and finally from \MTA\ to the \MDA{}---the message gets transferred and if the transfer was successful, the responsibility for the message is transferred as well. The responsibility chain ends at a user's mailbox where he himself has control on the message.
     2.9  
    2.10  A third concept is about failure handling. At any step on the way an \MTA\ may receive a message it is unable to handle. In such a case this receiving \MTA\ will \name{reject}\index{smtp!rejecting} the message before it takes responsibility for it. The sending \MTA\ still has responsibility for the message and may try other ways for sending the message. If none succeeds the \MTA\ will send a \name{bounce message}\index{smtp!bouncing} back to the original sender with information on the type of failure. Bounces are only sent if the failure is expected to be permanent or if the transfer still was unsuccessful after many tries.
    2.11  
    2.12 @@ -122,7 +122,7 @@
    2.13  
    2.14  \masqmail\ is best used in home networks which are non-permanently connected to the Internet\index{non-permanent}. It is easy configurable for situations which are rarely solvable with the common \MTA{}s. Such include different handling of mail to local or remote destination and respecting different routes of online connection. These features are explained in more detail in section~\ref{sec:masqmail-features}.
    2.15  
    2.16 -While many other \MTA{}s are general purpose \MTA{}s, \masqmail\ aims on special situations. Nevertheless, it can be used as general purpose \MTA\ too. Especially this was a design goal of \masqmail: To be a replacement for \sendmail\ or similar \MTA{}s.\index{masqmail!sendmail replacement}
    2.17 +While many other \MTA{}s are general purpose \MTA{}s, \masqmail\ aims on special situations. Nevertheless, it can be used as general purpose \MTA, too. Especially this was a design goal of \masqmail: To be a replacement for \sendmail\ or similar \MTA{}s.\index{masqmail!sendmail replacement}
    2.18  
    2.19  \masqmail\ is designed to run on workstations and on servers in small networks, like they are common in \NAME{SOHO}s (\name{Small Offices/Home Offices}).
    2.20  
    2.21 @@ -188,7 +188,7 @@
    2.22  The actual problem is not the permanent Internet connection but listening for incoming mail on it. If a firewall is closed for incoming mail, then the permanent Internet connection is no problem. To use \masqmail\ for permanent Internet connections it needs to be secured with care.
    2.23  \index{firewall}
    2.24  
    2.25 -The Internet is the common example for an untrusted network but other networks may be untrusted too.
    2.26 +The Internet is the common example for an untrusted network but other networks may be untrusted, too.
    2.27  
    2.28  
    2.29  

     3.1 --- a/thesis/tex/2-MarketAnalysis.tex	Fri Feb 06 21:09:21 2009 +0100
     3.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Sat Feb 07 11:42:45 2009 +0100
     3.3 @@ -7,7 +7,7 @@
     3.4  
     3.5  \section{Electronic communication technologies}
     3.6  
     3.7 -Electronic communication is ``communication by computer'', according to the \name{WordNet} database of the \name{Princeton University} \citeweb{wordnet}. Mobile phones and fax machines should be seen as computers here too. The \name{Science Glossary} of the \name{Pennsylvania Department of Education} \citeweb{science-glossary-pa} describes electronic communication as ``System for the transmission of information using electronic technology (e.g., digital cameras, cellular telephones, Internet, television, fiber optics).''
     3.8 +Electronic communication is ``communication by computer'', according to the \name{WordNet} database of the \name{Princeton University} \citeweb{wordnet}. Mobile phones and fax machines should be seen as computers here, too. The \name{Science Glossary} of the \name{Pennsylvania Department of Education} \citeweb{science-glossary-pa} describes electronic communication as ``System for the transmission of information using electronic technology (e.g., digital cameras, cellular telephones, Internet, television, fiber optics).''
     3.9  \index{electronic communication}
    3.10  
    3.11  Electronic communication needs no transport of tangible things, only electrons, photons, or radio waves need to be transmitted. Thus electronic communication is fast in general. With costs mainly for infrastructure and very low costs for data transmission is electronic communication also cheap communication. Primary the Internet is used as underlying transport infrastructure. Thus electronic communication is available nearly everywhere around the world. These properties---fast, cheap, available---make electronic communication well suited for long distance communication.
    3.12 @@ -238,7 +238,7 @@
    3.13  Nowadays, dial-up Internet access became rare; the majority of the users has broadband Internet access. As a flat rate is payed for it, the time being online does not affect costs anymore, even traffic is unlimited. Today it is possible to have an own mail server running at home. The remaining technical problem is the changing \NAME{IP} addresses one gets assigned every 24 hours\footnote{This, at least, is the situation in Germany.}. But this is solvable with one of the dynamic \NAME{DNS} services; they provide the mapping of a fixed domain name to the changing \NAME{IP} addresses.
    3.14  \index{changing ip addresses}
    3.15  
    3.16 -Home servers become popular for central data storage and multimedia services, these days. Being assembled of energy efficient hardware, power consumption is no big problem anymore. These home servers will replace video recorders and \NAME{CD} music collections in the near future. It is also realistic that they will manage heating systems and intercoms too. Given the future leads to this direction, it will be a logical step to have email and other communication provided by the own home server as well.
    3.17 +Home servers become popular for central data storage and multimedia services, these days. Being assembled of energy efficient hardware, power consumption is no big problem anymore. These home servers will replace video recorders and \NAME{CD} music collections in the near future. It is also realistic that they will manage heating systems and intercoms, too. Given the future leads to this direction, it will be a logical step to have email and other communication provided by the own home server as well.
    3.18  \index{home server}
    3.19  
    3.20  After years in which \MTA{}s have not been popular for users, the next years might bring the \MTA{}s back to the users. Maybe in a few years nearly everyone will have one, or many, running at home.
    3.21 @@ -259,7 +259,7 @@
    3.22  
    3.23  \subsubsection*{New email concepts}
    3.24  
    3.25 -Changing requirements for email communication lead to the need for new concepts and new protocols that cover these requirements. One of these concepts to redesign the email system is named \name{Internet Mail 2000}. It was proposed by \person{Daniel~J.\ Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others too.
    3.26 +Changing requirements for email communication lead to the need for new concepts and new protocols that cover these requirements. One of these concepts to redesign the email system is named \name{Internet Mail 2000}. It was proposed by \person{Daniel~J.\ Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others, too.
    3.27  %FIXME: add references for IM2000
    3.28  \index{Internet Mail 2000}
    3.29  

     4.1 --- a/thesis/tex/3-MailTransferAgents.tex	Fri Feb 06 21:09:21 2009 +0100
     4.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Sat Feb 07 11:42:45 2009 +0100
     4.3 @@ -54,7 +54,7 @@
     4.4  
     4.5  Normally the term ``groupware'' does not mean one single program, but a suite of programs. They build a framework which is then populated with various modules that provide the actual functionality. Modules for mail transfer, file storage, calendars, resource management, Instant Messaging, and more, are commonly available.
     4.6  
     4.7 -These program suites are used if the main work to do is providing integrated communication facilities and team working support for a group of people. Mail transfer is only one part of the problem to solve. The most common scenario are companies. They use \name{groupware} to provide adequate services for their teams to work efficiently. But one may use \name{groupware} on the home server for the family members too.
     4.8 +These program suites are used if the main work to do is providing integrated communication facilities and team working support for a group of people. Mail transfer is only one part of the problem to solve. The most common scenario are companies. They use \name{groupware} to provide adequate services for their teams to work efficiently. But one may use \name{groupware} on the home server for the family members, too.
     4.9  
    4.10  Examples for groupware are: \name{Lotus Notes}, \name{Microsoft Exchange}, and \name{OpenGroupware.org}.
    4.11  
    4.12 @@ -171,7 +171,7 @@
    4.13  
    4.14  \exim\ was started in 1995 by \person{Philip Hazel} at the \name{University of Cambridge}. It is a fork of \name{smail-3}, and inherited the monolithic architecture which is similar to \sendmail's. But having no architecture-given separation of the individual components of the system did not hurt. Its security is quite good \cite{blanco05}.
    4.15  
    4.16 -\exim\ is highly configurable, especially in the field of mail policies. This makes it easy to specify how mail is routed through the system and who is allowed to send email to whom. Interfaces to integrate spam and malware checkers are provided by design too.
    4.17 +\exim\ is highly configurable, especially in the field of mail policies. This makes it easy to specify how mail is routed through the system and who is allowed to send email to whom. Interfaces to integrate spam and malware checkers are provided by design, too.
    4.18  
    4.19  The program is Free Software, released under the \NAME{GPL}. The latest stable version is 4.69 from December 2007.
    4.20  \index{gpl}
    4.21 @@ -187,7 +187,7 @@
    4.22  
    4.23  \qmail\ is seen by its community as ``a modern \SMTP\ server which makes sendmail obsolete'' \citeweb{qmail:homepage2}. It was written by \person{Daniel~J.\ Bernstein}, starting in 1995. His primary goal was to create a secure \MTA\ to replace the popular, but vulnerable, \sendmail. His own words are: ``This is why I started writing qmail: I was sick of the security holes in sendmail and other \MTA{}s.'' \citeweb{qmail:homepage1}.
    4.24  
    4.25 -\qmail\ first introduced many innovative concepts in \MTA\ design. The most obvious contrast to \sendmail\ and \exim\ is its modular design. But \qmail\ was not the first modular \MTA. \NAME{MMDF}, which predates even \sendmail, was modular too. Regardless of \NAME{MMDF}'s modular architecture, \qmail\ is generally seen as the first security-aware \MTA\ \citeweb{wikipedia:qmail}.
    4.26 +\qmail\ first introduced many innovative concepts in \MTA\ design. The most obvious contrast to \sendmail\ and \exim\ is its modular design. But \qmail\ was not the first modular \MTA. \NAME{MMDF}, which predates even \sendmail, was modular, too. Regardless of \NAME{MMDF}'s modular architecture, \qmail\ is generally seen as the first security-aware \MTA\ \citeweb{wikipedia:qmail}.
    4.27  
    4.28  The latest release of \qmail\ is version 1.03 from July 1998. Afterwards, in November 2007, \qmail's source was put into the \name{public domain}. This made it Free Software.
    4.29  \index{public domain}
    4.30 @@ -239,7 +239,7 @@
    4.31  \subsubsection*{Architecture}
    4.32  \index{mta!architecture}
    4.33  
    4.34 -Architecture is most important when comparing \MTA{}s. Many other properties of a program depend on its architecture. \person{Munawar Hafiz} discusses in detail on \MTA\ architecture, comparing \sendmail, \qmail, \postfix, and \name{sendmail~X} \cite{hafiz05}. \person{Jonathan de Boyne Pollard}'s \MTA\ review \cite{jdebp} is a source too.
    4.35 +Architecture is most important when comparing \MTA{}s. Many other properties of a program depend on its architecture. \person{Munawar Hafiz} discusses in detail on \MTA\ architecture, comparing \sendmail, \qmail, \postfix, and \name{sendmail~X} \cite{hafiz05}. \person{Jonathan de Boyne Pollard}'s \MTA\ review \cite{jdebp} is a source, too.
    4.36  
    4.37  Two different architecture types show off: monolithic and modular \MTA{}s.
    4.38  
    4.39 @@ -278,7 +278,7 @@
    4.40  
    4.41  \paragraph{Security}
    4.42  \index{security}
    4.43 -The third trend (even more security awareness) is addressed by each of the four programs. It seems as if all widely used \MTA{}s provide good security nowadays. Even \sendmail\ can be configured to be secure today. However, the modular architecture, used by \qmail\ and \postfix, is generally seen to be conceptually more secure. \sendmail's creators have started \name{MeTA1}, a modular \MTA\ that merges the best of \qmail\ and \postfix, to replace the old \sendmail. It will be interesting to watch \exim's future---will it become modular too?
    4.44 +The third trend (even more security awareness) is addressed by each of the four programs. It seems as if all widely used \MTA{}s provide good security nowadays. Even \sendmail\ can be configured to be secure today. However, the modular architecture, used by \qmail\ and \postfix, is generally seen to be conceptually more secure. \sendmail's creators have started \name{MeTA1}, a modular \MTA\ that merges the best of \qmail\ and \postfix, to replace the old \sendmail. It will be interesting to watch \exim's future---will it become modular, too?
    4.45  
    4.46  
    4.47  

     5.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Fri Feb 06 21:09:21 2009 +0100
     5.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 11:42:45 2009 +0100
     5.3 @@ -87,7 +87,7 @@
     5.4  \index{forwarder}
     5.5  \index{non-permanent}
     5.6  
     5.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.
     5.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.
     5.9  \index{reliability}
    5.10  
    5.11  
    5.12 @@ -96,7 +96,7 @@
    5.13  \paragraph{\RF3: Header sanitizing}
    5.14  \label{rf3}
    5.15  \index{header sanitizing}
    5.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.
    5.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.
    5.18  \index{masqmail!online routes}
    5.19  
    5.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.
    5.21 @@ -134,8 +134,8 @@
    5.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:
    5.23  
    5.24  \begin{enumerate}
    5.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.
    5.26 -\index{auth!smtp-after-pop}
    5.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.
    5.28 +	\index{auth!smtp-after-pop}
    5.29  	\item \SMTP\ authentication: An extension to \SMTP. It allows to request authentication before mail is accepted. Here no helper protocols are needed.
    5.30  \index{auth!smtp-auth}
    5.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.
    5.32 @@ -147,7 +147,7 @@
    5.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.
    5.34  \index{untrusted environment}
    5.35  
    5.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.
    5.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.
    5.38  
    5.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.
    5.40  
    5.41 @@ -257,10 +257,10 @@
    5.42  
    5.43  \paragraph{\RG2: Reliability}
    5.44  \index{reliability}
    5.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.
    5.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.
    5.47  \index{mail loss}
    5.48  
    5.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.
    5.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.
    5.51  
    5.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.
    5.53  \index{duplicates}
    5.54 @@ -273,7 +273,7 @@
    5.55  
    5.56  \paragraph{\RG4: Extendability}
    5.57  \index{extendability}
    5.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.
    5.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.
    5.60  
    5.61  
    5.62  \paragraph{\RG5: Maintainability}
    5.63 @@ -405,7 +405,7 @@
    5.64  
    5.65  \paragraph{\RF6: Authentication}
    5.66  \index{auth}
    5.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.
    5.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.
    5.69  \index{auth!smtp-after-pop}
    5.70  \index{auth!smtp-auth}
    5.71  
    5.72 @@ -433,7 +433,7 @@
    5.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.
    5.74  \index{masqmail!security}
    5.75  
    5.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.
    5.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.
    5.78  \index{conditional compilation}
    5.79  
    5.80  \paragraph{\RG2: Reliability}
    5.81 @@ -529,7 +529,7 @@
    5.82  
    5.83  \subsubsection*{\TODO3: Security (\RG1)}
    5.84  \index{security}
    5.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.
    5.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.
    5.87  \index{modularity}
    5.88  
    5.89  
    5.90 @@ -598,7 +598,7 @@
    5.91  
    5.92  This leads to the conclusion that S\,3 (A new design) is probably the best strategy for further development.
    5.93  
    5.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.
    5.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.
    5.96  
    5.97  
    5.98  
    5.99 @@ -614,7 +614,7 @@
   5.100  \subsubsection*{Quality improvements}
   5.101  \index{quality improvement}
   5.102  
   5.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.
   5.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.
   5.105  \index{modularity}
   5.106  
   5.107  
   5.108 @@ -654,7 +654,7 @@
   5.109  
   5.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.
   5.111  
   5.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.
   5.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.
   5.114  
   5.115  
   5.116  
   5.117 @@ -691,7 +691,7 @@
   5.118  \subsubsection*{Repairing}
   5.119  \index{reparing}
   5.120  
   5.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.
   5.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.
   5.123  
   5.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}.
   5.125  
   5.126 @@ -702,7 +702,7 @@
   5.127  
   5.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.
   5.129  
   5.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.
   5.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.
   5.132  \index{quality improvement}
   5.133  
   5.134  
   5.135 @@ -730,7 +730,7 @@
   5.136  \subsubsection*{Modularity}
   5.137  \index{modularity}
   5.138  
   5.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.
   5.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.
   5.141  
   5.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.
   5.143  \index{modularity}

     6.1 --- a/thesis/tex/5-Improvements.tex	Fri Feb 06 21:09:21 2009 +0100
     6.2 +++ b/thesis/tex/5-Improvements.tex	Sat Feb 07 11:42:45 2009 +0100
     6.3 @@ -80,7 +80,7 @@
     6.4  \hfill\cite[page~44]{dent04}
     6.5  \end{quote}
     6.6  
     6.7 -These days \NAME{SMTP-AUTH}---defined in \RFC\,2554---is supported by most email clients. If encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
     6.8 +These days \NAME{SMTP-AUTH}---defined in \RFC\,2554---is supported by almost all email clients. If encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
     6.9  
    6.10  
    6.11  \subsubsection*{Simple Authentication and Security Layer}
    6.12 @@ -136,7 +136,7 @@
    6.13  \index{inetd}
    6.14  \index{proxy}
    6.15  
    6.16 -Mail from outside would then come through the proxy into the system. Mail from the local host and from the local network could be directly accepted by the normal \masqmail, if those locations are considered trusted. But it seems better to have them use the proxy too, or maybe a second proxy instance with different policy.
    6.17 +Mail from outside would then come through the proxy into the system. Mail from the local host and from the local network could be directly accepted by the normal \masqmail, if those locations are considered trusted. But it seems better to have them use the proxy, too, or maybe a second proxy instance with different policy.
    6.18  \index{policy}
    6.19  
    6.20  The here described setup comes close to the structure of the incoming channels in the new design which is described in section~\ref{sec:new-design}. This shows the capabilities of the here chosen approach.
    6.21 @@ -144,7 +144,7 @@
    6.22  
    6.23  \subsubsection*{A concrete setup}
    6.24  
    6.25 -A stripped down proxy needs to be created. It should only be able to receive mail via \SMTP, encrypt the communication, authenticate clients, and send mail out via \SMTP\ to an internal socket (named ``X'' in the figure). This is a straight forward task. The normal \masqmail\ instance runs on the system too. It takes input from \name{stdin} (when the \path{sendmail} command is invoked) and via \SMTP\ where it listens on an internal socket (named ``X'' in the figure). Outgoing mail is handled without difference to a regular setup. Figure~\ref{fig:proxy-setup} depicts the setup.
    6.26 +A stripped down proxy needs to be created. It should only be able to receive mail via \SMTP, encrypt the communication, authenticate clients, and send mail out via \SMTP\ to an internal socket (named ``X'' in the figure). This is a straight forward task. The normal \masqmail\ instance runs on the system, too. It takes input from \name{stdin} (when the \path{sendmail} command is invoked) and via \SMTP\ where it listens on an internal socket (named ``X'' in the figure). Outgoing mail is handled without difference to a regular setup. Figure~\ref{fig:proxy-setup} depicts the setup.
    6.27  \index{auth}
    6.28  \index{enc}
    6.29  
    6.30 @@ -219,7 +219,7 @@
    6.31  \index{smtp}
    6.32  \index{setuid}
    6.33  
    6.34 -But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP. To \qmail\ and \postfix\ new protocol handlers may be added without change in other parts of the system. The \SMTP\ modules can even be removed if it is not needed. It is better to have a larger number of independent modules if each one is simpler then. The need to implement \SMTP\ clients in every module for internal communication makes them more complicated.
    6.35 +But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP. To \qmail\ and \postfix\ new protocol handlers may be added without change in other parts of the system. The \SMTP\ modules can even get removed if it is not needed. It is better to have a larger number of independent modules if each one is simpler then. The need to implement \SMTP\ clients in every module for internal communication makes them more complicated.
    6.36  \index{qmail}
    6.37  \index{postfix}
    6.38  
    6.39 @@ -288,7 +288,7 @@
    6.40  
    6.41  The mail body will never get modified, except for removing and adding transfer protocol specific requirements like dot stuffing or special line ending characters. These translations are only done in receiving and sending modules.
    6.42  
    6.43 -\person{Jon Postel}'s robustness principle (``Be liberal in what you accept, and conservative in what you send.''), which can be found in this wording in \RFC\,1122 and in different wordings in numerous \RFC{}s, should be respected in the \name{scanning} module. The module should parse the given input in a liberal way and generate clean output. \person{Raymond}'s \name{Rule of Repair} (``Repair what you can -- but when you must fail, fail noisily and as soon as possible.'') \cite[page~18]{raymond03} can be applied too. But it is important to repair only obvious problems, because repairing functionality is likely a target for attacks.
    6.44 +\person{Jon Postel}'s robustness principle\footnote{``Be liberal in what you accept, and conservative in what you send.''. In this wording in \RFC\,1122 and in different wordings in numerous \RFC{}s} should be respected in the \name{scanning} module. The module should parse the given input in a liberal way and generate clean output. \person{Raymond}'s \name{Rule of Repair}\footnote{``Repair what you can -- but when you must fail, fail noisily and as soon as possible.'' \cite[page~18]{raymond03}} can be applied, too. But it is important to repair only obvious problems, because repairing functionality is likely a target for attacks.
    6.45  \index{robustness!principle of}
    6.46  
    6.47  
    6.48 @@ -484,6 +484,12 @@
    6.49  
    6.50  Left is only the communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Suggested for this communication is a simple protocol with data exchange through \unix\ pipes. Figure~\ref{fig:ipc-protocol} shows a state diagram for the protocol.
    6.51  
    6.52 +The protocol is described in more detail now:
    6.53 +\index{protocol}
    6.54 +
    6.55 +\paragraph{Timing}
    6.56 +One dialog consists of exactly three phases: (1) The connection attempt, (2) The envelope and header transfer, and (3) The transfer of the message body. The order is always the same. The three phases are all initiated by the client process. After each phase the server process sends a success or failure reply. Timeouts for each phase need to be implemented.
    6.57 +
    6.58  \begin{figure}
    6.59  	\begin{center}
    6.60  		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
    6.61 @@ -493,12 +499,6 @@
    6.62  	\label{fig:ipc-protocol}
    6.63  \end{figure}
    6.64  
    6.65 -The protocol is described in more detail now:
    6.66 -\index{protocol}
    6.67 -
    6.68 -\paragraph{Timing}
    6.69 -One dialog consists of exactly three phases: (1) The connection attempt, (2) The envelope and header transfer, and (3) The transfer of the message body. The order is always the same. The three phases are all initiated by the client process. After each phase the server process sends a success or failure reply. Timeouts for each phase need to be implemented.
    6.70 -
    6.71  \paragraph{Semantics}
    6.72  The connection attempt is simply opening the connection. This starts the dialog. A positive reply by the server leads to the transfer of the envelope and the message header. If the server again sends a positive reply, the message data is transferred. A last server reply ends the dialog.
    6.73