1.1 --- a/thesis/tex/0-preface.tex	Sat Jan 31 21:39:53 2009 +0100
     1.2 +++ b/thesis/tex/0-preface.tex	Mon Feb 02 12:04:32 2009 +0100
     1.3 @@ -14,7 +14,7 @@
     1.4  
     1.5  I decided to start at the basis and analyze the environment and \masqmail\ throughout to end up in concrete plans of what should be done and how it should be done to turn \masqmail\ into a modern mail transfer agent again.
     1.6  
     1.7 -The actual implementation of the the proposed changes will follow-up this thesis. Here solutions are identified, described, discussed, and recommended but not implemented. I have been working in the code and have fixed bugs during the time I worked on the thesis, though.
     1.8 +The actual implementation of the proposed changes will follow-up this thesis. Here solutions are identified, described, discussed, and recommended but not implemented. I have been working in the code and have fixed bugs during the time I worked on the thesis, though.
     1.9  
    1.10  \quad
    1.11  

     2.1 --- a/thesis/tex/1-Introduction.tex	Sat Jan 31 21:39:53 2009 +0100
     2.2 +++ b/thesis/tex/1-Introduction.tex	Mon Feb 02 12:04:32 2009 +0100
     2.3 @@ -52,7 +52,7 @@
     2.4  
     2.5  A selection of important concepts of \SMTP\index{smtp!concepts of} is explained here.
     2.6  
     2.7 -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 gets stored for some time on each \MTA, until it is forwarded to the next \MTA.
     2.8 +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.9  
    2.10  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.11  
    2.12 @@ -76,7 +76,7 @@
    2.13  
    2.14  Each \MTA\ on the way reads envelopes it receives and generates new ones. If a message has recipients on different hosts, then the message gets copied and sent within multiple envelopes, one for each host.
    2.15  
    2.16 -The sample message would would lead to two envelopes\index{mail message!more envelopes}, one from \name{markus@host01} to \name{alice@host02}, the other from \name{markus@host01} to \name{bob@host03}. Both envelopes would contain the same message.
    2.17 +The sample message would lead to two envelopes\index{mail message!more envelopes}, one from \name{markus@host01} to \name{alice@host02}, the other from \name{markus@host01} to \name{bob@host03}. Both envelopes would contain the same message.
    2.18  
    2.19  
    2.20  
    2.21 @@ -114,7 +114,7 @@
    2.22  In these cases, MasqMail is a slim replacement for full-blown \MTA{}s such as sendmail, exim, qmail or postfix.
    2.23  \hfill\citeweb{packages.debian:masqmail}
    2.24  \end{quote}
    2.25 -The program is a good replacement ``in these cases'', but not generally, since is lacks essential features for running on mail servers. It is primarily not secure enough for being accessible from untrusted locations.
    2.26 +The program is a good replacement ``in these cases'', but not generally, since it lacks essential features for running on mail servers. It is primarily not secure enough for being accessible from untrusted locations.
    2.27  
    2.28  \masqmail\ is best used in home networks, which are non-permanently connected to the Internet. 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 being online connection. These features are explained in more detail in the following \name{Features} section on page \ref{sec:masqmail-features}. %fixme: is it still called ``features''?
    2.29  
    2.30 @@ -126,7 +126,7 @@
    2.31  
    2.32  \subsubsection*{Typical usage scenarios}
    2.33  
    2.34 -This section describes three common setups that makes sensible use of \masqmail. The first two are shown in figure \ref{fig:masqmail-typical-usage}.
    2.35 +This section describes three common setups that make sensible use of \masqmail. The first two are shown in figure \ref{fig:masqmail-typical-usage}.
    2.36  
    2.37  \begin{figure}
    2.38  	\begin{center}
    2.39 @@ -154,7 +154,7 @@
    2.40  \end{description}
    2.41  
    2.42  
    2.43 -In general, all kinds of usage scenarios within a trusted network are possible. Important to notice is that mail can not be send from outside into the trusted network then. For using \masqmail\ on notebooks it is suggested to only accept mail from local users because notebooks are often in untrusted environments.
    2.44 +In general, all kinds of usage scenarios within a trusted network are possible. Important to notice is that mail can not be sent from outside into the trusted network then. For using \masqmail\ on notebooks it is suggested to only accept mail from local users because notebooks are often in untrusted environments.
    2.45  
    2.46  
    2.47  
    2.48 @@ -187,7 +187,7 @@
    2.49  
    2.50  \subsection{Features}
    2.51  
    2.52 -Here regarded is version 0.2.21 of \masqmail. This is the last version released by \person{Oliver Kurth}.
    2.53 +This thesis regards version 0.2.21 of \masqmail. This is the last version released by \person{Oliver Kurth}.
    2.54  
    2.55  
    2.56  \subsubsection*{The source code}
    2.57 @@ -234,7 +234,7 @@
    2.58  
    2.59  Mail queuing is essential for \masqmail\ and thus supported of course, alias expansion is also supported.
    2.60  
    2.61 -The \masqmail\ executable can be called by various names for sendmail-compatibility reasons. As many programs expect the \MTA\ to be located at \path{/usr/lib/sendmail} or \path{/usr/sbin/sendmail}, symbolic links are pointing from there to the \masqmail\ executable. Further more does \sendmail\ supports calling it with a different name instead of supplying command line arguments. The best known of these 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 yet 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 strict requirements.} \path{hoststat} and \path{purgestat} are missing for complete sendmail-compatibility.
    2.62 +The \masqmail\ executable can be called by various names for sendmail-compatibility reasons. As many programs expect the \MTA\ to be located at \path{/usr/lib/sendmail} or \path{/usr/sbin/sendmail}, symbolic links are pointing from there to the \masqmail\ executable. Furthermore does \sendmail\ supports calling it with a different name instead of supplying command line arguments. The best known of these 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 yet 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 strict requirements.} \path{hoststat} and \path{purgestat} are missing for complete sendmail-compatibility.
    2.63  %masqmail: mailq, mailrm, runq, rmail, smtpd/in.smtpd
    2.64  %sendmail: hoststat, mailq, newaliases, purgestat, smtpd
    2.65  
    2.66 @@ -259,7 +259,7 @@
    2.67  \item Querying an \name{mserver} system
    2.68  \end{enumerate}
    2.69  
    2.70 -Each method may return a string naming the routes that is online or returning nothing to indicate offline state.
    2.71 +Each method may return a string naming the route that is online or returning nothing to indicate offline state.
    2.72  
    2.73  
    2.74  Mail for hosts inside the local network or for users on the local machine is not touched by this concept; such mail is always sent immediately.

     3.1 --- a/thesis/tex/2-MarketAnalysis.tex	Sat Jan 31 21:39:53 2009 +0100
     3.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Mon Feb 02 12:04:32 2009 +0100
     3.3 @@ -9,7 +9,7 @@
     3.4  
     3.5  Electronic communication is ``communication by computer'', according to the \name{WordNet} database of \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} describes electronic communication as ``System for the transmission of information using electronic technology (e.g., digital cameras, cellular telephones, Internet, television, fiber optics).'' \citeweb{science-glossary-pa}.
     3.6  
     3.7 -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, electronic communication is also cheap communication. As underlying transport infrastructure, primary the Internet is used; 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.8 +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, electronic communication is 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.9  
    3.10  As globalization proceeds and long distance communication becomes more and more important, the future for electronic communication is bright.
    3.11  
    3.12 @@ -41,7 +41,7 @@
    3.13  
    3.14  
    3.15  \subsection{Life cycle analysis}
    3.16 -Life cycle analysis are common for products but also for technologies. This one here is for electronic communication technologies. The first dimensions regarded is the life time of the subject. It is segmented into the introduction, growth, mature, saturation, and decline phases. The second dimension can display market share, importance, or similar values. The graph has always an S-line shape, with a slow start, a rapidly increasing first half, the highest level in the fourth phase, and a slowly declining end. Reaching the end of the life cycle means, the subject gets inherited by successors or the market situation changed thus it is old fashioned.
    3.17 +Life cycle analysis are common for products but also for technologies. This one here is for electronic communication technologies. The first dimension regarded is the life time of the subject. It is segmented into the introduction, growth, mature, saturation, and decline phases. The second dimension can display market share, importance, or similar values. The graph has always an S-line shape, with a slow start, a rapidly increasing first half, the highest level in the fourth phase, and a slowly declining end. Reaching the end of the life cycle means, the subject gets inherited by successors or the market situation changed thus it is old fashioned.
    3.18  
    3.19  The current position on the life cycle of some selected communication technologies is depicted in figure \ref{fig:comm-lifecycle}. It is important to notice that the time dimension can be different for each technology---some life cycles are shorter than others---the shape of the graph, however, is the same.
    3.20  
    3.21 @@ -182,7 +182,7 @@
    3.22  \subsection{Trends for electronic mail}
    3.23  \label{sec:email-trends}
    3.24  
    3.25 -Noting remains the same, so does the email technology not. Emailing in future will probably differ from emailing today. This section tries to identify possible trends affecting the future of electronic mail.
    3.26 +Nothing remains the same, so does the email technology not. Emailing in future will probably differ from emailing today. This section tries to identify possible trends affecting the future of electronic mail.
    3.27  
    3.28  
    3.29  \subsubsection*{Provider independence}
    3.30 @@ -190,9 +190,9 @@
    3.31  
    3.32  Outgoing mail is send either with the web mail client of the provider or using \name{mail user agent}s sending it to the provider for relay. Incoming mail is read with the web mail client or retrieved from the provider via \NAME{POP3} or \NAME{IMAP} to the local computer to be read using the \name{mail user agent}. This means all mail sending and receiving work is done by the provider.
    3.33  
    3.34 -The reason therefor is originated in the time when people used dial-up connections to the Internet. A mail server needs to be online to receive email. Sending mail is no problem, but receiving it is hardly possible with an \MTA\ being few time online. Internet service providers had servers running all day long connected to the Internet. So they offered email service, and they still do.
    3.35 +The reason therefore is originated in the time when people used dial-up connections to the Internet. A mail server needs to be online to receive email. Sending mail is no problem, but receiving it is hardly possible with an \MTA\ being few time online. Internet service providers had servers running all day long connected to the Internet. So they offered email service, and they still do.
    3.36  
    3.37 -Nowadays, dial-up Internet access became rare; the majority has broadband Internet access paying a flat rate for it. Hence the time being online not affect costs anymore, even traffic is unlimited. Today it is possible to have an own mail server running at home. The technical problem remaining is the changing \NAME{IP} addresses one gets assigned every 24 hours. 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.38 +Nowadays, dial-up Internet access became rare; the majority has broadband Internet access paying a flat rate for it. Hence 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 technical problem remaining is the changing \NAME{IP} addresses one gets assigned every 24 hours. 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.39  
    3.40  Home servers become popular for central data storage and multimedia services, these days. Being assembled of energy efficient elements, 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.41  
    3.42 @@ -235,7 +235,7 @@
    3.43  
    3.44  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-prove, to 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 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.
    3.45  
    3.46 -Complex configuration itself is not a problem if simplification wrappers around it do 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
    3.47 +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
    3.48  It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. \sendmail\ took this approach with the \name{m4} macros. %fixme: add ref
    3.49  Further more is it 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).
    3.50  
    3.51 @@ -267,7 +267,7 @@
    3.52  
    3.53  %The trends in the communication market are consolidation, integration, and the merge of communication hardware. All this goes along with market's change to Unified Messaging.
    3.54  
    3.55 -Unified Communication, as next step after Unified Messaging, is about the integration of asynchronous an synchronous communication channels. It seems impossible to merge the two worlds on basis of email in an evolutionary way. As only a revolutionary change of the whole email concept would make that merge possible, it is best to ignore it. New designed technologies are usually superior to heavily patched and bent old technologies, anyway. A general merge of synchronous and asynchronous communication has good chances to be fatal for email.
    3.56 +Unified Communication, as next step after Unified Messaging, is about the integration of synchronous and asynchronous communication channels. It seems impossible to merge the two worlds on basis of email in an evolutionary way. As only a revolutionary change of the whole email concept would make that merge possible, it is best to ignore it. New designed technologies are usually superior to heavily patched and bent old technologies, anyway. A general merge of synchronous and asynchronous communication has good chances to be fatal for email.
    3.57  
    3.58  Until Unified Communication will become reality---if ever---electronic mail has a good position, also as basis for Unified Messaging.
    3.59  

     4.1 --- a/thesis/tex/3-MailTransferAgents.tex	Sat Jan 31 21:39:53 2009 +0100
     4.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Mon Feb 02 12:04:32 2009 +0100
     4.3 @@ -204,7 +204,7 @@
     4.4  
     4.5  Monolithic \MTA{}s are \sendmail, \name{smail}, \exim, and \masqmail. They all consist of one single \emph{setuid root}\footnote{\emph{setuid root} lets a program run with the rights of its owner, here root. This is considered to be a security risk. Thus it it should be avoided if possible.} binary which does all the work.
     4.6  
     4.7 -Modular \MTA{}s are \NAME{MMDF}, \qmail, \postfix, and \name{MeTA1}. They consist of several programs, each doing a part of the overall job. The different programs run with the least permissions the need, and \emph{setuid root} can be avoided completely.
     4.8 +Modular \MTA{}s are \NAME{MMDF}, \qmail, \postfix, and \name{MeTA1}. They consist of several programs, each doing a part of the overall job. The different programs run with the least permissions they need, and \emph{setuid root} can be avoided completely.
     4.9  
    4.10  The architecture does not directly define the program's security, but ``[t]he goal of making a software secure can be better achieved by making the design simple and easier to understand and verify'' \cite[chapter 6]{hafiz05}. \exim, though being monolithic, has a fairly clean security record. But it is very hard to keep the security up, as the program growth. \person{Wietse Venema} (the author of \postfix) says, it was the architecture that enabled \postfix\ to grow without running into security problems. \cite[page 13]{venema:postfix-growth}
    4.11  
    4.12 @@ -217,7 +217,7 @@
    4.13  
    4.14  Spam and malware increased during the last years. Today it is important for an \MTA\ to be able to provide checking for bad mail. This can be done by implementing functionality into the \MTA, or by invoking external programs to do this job.
    4.15  
    4.16 -\sendmail\ invented \name{milter} which is the common abbreviation for the \name{sendmail mail filter} \NAME{API}. It is used to interface external programs of various kind. \postfix\ adopted the \name{milter} interface, but is also able to easily include scanning modules into its modular structure. \qmail\ is pretty old and did not evolve with the changing market situation. Anyhow, its modular structure enables external scanners to be included into \qmail. \exim\ has the advantage that is was designed with the goal to provide extensive scanning facilities. It is therefore very good suited to scan itself or invoke external scanners.
    4.17 +\sendmail\ invented \name{milter} which is the common abbreviation for the \name{sendmail mail filter} \NAME{API}. It is used to interface external programs of various kind. \postfix\ adopted the \name{milter} interface, but is also able to easily include scanning modules into its modular structure. \qmail\ is pretty old and did not evolve with the changing market situation. Anyhow, its modular structure enables external scanners to be included into \qmail. \exim\ has the advantage that it was designed with the goal to provide extensive scanning facilities. It is therefore very good suited to scan itself or invoke external scanners.
    4.18  
    4.19  
    4.20  \subsubsection*{Provider independence}
    4.21 @@ -228,7 +228,7 @@
    4.22  
    4.23  \subsubsection*{Performance}
    4.24  
    4.25 -As second trend, the decreasing necessity for high performance was identified. This goes along with the move of \MTA{}s from service providers to home servers. \postfix\ focuses much on performance, this might not be an important point in the future. Of course there still will be the need for high performance \MTA{}s, but a growing share of the market will not require high performance. Energy and space efficiency is related to performance; it is a similar goal in a different direction. Optimization, be it for performance or other efficiencies, is often in contrast to simplicity and clarity, which effect security. Optimizing does in most times decrease the simplicity and clarity. Simple \MTA{}s not aiming for high performance are what is needed in future. The simple design of \qmail (\qmail\ is still fast) seems to be a good example.
    4.26 +As second trend, the decreasing necessity for high performance was identified. This goes along with the move of \MTA{}s from service providers to home servers. \postfix\ focuses much on performance, this might not be an important point in the future. Of course there still will be the need for high performance \MTA{}s, but a growing share of the market will not require high performance. Energy and space efficiency is related to performance; it is a similar goal in a different direction. Optimization, be it for performance or other efficiencies, is often in contrast to simplicity and clarity; these two improve security. Optimizing does in most times decrease the simplicity and clarity. Simple \MTA{}s not aiming for high performance are what is needed in future. The simple design of \qmail\footnote{\qmail\ is still fast} is a good example.
    4.27  
    4.28  \subsubsection*{Security}
    4.29  

     5.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Jan 31 21:39:53 2009 +0100
     5.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Mon Feb 02 12:04:32 2009 +0100
     5.3 @@ -10,7 +10,7 @@
     5.4  
     5.5  Should \masqmail\ become more specific to a more narrow niche or rather become more general and move a bit out of its niche? Or should it even become a totally general \MTA\ like \sendmail, \exim, \qmail, and \postfix?
     5.6  
     5.7 -Becoming completely general seems to be no choice because the competitors are too many and they are already too strong. It would require a strong base of developers and superior features to establish. There seems to be no need for another general purpose \MTA\ additional to those four programs. Thus the effort would most likely die a try. \person{Venema} stated ``It is becoming less and less likely that someone will write another full-featured Postfix or Sendmail \MTA\ \emph{from scratch} (100 kloc).'' \cite{venema:postfix-growth}. At least \masqmail\ is not going to try that.
     5.8 +Becoming completely general seems to be no choice because the competitors are too many and they are already too strong. It would require a strong base of developers and superior features to establish. There seems to be no need for another general purpose \MTA\ additional to those four programs. Thus the effort would most likely remain a try. \person{Venema} stated ``It is becoming less and less likely that someone will write another full-featured Postfix or Sendmail \MTA\ \emph{from scratch} (100 kloc).'' \cite{venema:postfix-growth}. At least \masqmail\ is not going to try that.
     5.9  
    5.10  \masqmail\ was intended to be a small ``real \MTA'' which covers the niche of managing the relay over several smart hosts. Small and resource friendly software is still important for workstations, home servers, and especially for embedded computers. Other software that focuses on the same niche is not known. Dial-up connections have become rare but mobile computers that move between different networks are popular. So, the niche is still present.
    5.11