1.1 --- a/thesis/bib/thesis.bib	Sat Feb 07 14:47:27 2009 +0100
     1.2 +++ b/thesis/bib/thesis.bib	Sat Feb 07 19:00:25 2009 +0100
     1.3 @@ -507,3 +507,25 @@
     1.4  	year = "1979",
     1.5  	note = "Available on the Internet: {\small\url{http://dinosaur.compilertools.net/yacc/yacc.ps} (2009-02-07)}",
     1.6  }
     1.7 +
     1.8 +@article{saltzer75,
     1.9 +	author = "Jerome~H. Saltzer and Michael~D. Schroeder",
    1.10 +	title = "\textit{The Protection of Information in Computer Systems}",
    1.11 +	journal = "Proceedings of the IEEE",
    1.12 +	volume = "63",
    1.13 +	number = "9",
    1.14 +	year = "1975",
    1.15 +	pages = "1278--1308",
    1.16 +	note = "Available on the Internet: {\small\url{http://web.mit.edu/Saltzer/www/publications/protection/} (2009-02-07)}",
    1.17 +}
    1.18 +
    1.19 +@manual{sendmail:config,
    1.20 +	author = "Eric Allman",
    1.21 +	organization = "Sendmail Consortium, The",
    1.22 +	title = "\textit{Sendmail Configuration Files}",
    1.23 +	year = "2006",
    1.24 +	note = "Available on the Internet: {\small\url{http://sendmail.org/m4/readme.html} (2009-02-07)}",
    1.25 +}
    1.26 +
    1.27 +
    1.28 +

     2.1 --- a/thesis/bib/websites.bib	Sat Feb 07 14:47:27 2009 +0100
     2.2 +++ b/thesis/bib/websites.bib	Sat Feb 07 19:00:25 2009 +0100
     2.3 @@ -348,3 +348,17 @@
     2.4  	howpublished = "{\small\url{http://ietf.org} (2000-02-07)}",
     2.5  }
     2.6  
     2.7 +@misc{pushemail.co.uk,
     2.8 +	author = "unknown",
     2.9 +	title = "\textit{Push Email -- An Introduction}",
    2.10 +	howpublished = "{\small\url{http://pushemail.co.uk} (2000-02-07)}",
    2.11 +}
    2.12 +
    2.13 +@misc{im2000,
    2.14 +	author = "Daniel~J. Bernstein",
    2.15 +	title = "\textit{Internet Mail 2000}",
    2.16 +	howpublished = "{\small\url{http://cr.yp.to/im2000.html} (2000-02-07)}",
    2.17 +}
    2.18 +
    2.19 +
    2.20 +

     3.1 --- a/thesis/tex/1-Introduction.tex	Sat Feb 07 14:47:27 2009 +0100
     3.2 +++ b/thesis/tex/1-Introduction.tex	Sat Feb 07 19:00:25 2009 +0100
     3.3 @@ -47,12 +47,13 @@
     3.4  
     3.5  
     3.6  \subsubsection{Mail transfer with SMTP}
     3.7 +\label{smtp-intro}
     3.8  
     3.9  Today most of the email is transferred using the \name{Simple Mail Transfer Protocol}\index{smtp} (short: \SMTP), which is defined in \RFC\,821 and the successors \RFC\,2821 and \RFC\,5321. A good entry point for further information is \citeweb{wikipedia:smtp}.
    3.10  
    3.11  A selection of important concepts of \SMTP\index{smtp!concepts of} is explained here.
    3.12  
    3.13 -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.
    3.14 +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.
    3.15  
    3.16  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.
    3.17  
    3.18 @@ -330,7 +331,7 @@
    3.19  
    3.20  %fixme: hikernet
    3.21  
    3.22 -Additionally does \masqmail\ make it easy to run an \MTA\ on workstations or notebooks. There is no need to do complex configuration or to be a mail server expert. Only a handful of options need to be set; the host name, the local networks, and one route for relaying are sufficient in most times. %fixme: is that true?
    3.23 +Additionally does \masqmail\ make it easy to run an \MTA\ on workstations or notebooks. There is no need to do complex configuration or to be a mail server expert. Only a handful of options need to be set; the host name, the local networks, and one route for relaying are sufficient in most times.
    3.24  \index{notebook}
    3.25  
    3.26  Probably users say it best; in this case \person{Derek Broughton}:

     4.1 --- a/thesis/tex/2-MarketAnalysis.tex	Sat Feb 07 14:47:27 2009 +0100
     4.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Sat Feb 07 19:00:25 2009 +0100
     4.3 @@ -178,10 +178,9 @@
     4.4  \index{um}
     4.5  \index{store-and-forward}
     4.6  
     4.7 -The use of different hardware to access mail is another opportunity of the market. But as more hardware gets involved, the networks become more complex. Thus the need for more software and infrastructure to transfer mail within the growing network might be a weakness of the email system. %fixme: think about that
     4.8 +The use of different hardware to access mail is another opportunity of the market. But as more hardware gets involved, the networks become more complex. Thus the need for more software and infrastructure to transfer mail within the growing network might be a weakness of the email system.
     4.9  
    4.10 -An opportunity of the market and at the same time a strength of electronic mail is its standardization. Few other communication technologies are standardized, and thus freely available, in a similar way. %fixme: ref
    4.11 -Another opportunity and strength is the modular and extensible structure of electronic mail; it can easily evolve to new requirements. %fixme: ref
    4.12 +An opportunity of the market and at the same time a strength of electronic mail is its standardization. Few other communication technologies are standardized, and thus freely available, in a similar way. Another opportunity and strength is the modular and extensible structure of electronic mail; it can easily evolve to new requirements.
    4.13  \index{email!standardiziation}
    4.14  
    4.15  The increasing integration of communication channels is an opportunity for the market. But deciding whether it is a weakness or strength of email is difficult. Due to the impossibility to integrate synchronous stream data and large binary data, it is a weakness. But it is also a strength, because arbitrary asynchronous communication data already can be integrated. On the other hand, the integration might be a threat too, because integration often leads to complexity of software. Complex software is more error prone and thus less reliable. This, however, could again be a strength of electronic mail because its modular design decreases complexity.
    4.16 @@ -249,22 +248,19 @@
    4.17  
    4.18  The retrieval of email is a field that is also about to change these days. The old way is to fetch email by polling the server that holds the personal mailbox. This polling is normally done in regular intervals, often once every five to thirty minutes. The mail transfer from the mailbox to the \MUA\ is initiated from the user side. The disadvantage herewith is the delay between the arrival of mail on the server and the time when the user finally has the message on his screen.
    4.19  
    4.20 -To remove this disadvantage, \name{push email} was invented. Here the server is not polled every few minutes about new mail, but the server pushes new mail directly to the client on arrival. The transfer is initiated by the server. This concept became popular with smart phones; they were able to do emailing but the traffic caused by polling the server was expensive.
    4.21 +To remove this disadvantage, \name{push email} \citeweb{pushemail.co.uk} was invented. Here the server is not polled every few minutes about new mail, but the server pushes new mail directly to the client on arrival. The transfer is initiated by the server. This concept became popular with smart phones; they were able to do emailing but the traffic caused by polling the server was expensive.
    4.22  
    4.23  The concept works well with mobile phones where the provider knows about the client, but it does not seem to be a choice for computers, since the provider needs to have some kind of login to push data to the user's computer. Push email, however, could swap over to computers when using a home server and no external provider. A possible scenario is a home server which receives mail from the Internet and pushing it to own workstations and smart phones. The configuration could be done by the user by using some simple interface, like one configures his telephone system to have different telephone numbers ringing on specified phones.
    4.24 -%FIXME: add reference to push email
    4.25  
    4.26  Another problem is when multiple clients share one mailbox. This is only solvable by working directly in the server's mailbox, which causes lots of traffic, or by storing at least information about read messages and the like there.
    4.27  
    4.28  
    4.29  \subsubsection*{New email concepts}
    4.30  
    4.31 -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.
    4.32 -%FIXME: add references for IM2000
    4.33 +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} \citeweb{im2000}. It was proposed by \person{Daniel~J.\ Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others, too.
    4.34  \index{Internet Mail 2000}
    4.35  
    4.36 -As main change, the sender has the responsibility for mail storage; only a notification about a mail message gets sent to the recipient. The recipient can then fetch the message then from the sender's server. This is in contrast to the \NAME{SMTP} mail architecture where mail and the responsibility for it is transferred from the sender to the receiver (see \name{store-and-forward}).
    4.37 -%fixme: reference to the store-and-forward concept
    4.38 +As main change, the sender has the responsibility for mail storage; only a notification about a mail message gets sent to the recipient. The recipient can then fetch the message then from the sender's server. This is in contrast to the \SMTP\ mail architecture where mail and the responsibility for it is transferred from the sender to the receiver. (See page~\pageref{smtp-intro} for the \name{store-and-forward} principle.)
    4.39  \index{smtp!store-and-forward}
    4.40  
    4.41  \MTA{}s are still important in this new email architecture, but in a slightly different way. They do not transfer mail itself anymore, but they transport the notifications about new mail to the destinations. This is a quite similar job as in the \NAME{SMTP} model. The real transfer of the mail, however, can be done in an arbitrary way, for example via \NAME{FTP} or \NAME{SCP}.
    4.42 @@ -289,9 +285,7 @@
    4.43  Provider independence through running an own mail server at home asks for easy configuration of the \MTA. Providers have specialists to configure the systems, but ordinary people do not. Solutions are either having some home service system for computer configuration established with specialists coming to ones home to set up the systems; like it is already common for problems with the power and water supply systems. Or configuration needs to be easy and fool-proof, so it can be done by the owner himself. The latter solution depends on standardized parts that fit together seamlessly. The technology must not be a problem itself. Only settings that are custom to the users environment should be left open for him to set. This of course needs to be doable using a simple configuration interface like a web interface. Non-technical educated users should be able to configure the system.
    4.44  \index{easy configuration}
    4.45  
    4.46 -Complex configuration itself is not a problem if simplification wrappers provide an easy interface. The approach of wrappers to make it look easier to the outside is a good concept in general. %FIXME: add ref
    4.47 -It still lets the specialist do complex and detailed configuration while also a simple configuration interface to novices is offered. \sendmail\ took this approach with the \name{m4} macros. %fixme: add ref
    4.48 -Further more is this approach well suited to provide various wrappers with different user interfaces (e.g.\ graphical programs, websites, command line programs; all of them either in a questionnaire style or interactive).
    4.49 +Complex configuration itself is not a problem if simplification wrappers provide an easy interface. The approach of wrappers to make it look easier to the outside is a good concept in general. It still lets the specialist do complex and detailed configuration while also a simple configuration interface to novices is offered. \sendmail\ took this approach with the \name{m4} macros \cite{sendmail:config}. Further more is this approach well suited to provide various wrappers with different user interfaces (e.g.\ graphical programs, websites, command line programs; all of them either in a questionnaire style or interactive).
    4.50  \index{sendmail!m4 macros}
    4.51  
    4.52  \paragraph{Performance}
    4.53 @@ -338,7 +332,7 @@
    4.54  
    4.55  Until Unified Communication will become reality---if ever---electronic mail has a good position, also as basis for Unified Messaging.
    4.56  
    4.57 -\paragraph{SWOT analysis}
    4.58 +\paragraph{\NAME{SWOT} analysis}
    4.59  Not only the market influences email's future safety, but also must the email technology itself evolve to satisfy upcoming needs. Actions to take were discovered by using the \NAME{SWOT} analysis. These are: Prepare against spam. Search solutions for large data transfers and increasing growth and ramification of networks. Exploit standardization, modularity, and extendability.
    4.60  
    4.61  \paragraph{Trends}
    4.62 @@ -350,8 +344,7 @@
    4.63  \MTA{}s might become more commodity software, like web servers already are today, with the purpose to be included in many systems with only minimal configuration.
    4.64  
    4.65  
    4.66 -\masqmail\ is a valuable program for various situations. Some setups became rare, but others are expected to become popular in the next years. \masqmail's niche will rather grow than shrink.
    4.67 -%fixme: rewrite that last sentence; add a new heading ``conclusion''? think about it!
    4.68 +\masqmail\ is a valuable program for various situations. Some setups became rare, but others are expected to become popular in the next years. It is expected that \masqmail's niche will rather grow than shrink.
    4.69  
    4.70  
    4.71  

     5.1 --- a/thesis/tex/3-MailTransferAgents.tex	Sat Feb 07 14:47:27 2009 +0100
     5.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Sat Feb 07 19:00:25 2009 +0100
     5.3 @@ -73,7 +73,7 @@
     5.4  
     5.5  \MTA{}s can also be split in other ways.
     5.6  
     5.7 -Due to \sendmail's significance in the early times of email, compatibility interfaces to \sendmail\ are important for Unix \MTA{}s. The reason is that many mail applications simply assume the \sendmail\ \MTA\ to be installed on the system. Being not \name{sendmail-compatible} may not matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on Unix systems. Hence being sendmail-compatible is a major property of an \MTA. \MTA{}s without \name{sendmail-compatible} interfaces, or at least compatibility add-ons, will not be covered here. One example for such a program is \name{Apache James}.  %FIXME: check if correct
     5.8 +Due to \sendmail's significance in the early times of email, compatibility interfaces to \sendmail\ are important for Unix \MTA{}s. The reason is that many mail applications simply assume the \sendmail\ \MTA\ to be installed on the system. Being not \name{sendmail-compatible} may not matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on Unix systems. Hence being sendmail-compatible is a major property of an \MTA. \MTA{}s without \name{sendmail-compatible} interfaces, or at least compatibility add-ons, will not be covered here. One example for such a program is \name{Apache James}.
     5.9  \index{sendmail!compatibility}
    5.10  
    5.11  Another separation can be done between Free Software \MTA{}s and proprietary ones. Many of the \MTA{}s for Unix systems are Free Software. Only these are regarded throughout this thesis, because comparing Free Software with proprietary or commercial software is not what typical users of programs like \masqmail\ do. Comparison with non-free programs may be a point for large Free Software projects that try to step into the business world. Small projects, mostly used by individuals at home, need to be compared against other projects of similar shape. The document is seen from \masqmail's point of view---an \MTA\ for Unix systems on home servers and workstations---so non-free software is out of the way.

     6.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 14:47:27 2009 +0100
     6.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 19:00:25 2009 +0100
     6.3 @@ -39,9 +39,7 @@
     6.4  \label{sec:functional-requirements}
     6.5  \index{functional requirements}
     6.6  
     6.7 -Functional requirements are about the function of the software. They define what the program can do and in what way.
     6.8 -%fixme: add ref
     6.9 -The requirements are named ``\NAME{RF}'' for ``requirement, functional''.
    6.10 +Functional requirements are about the function of the software. They define what the program can do and in what way. The requirements are named ``\NAME{RF}'' for ``requirement, functional''.
    6.11  
    6.12  
    6.13  \paragraph{\RF\,1: Incoming and outgoing channels}
    6.14 @@ -58,7 +56,6 @@
    6.15  \index{outgoing channels}
    6.16  \index{uucp}
    6.17  
    6.18 -%fixme: is the def of MTA: transfer between machines, or transfer between users?
    6.19  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 this job. 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.
    6.20  \index{local delivery}
    6.21  
    6.22 @@ -241,9 +238,7 @@
    6.23  \subsection{Non-functional requirements}
    6.24  \index{non-functional requirement}
    6.25  
    6.26 -Now follows a list of non-functional requirements for \masqmail. These requirements specify the quality properties of a 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}.
    6.27 -%fixme: refer to ch01 and ch02
    6.28 -These non-functional requirements are named ``\NAME{RG}'' for ``requirement, general''.
    6.29 +Now follows a list of non-functional requirements for \masqmail. These requirements specify the quality properties of a 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}. These non-functional requirements are named ``\NAME{RG}'' for ``requirement, general''.
    6.30  
    6.31  
    6.32  \paragraph{\RG\,1: Security}
    6.33 @@ -309,7 +304,6 @@
    6.34  \index{usability}
    6.35  Usability, not mentioned by \person{Hafiz} \cite{hafiz05} (he focuses on architecture) but by \person{Spinellis} \cite{spinellis06} and \person{Kan} \cite{kan03}, is a property which is 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; 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 the focus should be on the most common form of configuration: choosing one of several common setups.
    6.36  
    6.37 -%fixme: << masqmail as portable app? >>
    6.38  
    6.39  
    6.40  
    6.41 @@ -317,10 +311,7 @@
    6.42  \label{sec:discussion-mta-arch}
    6.43  \index{architecture}
    6.44  
    6.45 -%fixme: what's this section to do with requirements?
    6.46 -
    6.47 -\masqmail's current architecture is monolithic like \sendmail's and \exim's. But more than the other two is it one block of interweaved code. \exim\ has a highly structured code with many internal interfaces, a good example is the interface for authentication ``modules''. %fixme: add ref
    6.48 -\sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules. \masqmail\ has none of them---it is what \sendmail\ was in the beginning: a single large block.
    6.49 +\masqmail's current architecture is monolithic like \sendmail's and \exim's. But more than the other two is it one block of interweaved code. \exim\ has a highly structured code with many internal interfaces, a good example is the interface for authentication ``modules''. \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules. \masqmail\ has none of them---it is what \sendmail\ was in the beginning: a single large block.
    6.50  \index{milter}
    6.51  \index{masqmail!architecture}
    6.52  
    6.53 @@ -364,7 +355,6 @@
    6.54  
    6.55  Hence, aspiration for modularity, by compartmentalization, improves the overall quality and function of the software. It can be seen as an architectural requirement for a secure and modern \MTA.
    6.56  
    6.57 -%fixme: explain: why are compartments and interfaces so good?
    6.58  
    6.59  
    6.60  
    6.61 @@ -385,7 +375,7 @@
    6.62  \index{outgoing channels}
    6.63  The incoming and outgoing channels that \masqmail\ already has (depicted in figure~\ref{fig:masqmail-channels} on page \pageref{fig:masqmail-channels}) are the ones required for an \MTA{}s at the moment. Currently, support for other protocols seems not to be necessary, although new protocols and mailing concepts are likely to appear (see section~\ref{sec:email-trends}). As other protocols are not required today, \masqmail\ is regarded to fulfill \RF\,1. Without any support in \masqmail\ for adding further protocols, the best strategy is to delaying such work until the functionality is essential, anyway.
    6.64  
    6.65 -%fixme: << smtp submission >> %fixme
    6.66 +%fixme: << smtp submission >>
    6.67  
    6.68  \paragraph{\RF\,2: Queuing}
    6.69  \index{mail queue}
    6.70 @@ -446,13 +436,11 @@
    6.71  \hfill\citeweb{masqmail:homepage2}
    6.72  \end{quote}
    6.73  
    6.74 -In summary: Current reliability needs to be improved.
    6.75 -%fixme: state machine
    6.76 +In summary: Current reliability needs to be improved. Implementing a state machine can help here.
    6.77  
    6.78  \paragraph{\RG\,3: Robustness}
    6.79  \index{robustness}
    6.80  The logging behavior of \masqmail\ is good, although it does not cover the whole code. 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.
    6.81 -%fixme: rule of robustness, rule of repair
    6.82  
    6.83  \paragraph{\RG\,4: Extendability}
    6.84  \index{extendability}
    6.85 @@ -471,7 +459,6 @@
    6.86  Two additional scripts exist to send a set of mails to differend kinds of recipients. They can be used for automated testing, but both check only the function of the whole system, not its parts.
    6.87  \index{test program}
    6.88  
    6.89 -%fixme: think about clean-room testing
    6.90  
    6.91  \paragraph{\RG\,7: Performance}
    6.92  \index{performance}
    6.93 @@ -679,7 +666,7 @@
    6.94  
    6.95  Adding new functionality to an existing code base seems to be a secure and cheap strategy. The existing code is known to work and features can often be added in small increments. Risks like wasted effort if a new design fails are hardly existent, and the faults in the current design are already made and most probably fixed.
    6.96  
    6.97 -Functionality that is hard to add incrementally into the application, like support for new protocols, may be addable to the outside. \masqmail\ can be secured to a huge amount by guarding it with wrappers that block attackers. Spam and malware scanners can be included by running two instances of \masqmail. All those methods base on the current code which they can indirectly improve.
    6.98 +Functionality that is hard to add incrementally into the application, like support for new protocols, may be addable to the outside. \masqmail\ can be secured to a huge amount by guarding it with wrappers that block attackers \cite[page~71]{graff03}. Spam and malware scanners can be included by running two instances of \masqmail. All those methods base on the current code which they can indirectly improve.
    6.99  \index{wrapper}
   6.100  \index{extendability}
   6.101  
   6.102 @@ -717,7 +704,7 @@
   6.103  Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail, which had an almost monopoly for a long time. But when security became important, \sendmail\ was only repaired instead of the problem sources---its insecure design---would have been removed. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. \sendmail's reaction to the new requirements, in form of \name{sendmail~X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s.
   6.104  \index{sendmail}
   6.105  
   6.106 -Redesigning a software as requirements change helps keeping it alive. % fixme: add quote: ``one thing surely remains: change'' (something like that)
   6.107 +Redesigning a software as requirements change helps keeping it alive. The knowledge of the Greek philosopher \person{Heraclitus} shall be an inspriation: ``Nothing endures but change.''
   6.108  \index{redesign}
   6.109  
   6.110  Another danger is the dead end of complexity which is likely to appear by constant work on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} for example advertises such a philosophy of small and simple software by following the thoughts of the Unix inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code avoids complexity and is thus also a strong prerequisite for security.
   6.111 @@ -759,7 +746,7 @@
   6.112  \subsubsection*{Break Even}
   6.113  \index{Break Even}
   6.114  
   6.115 -It is important to keep the time dimension in mind. This includes the  separation into a short-time and a long-time view. The short-time view shall cover between two and four years, here. The long-time view is the following time. % fixme: find sources!
   6.116 +It is important to keep the time dimension in mind. This includes the  separation into a short-time and a long-time view. The short-time view shall cover between two and four years, here. The long-time view is the following time.
   6.117  
   6.118  In the short-time view, the effort for improving the existing code is much smaller than the effort for a new design plus improvements. But to have similar quality properties at the end of the short-time frame, a version that is based on current code will probably require nearly as much effort as a new designed version will take. For all further development afterwards, the new design will scale well while the old code will require exponential more work.
   6.119  \index{existing code}
   6.120 @@ -778,12 +765,11 @@
   6.121  Quality improvement is no popular work, but it is required to avoid dead ends. As more code increases the work that needs to be done for quality and modularity improvements, it is better to do these improvements early. Afterwards, all further development will profit from it.
   6.122  \index{quality improvement}
   6.123  
   6.124 -Also, if some design is bad one should never hesitate to erase it and rebuild it in a sane way.
   6.125 -%fixme: doubled speech!
   6.126 +If some design is bad, it should get replaced by a sane solution.
   6.127  
   6.128 -Again \person{Doug McIlroy} gives valuable advice: ``Don't hesitate to throw away the clumsy parts and rebuild them.'' \cite{mcilroy78}.
   6.129 +\person{Doug McIlroy} gives valuable advice for these situations: ``Don't hesitate to throw away the clumsy parts and rebuild them.'' \cite{mcilroy78}.
   6.130  
   6.131 -However, making such a cut is hard, especially if the bad design is still \dots\ ``good enough''.
   6.132 +Though, making such a cut is hard, especially if the bad design is still \dots\ ``good enough''.
   6.133  
   6.134  
   6.135  

     7.1 --- a/thesis/tex/5-Improvements.tex	Sat Feb 07 14:47:27 2009 +0100
     7.2 +++ b/thesis/tex/5-Improvements.tex	Sat Feb 07 19:00:25 2009 +0100
     7.3 @@ -75,7 +75,6 @@
     7.4  \index{sasl}
     7.5  
     7.6  \begin{quote}
     7.7 -%None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.
     7.8  None of these [authentication methods] is an ideal solution. They require additional code compiled into your existing daemons that may then require special write access to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users.
     7.9  \hfill\cite[page~44]{dent04}
    7.10  \end{quote}
    7.11 @@ -106,7 +105,6 @@
    7.12  For a small \MTA\ like \masqmail, it seems preferable to store the login data in a text file under \masqmail's control. This is the most simple choice for many usage scenarios. But using a central authentication facility has advantages in larger setups, too. \name{Cyrus} \NAME{SASL} supports both, so there is no problem. If \name{gsasl} is chosen, it seems best to start with an authentication file under \masqmail's control.
    7.13  
    7.14  
    7.15 -%fixme: << how could this be covered by architecture (e.g. smtp submission). >>
    7.16  
    7.17  
    7.18  
    7.19 @@ -204,7 +202,6 @@
    7.20  \end{enumerate}
    7.21  \index{compartmentalization}
    7.22  
    7.23 -%fixme: << conditional compilation >>
    7.24  
    7.25  
    7.26  \subsubsection*{Incoming channels}
    7.27 @@ -213,8 +210,7 @@
    7.28  The functional requirements for incoming channels were already discussed as \RF\,1 on page~\pageref{rf1}. Two required incoming channels were identified: the \path{sendmail} command for local mail submission and the \SMTP\ daemon for remote connections.
    7.29  \index{sendmail!command}
    7.30  
    7.31 -A bit different is the structure of \name{sendmail~X} at that point: Locally submitted messages go also to the \SMTP\ daemon, which is the only connection to the mail queue. %fixme: is it a smtp dialog? or a back door?
    7.32 -\person{Finch} proposes a similar approach \cite{finch-sendmail}: He wants the \path{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA, like it is done by connections from remote. The advantage here is to have one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid}, because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
    7.33 +A bit different is the structure of \name{sendmail~X} at that point: Locally submitted messages go also to the \SMTP\ daemon, which is the only connection to the mail queue. \person{Finch} proposes a similar approach \cite{finch-sendmail}: He wants the \path{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA, like it is done by connections from remote. The advantage here is to have one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid}, because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
    7.34  \index{sendmailx}
    7.35  \index{smtp}
    7.36  \index{setuid}
    7.37 @@ -282,8 +278,7 @@
    7.38  \qmail\ has the principle of ``don't parse'' which propagates the avoidance of parsing as much as possible. The reason is that parsing is a highly complex task which likely makes code exploitable.
    7.39  \index{qmail}
    7.40  
    7.41 -In \masqmail's new design, mail should be stored into the queue without parsing. A scanning module should then parse the message with high care. It seems best to use a \name{parser generator}\footnote{\person{Stephen~C.\ Johnson}'s paper about \name{yacc} is a good introduction into \name{parser generators} \cite{johnson79}.} for this work. The parsed data should then get modified if needed and written into a second queue. This approach has several advantages. First, the receiving parts of the system are independent from content, they simply store it into the queue. Second, one single module does the parsing and generates new messages that contain only valid data. Third, the sending parts of the system will thus only work on messages that consist of valid data. Of course, it must be ensured that each message passes through the \name{scanning} module, but this is already required for spam and malware scanning.
    7.42 -%fixme: ref for parser generator
    7.43 +In \masqmail's new design, mail should be stored into the queue without parsing. A scanning module should then parse the message with high care. \person{Spinellis} proposes reliable approaches to do this work \cite[pages~17--18]{spinellis06}; using a \name{parser generator}\footnote{\person{Stephen~C.\ Johnson}'s paper about \name{yacc} is a good introduction into \name{parser generators} \cite{johnson79}.} is the best solution here. The parsed data should then get modified if needed and written into a second queue. This approach has several advantages. First, the receiving parts of the system are independent from content, they simply store it into the queue. Second, one single module does the parsing and generates new messages that contain only valid data. Third, the sending parts of the system will thus only work on messages that consist of valid data. Of course, it must be ensured that each message passes through the \name{scanning} module, but this is already required for spam and malware scanning.
    7.44  \index{parser generator}
    7.45  
    7.46  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.
    7.47 @@ -310,8 +305,7 @@
    7.48  \subsubsection*{Route management}
    7.49  \index{online routes}
    7.50  
    7.51 -The online state is only important for the sending modules of the system, thus it should be queried in the \name{queue-out} module which selects ready messages from the \name{outgoing} queue and transfers them to the appropriate sending module. Route-based aliasing, which was described in the last section, %fixme: is this still true?
    7.52 -should be done in the same go.
    7.53 +The online state is only important for the sending modules of the system, thus it should be queried in the \name{queue-out} module which selects ready messages from the \name{outgoing} queue and transfers them to the appropriate sending module. Route-based aliasing, which was described in the last section, should be done in the same go.
    7.54  
    7.55  
    7.56  
    7.57 @@ -431,6 +425,7 @@
    7.58  \paragraph{Receiver modules}
    7.59  \index{incoming channels}
    7.60  They are the communication interface between external senders and the \name{queue-in} module. Each protocol needs a corresponding \name{receiver module} to be supported. Most popular is the \name{sendmail} module, which is a command to be called from the local host, and the \name{smtpd} module which usually listens on port 25. Other modules to support other protocols may be added as needed. Receiving modules that need to listen on ports should get invoked by \name{inetd}, or by \person{Bernstein}'s more secure \name{ucspi-tcp}. This makes it possible to run them with least privilege.
    7.61 +\index{least privilege}
    7.62  
    7.63  
    7.64  \paragraph{The \name{queue-in} module}
    7.65 @@ -534,7 +529,7 @@
    7.66  Another possibility is to run a master process as daemon which starts and restarts the system parts. \postfix\ has such a master process, \qmail\ lacks it. The jobs of a master process can be done by other tools of the operating system too, thus making a master process abdicable. \masqmail\ does probably better go without a master process, because it aims to save resources, not to get the best performance.
    7.67  \index{master process}
    7.68  
    7.69 -A sane permission management is very important for secure software in general. The \name{principle of least privilege}, as it is often called, should be respected. If it is possible to use lower privilege then it should be done. An example for doing so is the \name{smtpd} module. It is a server module which listens on a port. One way is to start it as root and let it bind to the port and drop all privilege before it does any other work. But root privilege is avoidable completely if \name{inetd}, or one of its substitutes, listens on the port instead of the \name{smtpd} module. \name{inetd} will then launch the \name{smtpd} module to handle the connection whenever a connection attempt to the port is made. The \name{smtpd} module needs no privilege at all this way.
    7.70 +A sane permission management is very important for secure software in general. The \name{principle of least privilege} \cite[section~I.A.3.f]{saltzer75}, as it is often called, should be respected. If it is possible to use lower privilege then it should be done. An example for doing so is the \name{smtpd} module. It is a server module which listens on a port. One way is to start it as root and let it bind to the port and drop all privilege before it does any other work. But root privilege is avoidable completely if \name{inetd}, or one of its substitutes, listens on the port instead of the \name{smtpd} module. \name{inetd} will then launch the \name{smtpd} module to handle the connection whenever a connection attempt to the port is made. The \name{smtpd} module needs no privilege at all this way.
    7.71  
    7.72  
    7.73  

     8.1 --- a/thesis/tex/abstract.tex	Sat Feb 07 14:47:27 2009 +0100
     8.2 +++ b/thesis/tex/abstract.tex	Sat Feb 07 19:00:25 2009 +0100
     8.3 @@ -34,7 +34,6 @@
     8.4  
     8.5  	\vspace{1ex}
     8.6  	This document was typeset in Palatino and Computer Modern font, using the LaTeX document preparation system on machines running the Debian GNU/Linux operating system. Text editing was done with Vim. The PIC language and troff were used to generate the diagrams, in exception of figure \ref{fig:masqmail-arch} which was produced with Egypt and GraphVis. Mercurial was chosen for version control. Further programs and scripts were used for minor tasks---it was all Free Software, though.
     8.7 -%FIXME: check programs used
     8.8  
     8.9  	\vspace{1ex}
    8.10  	The final version of this thesis, in Portable Document Format and PostScript as well as the complete source code, can be retrieved from my website: http://marmaro.de/docs\,.

     9.1 --- a/thesis/tex/official.tex	Sat Feb 07 14:47:27 2009 +0100
     9.2 +++ b/thesis/tex/official.tex	Sat Feb 07 19:00:25 2009 +0100
     9.3 @@ -17,4 +17,3 @@
     9.4  \vspace{36ex}
     9.5  
     9.6  Breitingen, 2009-02-09 \hfill \person{Markus Schnalke}
     9.7 -%FIXME: insert correct date