1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/thesis/attic/about-masqmail.tex	Thu Jan 15 12:20:21 2009 +0100
     1.3 @@ -0,0 +1,24 @@
     1.4 +\chapter{About \masqmail}
     1.5 +
     1.6 +%TODO: have text by oliver here
     1.7 +%TODO: let oliver prove read it!
     1.8 +
     1.9 +This chapter describes the history and evolution of \masqmail.
    1.10 +
    1.11 +
    1.12 +\section{History and evolution}
    1.13 +The \masqmail\ program was written by Oliver Kurth, starting in 1999. His aim was to create a \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ handles situations which are rarely solveable with the common \MTA{}s.
    1.14 +
    1.15 +The date of the first release (version 0.0.1) is unknown, but it was packaged for \debian\ at 15\nth\ of September in 1999. Further releases were made every few weeks or month during 2000, 2001 and 2002. Development ended in mid-2003 in a hard stop. The last release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
    1.16 +
    1.17 +During the time of development, Oliver released 53 versions. That means a new release in less than every 20 days in average!
    1.18 +
    1.19 +Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
    1.20 +
    1.21 +One extra release (version 0.2.21) was made by him in November 2005. This one is only available from the \debian\ pool. Comparing it to version 0.2.20 shows, that no source code was altered. Only building documents (like Makefiles) and \debian\ packageing documents were changed. That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
    1.22 +
    1.23 +In May 2000 the minor version number increased to `1'. Nothing special is mentioned in the documentation about that. When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail. At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series. His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.
    1.24 +
    1.25 +
    1.26 +\section{\masqmail\ on the web}
    1.27 +

     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/thesis/attic/about-mta.tex	Thu Jan 15 12:20:21 2009 +0100
     2.3 @@ -0,0 +1,35 @@
     2.4 +\chapter{About \name{mail transfer agent}s}
     2.5 +
     2.6 +% TODO: describe content of this chapter here
     2.7 +
     2.8 +
     2.9 +\section{What is a \name{mail transfer agent}?}
    2.10 +The basic job of a \name{mail transfer agent} (or \name{mail transport agent}, short \NAME{MTA}) is to transfer/transport \name{electronic mail} (short \name{email}) from one host to another.
    2.11 +
    2.12 +% TODO: include definitions from others here (cites)
    2.13 +
    2.14 +
    2.15 +\section{History of \NAME{MTA}s}
    2.16 +% FIXME: is that true?
    2.17 +In the old days, the 70s, when Unix was created, computers were expensive. Universities and big firms normally had a single server with an amount of terminals connected to it. The computer filled a whole room somewhere in the cellar. People were operating at the terminals that were located in the offices and wired to the server. At that time, there was hardly no networking at all.
    2.18 +
    2.19 +During the following years, when computers became affordable and so more common (but still no personal computers at that time), connections between single computers were established. Inter-university connections were one of the first networks.
    2.20 +
    2.21 +Electronic mail is a basic concept in Unix. A lot of information gets distributed via system mail on Unix machines. System mail is electronic mail that stays on one machine. In nowadays this is primary notifications from system programs. But back then, there were frequently sent emails between users on the same machine.
    2.22 +
    2.23 +When computers were connected to each other and networks grew, the need appered to send electronic mail from one machine to another. E.g. Alice sitting on a terminal connected to server1 wants to send email to Bob sitting on a terminal connected to server2.
    2.24 +
    2.25 +Unix provided everything for that task, except a good tool to do the mail transport from server1 to server2.
    2.26 +
    2.27 +At that point the fathers of Unix at \name{Bell Labs} wrote the \NAME{UUCP} program and its compagnons. At about the same time in Berkeley a different solution for the same problem was developed: Eric Allman wrote \name{sendmail}.\footnote{To be exact: He wrote \name{delivermail} which he enhanced to \name{sendmail}.}
    2.28 +
    2.29 +
    2.30 +\section{About \name{sendmail}}
    2.31 +\name{sendmail} is the defacto-standard for \name{mail transfer agents}.
    2.32 +
    2.33 +% FIXME: is that true?
    2.34 +It was the first \NAME{MTA} and had no real alternative for a long time.
    2.35 +
    2.36 +All other existing substitutes, which are mainly \name{postfix}, \name{exim}, \name{qmail} and the here regarded \name{masqmail}, mimic \name{sendmail}'s behavior. Especially, they all create a symbolic link named ``sendmail'' pointing to their own executable. This is because a lot of programs assume there is an executable called ``sendmail'' on every computer system.
    2.37 +
    2.38 +Besides being the ``standard'', \name{sendmail} probably is the most scalable and powerful solution for transfering emails and definatly the most flexible one.

     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/thesis/attic/bcg_ansoff.tex	Thu Jan 15 12:20:21 2009 +0100
     3.3 @@ -0,0 +1,53 @@
     3.4 +%\subsubsection*{\NAME{BCG} matrix}
     3.5 +%
     3.6 +%\begin{figure}
     3.7 +%	\begin{center}
     3.8 +%		\begin{verbatim}
     3.9 +% ---------------------------------------------------
    3.10 +%             |                  |                  |
    3.11 +% high market |  ?               | *                |
    3.12 +% growth      |                  |                  |
    3.13 +%             |                  |                  |
    3.14 +% ---------------------------------------------------
    3.15 +%             |                  |                  |
    3.16 +% low market  |  dog             | cow              |
    3.17 +% growth      |                  |                  |
    3.18 +%             |                  |                  |
    3.19 +% ---------------------------------------------------
    3.20 +%             |                  |                  |
    3.21 +%             | small rel.       | large rel.       |
    3.22 +%             | market share     | market share     |
    3.23 +%             |                  |                  |
    3.24 +%		\end{verbatim}
    3.25 +%	\end{center}
    3.26 +%	\caption{\NAME{BCG} matrix for electronic communication}
    3.27 +%	\label{fig:comm-bcg}
    3.28 +%\end{figure}
    3.29 +%
    3.30 +%
    3.31 +%
    3.32 +%\subsubsection*{Ansoff matrix}
    3.33 +%
    3.34 +%\begin{figure}
    3.35 +%	\begin{center}
    3.36 +%		\begin{verbatim}
    3.37 +% ---------------------------------------------------
    3.38 +%             |                  |                  |
    3.39 +% current     | email            | im               |
    3.40 +% products    |                  |                  |
    3.41 +%             |                  |                  |
    3.42 +% ---------------------------------------------------
    3.43 +%             |                  |                  |
    3.44 +% new         | UM               |                  |
    3.45 +% products    |                  |                  |
    3.46 +%             |                  |                  |
    3.47 +% ---------------------------------------------------
    3.48 +%             |                  |                  |
    3.49 +%             | current          | new              |
    3.50 +%             | market           | market           |
    3.51 +%             |                  |                  |
    3.52 +%		\end{verbatim}
    3.53 +%	\end{center}
    3.54 +%	\caption{Ansoff matrix for electronic communication}
    3.55 +%	\label{fig:comm-ansoff}
    3.56 +%\end{figure}

     4.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     4.2 +++ b/thesis/attic/e-comm-trends.tex	Thu Jan 15 12:20:21 2009 +0100
     4.3 @@ -0,0 +1,12 @@
     4.4 +\subsubsection*{Speed}
     4.5 +Communication gets faster in general. Slow mediums as letters get substituted by electronic mail, which is delivered within seconds. Also communication becomes more transmitted through digital channels. This can be seen at the telephone which's information is now more and more transported in bits over the internet link. Also telefaxes are succeeded by email or are transported within email. Instant messaging can be seen as the written couterpart to the telephone; not to substitute it completely, but to be used if it is more useful for the information to transmit.
     4.6 +
     4.7 +Many of the digital communication methods gained success by beeing cheaper than their counterparts. One example here is instant messaging in contrast to the telephone. As phoning costs fell, it became more popular again. The last years showed, that communication cost degreased dropped generally, caused by the transport through digital channels. And nothing to see, that would make them rise again.
     4.8 +
     4.9 +It seems as if in future will be low-cost communication methods available, which will be digitally transmitted.
    4.10 +
    4.11 +
    4.12 +\subsubsection*{Parallel usage}
    4.13 +Regarding the variety of communication methods shows a change, too. Communication systems are more easy to establish today, so more get established. This leads to more methods a person uses. But not only in the amount, also in parallel. For example when two people talk to each other on the phone, one might send a \NAME{URI}\footnote{Uniform Resource Identifier} by email meanwhile, because oral communication is not well suited to exchange such data. Another example for in parallel used communication channels is video chatting. Ony typically sees the other person, talks to it, and additionally has a instant messaging facility for exchanging written information.
    4.14 +
    4.15 +Parallel usage of different kinds of communication channels will be important in future. The most common combinations are one for spoken and one for written information. But one for dialogs and one for sending documents will be important too.

     5.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     5.2 +++ b/thesis/attic/foo.tex	Thu Jan 15 12:20:21 2009 +0100
     5.3 @@ -0,0 +1,152 @@
     5.4 +\chapter{something}
     5.5 +laber. \cite{brooks95}
     5.6 +
     5.7 +Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
     5.8 +incididunt ut labore et dolore magna aliqua. \url{http://marmaro.de/docs} Ut enim ad minim veniam, quis
     5.9 +nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    5.10 +
    5.11 +hallo \path{/usr/local/share/man1234} blubb \name{masqmail} laber bla \NAME{ANSI} laber \NAME{RFCs} laber 
    5.12 +
    5.13 +\begin{code}{label}{caption}
    5.14 +\begin{lstlisting}
    5.15 +127.0.0.1       pantheon.schnalke.local localhost.localdomain
    5.16 +127.0.0.1       localhost pantheon
    5.17 +192.168.0.100   serveme intranet deb deb.marmaro.de deb.prog.marmaro.de
    5.18 +192.168.0.100   hg hg.marmaro.de hg.prog.marmaro.de
    5.19 +	192.168.0.40    kugel
    5.20 +192.168.0.102   karton
    5.21 +192.168.0.103   milk
    5.22 +192.168.0.74    dream
    5.23 +
    5.24 +
    5.25 +# The following lines are desirable for IPv6 capable hosts
    5.26 +::1     ip6-localhost ip6-loopback
    5.27 +\end{lstlisting}
    5.28 +\end{code}
    5.29 +
    5.30 +\section{blubb}
    5.31 +
    5.32 +Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
    5.33 +incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
    5.34 +nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    5.35 +
    5.36 +\begin{code}{}{}
    5.37 +\begin{verbatim}
    5.38 +$ make clean
    5.39 +latexmk -c
    5.40 +This is latexmk, John Collins, 2 June 2004, version: 3.07a.
    5.41 +**** Report bugs etc to John Collins <collins at phys.psu.edu>. ****
    5.42 +\end{verbatim}
    5.43 +\end{code}
    5.44 +
    5.45 +\section{blah}
    5.46 +
    5.47 +Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
    5.48 +incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
    5.49 +nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    5.50 +
    5.51 +Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
    5.52 +fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
    5.53 +culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit
    5.54 +amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore
    5.55 +et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation
    5.56 +ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor
    5.57 +in reprehenderit in voluptate velit esse. Cillum dolore eu fugiat nulla
    5.58 +pariatur.
    5.59 +
    5.60 +Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia
    5.61 +deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur
    5.62 +adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
    5.63 +aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
    5.64 +ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
    5.65 +voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
    5.66 +occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim\index{Texteditor}
    5.67 +id est laborum.
    5.68 +
    5.69 +Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
    5.70 +aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
    5.71 +voluptate velit esse cillum dolore eu fugiat nulla pariatur. Duis aute irure
    5.72 +dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
    5.73 +pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
    5.74 +officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,
    5.75 +consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et
    5.76 +dolore magna aliqua.
    5.77 +
    5.78 +\chapter{muh}
    5.79 +
    5.80 +Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
    5.81 +aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
    5.82 +voluptate velit esse cillum dolore eu fugiat nulla pariatur. Duis aute irure
    5.83 +dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
    5.84 +pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
    5.85 +officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,
    5.86 +consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et
    5.87 +dolore magna aliqua.
    5.88 +
    5.89 +
    5.90 +\section{mäh}
    5.91 +
    5.92 +Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
    5.93 +incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis\index{Texteditor}
    5.94 +nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    5.95 +
    5.96 +Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
    5.97 +fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
    5.98 +culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit
    5.99 +amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore
   5.100 +et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation
   5.101 +ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor
   5.102 +in reprehenderit in voluptate velit esse. Cillum dolore eu fugiat nulla
   5.103 +pariatur.
   5.104 +
   5.105 +Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia
   5.106 +deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur
   5.107 +adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
   5.108 +aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
   5.109 +ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
   5.110 +voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
   5.111 +occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim
   5.112 +id est laborum.
   5.113 +
   5.114 +Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
   5.115 +aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
   5.116 +voluptate velit esse cillum dolore eu fugiat nulla pariatur. Duis aute irure
   5.117 +dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
   5.118 +pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
   5.119 +officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,
   5.120 +consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et
   5.121 +dolore magna aliqua.
   5.122 +
   5.123 +\section{miau}
   5.124 +
   5.125 +Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
   5.126 +incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
   5.127 +nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   5.128 +
   5.129 +Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
   5.130 +fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
   5.131 +culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit
   5.132 +amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore
   5.133 +et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation
   5.134 +ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor
   5.135 +in reprehenderit in voluptate velit esse. Cillum dolore eu fugiat nulla
   5.136 +pariatur.
   5.137 +
   5.138 +Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia
   5.139 +deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur
   5.140 +\index{Prototyp}
   5.141 +adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
   5.142 +aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
   5.143 +ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in\index{Daten}
   5.144 +voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
   5.145 +occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim
   5.146 +id est laborum.
   5.147 +
   5.148 +Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
   5.149 +aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
   5.150 +voluptate velit esse cillum dolore eu fugiat nulla pariatur. Duis aute irure
   5.151 +dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
   5.152 +pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
   5.153 +officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,\index{Texteditor}
   5.154 +consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et
   5.155 +dolore magna aliqua.

     6.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     6.2 +++ b/thesis/attic/free-software-projects.tex	Thu Jan 15 12:20:21 2009 +0100
     6.3 @@ -0,0 +1,128 @@
     6.4 +\section{About \freesw\ projects}
     6.5 +
     6.6 +% http://www.faqs.org/docs/artu/
     6.7 +
     6.8 +There are several differences between \freesw\ projects and projects about proprietary software.
     6.9 +To understand \freesw\ projects, one needs to understand \freesw\ itself first.
    6.10 +
    6.11 +\subsection{About \freesw}
    6.12 +The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
    6.13 +Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
    6.14 +One could say, the \GPL\ catalized the \name{Free Software movement}.
    6.15 +
    6.16 +% http://www.fsf.org/about/what-is-free-software
    6.17 +
    6.18 +After all, the \GPL\ was not the first \freesw\ license used.
    6.19 +The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
    6.20 +Licenses providing the same rights have been used since long time ago.
    6.21 +But none of them was so often (re)used by other projects---thus gattering less awareness.
    6.22 +Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
    6.23 +
    6.24 +\freesw\ gives freedoms to its users.
    6.25 +In contrast to proprietary software restricting the users freedom.
    6.26 +The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
    6.27 +% http://www.gnu.org/philosophy/free-sw.html
    6.28 +% http://www.fsf.org/licensing/essays/free-sw.html
    6.29 +\begin{enumerate}
    6.30 +	\item The freedom to run the program, for any purpose (freedom 0).
    6.31 +	\item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
    6.32 +	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
    6.33 +	\item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
    6.34 +\end{enumerate}
    6.35 +
    6.36 +
    6.37 +\subsection{The term ``Open Source''}
    6.38 +\name{Open Source Software} often stands for the same as \freesw.
    6.39 +But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
    6.40 +
    6.41 +\name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
    6.42 +
    6.43 +% http://www.gnu.org/philosophy/open-source-misses-the-point.html
    6.44 +% http://catb.org/~esr/open-source.html
    6.45 +
    6.46 +
    6.47 +\subsection{Development of \freesw}
    6.48 +Having source code available and the right to modify it, encouridges programmers to actually do so.
    6.49 +Their modifications are manifoldly.
    6.50 +Some tailor the software to their needs.
    6.51 +Some add features.
    6.52 +Some do it just for fun.
    6.53 +There are no limitations---whoever wants to, may work on it.
    6.54 +
    6.55 +Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
    6.56 +The process of development is watchable by everyone.
    6.57 +
    6.58 +The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
    6.59 +
    6.60 +Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
    6.61 +
    6.62 +The following text will focus on the ``bazaar'' model.
    6.63 +
    6.64 +
    6.65 +\subsection{The role of the community}
    6.66 +\freesw\ projects rise and fall with their community!
    6.67 +
    6.68 +Most \freesw\ programs are developed by a very small group of programmers, often only one person.
    6.69 +But they are used by many people.
    6.70 +In between the programmers and the users, are people located who are a bit of both.
    6.71 +These are the ones that write documentation, find bugs and probably even fix it.
    6.72 +They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
    6.73 +The program is often spread by their ``advertising''.
    6.74 +
    6.75 +The \emph{community} consists of the actual developers and all users that contribute to the program.
    6.76 +Contribution can be one of the described ways, or others like providing a server for the project website for example.
    6.77 +
    6.78 +\emph{Community} is everyone who is in contact through the project.
    6.79 +Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
    6.80 +
    6.81 +There will hardly be a community if no communication channels are available.
    6.82 +If the development team does not provide them, there is a chance that encouraged users set them up on their own.
    6.83 +But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
    6.84 +
    6.85 +Projects without a good community tend to die sooner or later.
    6.86 +
    6.87 +
    6.88 +\subsection{Evolution of a community}
    6.89 +Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
    6.90 +He starts developing.
    6.91 +When others get in contact with the project, there may be some who are so much interested that they start co-developing.
    6.92 +Others report bugs, and some only use the program.
    6.93 +
    6.94 +After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
    6.95 +The size ratio of the groups vary by type of project.
    6.96 +
    6.97 +One should have that in mind, when starting a \freesw\ project.
    6.98 +
    6.99 +
   6.100 +\subsection{Creating a strong community}
   6.101 +Building up a good community needs some effort of the main developers.
   6.102 +%TODO: search for documents about this topic
   6.103 +
   6.104 +First communication channels need to be set up, to enable the growth of a community.
   6.105 +
   6.106 +Second, development should be visible by everyone who is interested in it.
   6.107 +Time between work done on the project and its visibility to the public should be kept short.
   6.108 +This makes it interesting for other developers to join.
   6.109 +Developers are the core of a community.
   6.110 +
   6.111 +Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
   6.112 +Releases are (more) stable versions, primary for users.
   6.113 +They should be created, frequently.
   6.114 +People will more likely use programs of active projects.
   6.115 +
   6.116 +Fourth, the developers should try to get the users ``in the boat''.
   6.117 +Good communities have a large group of users that do not only receive, but also give something back to the project.
   6.118 +The project leaders should motivate users to contribute.
   6.119 +This unlocks a big work force and gets lot of unexiting work done.
   6.120 +
   6.121 +Fifth, documentation matters.
   6.122 +Good documentation makes it easy for users and developers to start.
   6.123 +And it helps to avoid a lot of unsatisfaction.
   6.124 +Documentation is something that shows quality and that people care about the project.
   6.125 +
   6.126 +And sixth, project leaders should be good souvereigns.
   6.127 +They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
   6.128 +
   6.129 +Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
   6.130 +Volunteer work lives by acknowledgement of the effort spent.
   6.131 +

     7.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     7.2 +++ b/thesis/attic/masqmail-history.tex	Thu Jan 15 12:20:21 2009 +0100
     7.3 @@ -0,0 +1,27 @@
     7.4 +\section{History}
     7.5 +%TODO: let oliver prove read it!
     7.6 +%FIXME: add references
     7.7 +%FIXME: where does the name come from: masqdialer (guessed)
     7.8 +
     7.9 +The date of the first release (version 0.0.1) is unknown.
    7.10 +The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999.
    7.11 +Further releases were made every few weeks or month during 2000, 2001 and 2002.
    7.12 +Development ended in mid-2003 in a hard stop.
    7.13 +The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
    7.14 +
    7.15 +During the time of development, Oliver released 53 versions.
    7.16 +That means a new release in less than every 20 days in average!
    7.17 +
    7.18 +Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
    7.19 +
    7.20 +One extra release (version 0.2.21) was made by him in November 2005.
    7.21 +This one is only available from the \debian\ pool.
    7.22 +Comparing it to version 0.2.20 shows, that no source code was altered.
    7.23 +Only building documents (like Makefiles) and \debian\ packageing documents were changed.
    7.24 +That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
    7.25 +
    7.26 +In May 2000 the minor version number increased to `1'.
    7.27 +Nothing special is mentioned in the documentation about that.
    7.28 +When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail.
    7.29 +At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series.
    7.30 +His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.

     8.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     8.2 +++ b/thesis/attic/masqmail-sendmail-replacement.tex	Thu Jan 15 12:20:21 2009 +0100
     8.3 @@ -0,0 +1,14 @@
     8.4 +Hence it must be secure enough. It either needs the security features or must drop the unsecure funtionality. The second option, however, leads to being \emph{no} replacement for other \MTA{}s. It is a valid decision to not be a replacement for \sendmail\ or thelike, but this is a design decision---the change of a primary goal.
     8.5 +
     8.6 +If \masqmail\ should be an \MTA\ to replace others, a switch to a better suited architecture that provides good security and extendability by design, seems required. But if \masqmail\ is wanted to cover some special jobs, not to replace common \MTA{}s, then its architecture depends on the special requirements of the specific job; \MTA\ architectures, like discussed by \person{Hafiz}, may be inadequate.
     8.7 +
     8.8 +What future is to choose for \masqmail---one to be a full featured \MTA, or one to be a stipped down \MTA\ for special jobs?
     8.9 +
    8.10 +The critical point to discuss upon is surely the listening on a port to accepte messages from outside via \NAME{SMTP} (herafter also refered to as the \NAME{SMTP}-in channel). This feature is required for an \MTA\ to be a \name{smart host}, to relay mail. But running as deamon and listening on a port requires much more security effort, because the program is put in direct contact with attackers and other bad guys.
    8.11 +
    8.12 +\MTA{}s without \SMTP-in channels can not receive mail from arbitrary outside hosts. They are only invoked by local users. This lowers the security need a lot---however, security is a general goal and still required, but on a lower level. Unfortunately, as they do not receive mail anymore (except by local submission), they are just better \name{forwarders} that are able to send mail directly to the destination.
    8.13 +
    8.14 +This is not what \masqmail\ was intended to be. Programs that cover this purpose are available; one is \name{msmtp}.
    8.15 +
    8.16 +\masqmail\ shall be a complete \mta. It shall be able to replace ones like \sendmail.
    8.17 +

     9.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     9.2 +++ b/thesis/attic/matrix-graphs.tex	Thu Jan 15 12:20:21 2009 +0100
     9.3 @@ -0,0 +1,32 @@
     9.4 +%		\begin{picture}(300,200)
     9.5 +%			\put(20,150){messages}
     9.6 +%			\put(100,110){\framebox(100,75){email, SMS}}
     9.7 +%			\put(200,110){\framebox(100,75){voicemail, video messages}}
     9.8 +%
     9.9 +%			\put(20,75){dialog}
    9.10 +%			\put(100,35){\framebox(100,75){IM, chat}}
    9.11 +%			\put(200,35){\framebox(100,75){VoIP, GSM/UMTS}}
    9.12 +%
    9.13 +%			\put(130,10){written}
    9.14 +%			\put(230,10){spoken}
    9.15 +%		\end{picture}
    9.16 +
    9.17 +%\begin{table}
    9.18 +%	\begin{tabular}[htb]{r||p{3cm}|p{3cm}|}
    9.19 +%		&&\\
    9.20 +%		& \textit{written} & \textit{spoken}\\[1ex]
    9.21 +%		\hline
    9.22 +%		\hline
    9.23 +%		\textit{messages (asynchron)} &
    9.24 +%		\parbox[t]{3cm}{\quad\\email\\SMS\\\quad} &
    9.25 +%		\parbox[t]{3cm}{\quad\\voicemail\\video messages\\\quad} \\
    9.26 +%		\hline
    9.27 +%		\textit{dialog (synchron)} &
    9.28 +%		\parbox[m]{3cm}{eIM\\chat} &
    9.29 +%		\parbox[m]{3cm}{eVoIP\\GSM/UMTS} \\
    9.30 +%		\hline
    9.31 +%	\end{tabular}
    9.32 +%	\caption{Classification of electronic communication}
    9.33 +%	\label{tab:comm-classification}
    9.34 +%\end{table}
    9.35 +

    10.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    10.2 +++ b/thesis/attic/mta-history-definition-sendmail.tex	Thu Jan 15 12:20:21 2009 +0100
    10.3 @@ -0,0 +1,92 @@
    10.4 +\subsection{History of electronic mail}
    10.5 +%FIXME: shorter!!!
    10.6 +
    10.7 +Electronic mail\index{electronic mail} (short: \name{email})\citeweb{wikipedia:email} is a basic concept in \unix.\citeweb{unix-mail-intro} On \unix\ machines, a lot of information is distributed by \name{system mail}, which is email sent by the operating system. Beside that, email is the common communication system between humans working on computers.
    10.8 +
    10.9 +The \unix\ operating system supports email through the \name{mail user agent} (short: \NAME{MUA}) \name{/bin/mail}.
   10.10 +
   10.11 +Development of \unix\ was not only made in the \name{Bell Labratories} of \NAME{AT\&T}. The \name{Univerity of California at Berkeley} worked on their version of a \unix\ operating system, too. It is refered to as \NAME{UCB} \unix, or \name{Berkeley} \unix\index{Berkeley Unix}.
   10.12 +
   10.13 +The few features of \name{/bin/mail} lead to a second \NAME{MUA} from Berkeley: \name{Mail} (with a capital `M'). Later, the superior functionality of \name{Mail} went back to \name{Bell Labs} and into the program \name{mailx}, the successor of \name{/bin/mail}.
   10.14 +
   10.15 +Nowadays, \name{mailx} and \name{Mail} are quite equivalent and \name{/bin/mail} is linked to either of them---whichever is installed.
   10.16 +
   10.17 +At that time, computers were connected by various kinds of networks. \name{Bell Labs} had invented the \NAME{UUCP} program and protocol suite (for ``\unix\ to \unix\ copy'')\citeweb{wikipedia:uucp}. Berkeley however had an own creation called \name{Berknet} in use. And the \name{United States Department of Defence Advanded Research Projects Agency}'s (\NAME{ARPA}) effort on designing a new wide area network, led to the \NAME{ARPANET}\citeweb{wikipedia:arpanet}, based on the \name{transmission control protocol} (\NAME{TCP}). There were also other, minor, kinds of networks in use.
   10.18 +
   10.19 +Email was transfered between different machines within the same networks. The file transfer itself was made uniformly using \NAME{FTP}, but the higher layered logic of the transfer was different. For example was addressing done different: \NAME{UUCP} used a flat-style schema, while \NAME{ARPANET}'s was hierachical.
   10.20 +
   10.21 +Mail transport from one machine connected to one kind of network to a second machine connected to another was a problem. This showed up at Berkeley where some departments of the university had switched to \NAME{ARPANET}, and some to \NAME{UUCP}, while the rest used \name{Berknet}.
   10.22 +
   10.23 +It was around 1982, when Eric Allman, then a student at Berkeley, wrote \name{delivermail}. Its purpose was to transform email from one network to another. \name{delivermail}, like its successor---the more flexible \sendmail---intermediated between the different networks. They were able to transform email messages from any network to any other.
   10.24 +
   10.25 +Todays email structure is basicly the same as then. The major difference is the uniformity of the underlying network, which is nearly always the \NAME{ARPANET}-based \name{Internet}. Hence lowering the importance of the transformation capabilities of \MTA{}s, that was essential to \sendmail's success---yet being the primary motivation for the program.
   10.26 +
   10.27 +More information about the history of electronic mail can be found at: \citeweb{email:griffiths}, \citeweb{email:crocker}, \citeweb{email:vleck}, \citeweb{email:akkad}, \citeweb{email:murakami}, and \citeweb{email:tomlinson}. A good starting point for general information on internet history is \citeweb{wikipedia:historyoftheinternet}.
   10.28 +%TODO: check the websites which ones are the important ones; remove unnessesary ones
   10.29 +
   10.30 +
   10.31 +
   10.32 +\subsection{Definition of \MTA}
   10.33 +%FIXME: better title; work text over!
   10.34 +%TODO: when was the term ``mail transfer agent'' established?
   10.35 +% shorter!
   10.36 +
   10.37 +This thesis is about a \name{mail transfer agent} (or \index{mail transport agent|see{mail transfer agent}}\name{mail transport agent}, short \NAME{MTA}): \masqmail. \sendmail\ is one too---the most important one.
   10.38 +
   10.39 +The basic job of a \mta\ is to transfer/transport electronic mail from one host to another.
   10.40 +
   10.41 +Here are definitions from others:
   10.42 +
   10.43 +\begin{quote}
   10.44 +A mail transfer agent (MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office.
   10.45 +\cite{costales97}
   10.46 +\end{quote}
   10.47 +
   10.48 +\begin{quote}
   10.49 +A mail transfer agent (MTA) (also called a mail transport agent, message transfer agent, or smtpd (short for SMTP daemon)), is a computer program or software agent that transfers electronic mail messages from one computer to another.
   10.50 +\citeweb{wikipedia:mta}
   10.51 +\end{quote}
   10.52 +
   10.53 +\begin{quote}
   10.54 +mail server (also known as a mail transfer agent or MTA, a mail transport agent, a mail router or an Internet mailer) is an application that receives incoming e-mail from local users (people within the same domain) and remote senders and forwards outgoing e-mail for delivery.
   10.55 +\citeweb{website:techtarget}
   10.56 +\end{quote}
   10.57 +
   10.58 +\begin{quote}
   10.59 +Message Transfer Agent - (MTA, Mail Transfer Agent): Any program responsible for delivering e-mail messages. Upon receiving a message from a Mail User Agent or another MTA, [...] it [...] delivers it to any local addressees and/or forwards it to other remote MTAs (routing) for delivery to remote recipients.
   10.60 +%Any program responsible for delivering e-mail messages. Upon receiving a message from a Mail User Agent or another MTA, often by SMTP over the Internet, it stores it temporarily locally and analyses the recipients and delivers it to any local addressees and/or forwards it to other remote MTAs (routing) for delivery to remote recipients. In either case it may edit and/or add to the message headers.
   10.61 +%
   10.62 +%The most widely used MTA for Unix is sendmail, which communicates using SMTP.
   10.63 +%
   10.64 +%RFC 2821 (SMTP) expands MTA as ``Mail Transfer Agent'' though this is less common. Alternatives with ``Transport'' are also seen but less correct.
   10.65 +\citeweb{website:thefreedictionary}
   10.66 +\end{quote}
   10.67 +
   10.68 +Common is the transfer of mail to other machines; this is the actual job. \MTA{}s work with mail, received from local users and/or remote machines. Mail delivery however is \emph{not} what \mta{}s are for, although probably every \MTA\ is able to deliver mail, and many do. \name{mail delivery agents} (short: \NAME{MDA}) are the programs for this job. Two of the best known \NAME{MDA}s are \name{procmail} and \name{maildrop}.
   10.69 +
   10.70 +
   10.71 +
   10.72 +\subsection{\name{sendmail-compatibility}}
   10.73 +\label{sec:sendmail}
   10.74 +%FIXME: rewrite!
   10.75 +% shorter!
   10.76 +
   10.77 +Allman wrote it to transfer emails between different networks, thus giving \sendmail\ mighty address rewriting abilities. In contrast to its predecessor \name{delivermail}, was \sendmail\ designed to offer greatest flexiblity in configuration; this enabled it to deal with any type of network.
   10.78 +
   10.79 +\sendmail\ was, and still is, very successful. So successful that it stands, like no other, for the whole group of \MTA{}s: \name{sendmail} actually is the \emph{de facto standard} for \mta{}s.
   10.80 +
   10.81 +Its author, Allman, sees three reasons for the huge success: the ``sloopy'' approach (accepting badly formed messages); its focus on the routing function; and the flexible configuration (this was important in \sendmail's early days).
   10.82 +\cite[page xviii]{costales97}
   10.83 +
   10.84 +Others see \sendmail's success more critical. One of them is quoted in the \name{MMDF} FAQs \citeweb{faqs:mmdf}:
   10.85 +\begin{quote}
   10.86 +Sendmail was once compared by one old Internet hand to ``those killer bees that escaped from the laboratory---and now they're everywhere and you can't get rid of 'em''.
   10.87 +\end{quote}
   10.88 +He definately hints here at \sendmail's many security vulnerabilities that came to light and on its complexity, in particular its obscure configuration file \path{sendmail.cf}.
   10.89 +
   10.90 +No matter how \sendmail\ is seen, one must admit its influence on \unix\ emailing programs. Most existing substitutes mimic \sendmail's interface and behavior. Most notable, they create a symbolic link named ``sendmail'' pointing to their own executable. The reason herefor are the many programs assuming an executable called ``sendmail'' on every computer system existing.
   10.91 +
   10.92 +\sendmail\ is not only ported to many platforms, even including \name{Microsoft Windows}, but also it is still the prefered \MTA\ on many systems.
   10.93 +
   10.94 +For deeper knowledge on \sendmail's history, see \cite{costales97} and \cite{vixie01}.
   10.95 +

    11.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    11.2 +++ b/thesis/attic/new-queue-permissions.txt	Thu Jan 15 12:20:21 2009 +0100
    11.3 @@ -0,0 +1,56 @@
    11.4 +\begin{tabular}[hbt]{ l l }
    11.5 +
    11.6 +\mbox{ queue-in:} & \mbox{
    11.7 +\begin{tabular}[hbt]{| c | c | c |}
    11.8 +	\hline
    11.9 + incoming & outgoing & pool \\
   11.10 +	\hline
   11.11 +	\hline
   11.12 + - & - & - \\
   11.13 +	\hline
   11.14 + 0600 & - & - \\
   11.15 +	\hline
   11.16 + 0600 & - & 0600 \\
   11.17 +	\hline
   11.18 + 0700 & - & 0600 \\
   11.19 +	\hline
   11.20 +\end{tabular}
   11.21 +} \\
   11.22 +
   11.23 +\quad & \\
   11.24 +
   11.25 +\mbox{scanning:} & \mbox{
   11.26 +\begin{tabular}[hbt]{| c | c | c |}
   11.27 +	\hline
   11.28 + incoming & outgoing & pool \\
   11.29 +	\hline
   11.30 +	\hline
   11.31 + 0700 & - & 0600 \\
   11.32 +	\hline
   11.33 + 0700 & 0600 & 0600 \\
   11.34 +	\hline
   11.35 + 0700 & 0700 & 0600 \\
   11.36 +	\hline
   11.37 + - & 0700 & 0600 \\
   11.38 +	\hline
   11.39 +\end{tabular}
   11.40 +} \\
   11.41 +
   11.42 +\quad & \\
   11.43 +
   11.44 +\mbox{queue-out:} & \mbox{
   11.45 +\begin{tabular}[hbt]{| c | c | c |}
   11.46 +	\hline
   11.47 + incoming & outgoing & pool \\
   11.48 +	\hline
   11.49 +	\hline
   11.50 + - & 0700 & 0600 \\
   11.51 +	\hline
   11.52 + - & 0700 & - \\
   11.53 +	\hline
   11.54 + - & - & - \\
   11.55 +	\hline
   11.56 +\end{tabular}
   11.57 +} \\
   11.58 +
   11.59 +\end{tabular}

    12.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    12.2 +++ b/thesis/attic/old/1-Candidates.tex	Thu Jan 15 12:20:21 2009 +0100
    12.3 @@ -0,0 +1,133 @@
    12.4 +\chapter{\unix\ \MTA{}s}
    12.5 +
    12.6 +After having read about the history of electronic mail and the basics of \mta{}s in the last chapter, this chapter introduces a group of \mta{}s. Among them, the already mentioned \sendmail. The selected group will be delimited against other groups of \MTA{}s, which are described as well.
    12.7 +
    12.8 +The chosen programs will be presented to the reader in a short overview and with the most important facts. The next chapter will show a comparison of these programs in several disciplines.
    12.9 +
   12.10 +
   12.11 +\section{Types of \MTA{}s}
   12.12 +``Mail transfer agent'' is a term covering a variety of programs. One thing is common to them: they transfer email from one \emph{thing} to another. These \emph{things} can be hosts, meaning independent machines, or protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transfered.\footnote{\sendmail{}'s initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.}
   12.13 +
   12.14 +Beside this common property, \MTA{}s can be very different. Some of them have \NAME{POP3} and/or \NAME{IMAP} servers included. Some can fetch mails through these protocols. Others have have all features you can think of. And maybe there are some that do nothing else but transporting email.
   12.15 +
   12.16 +Following are groups of \mta{}s that will \emph{not} be regarded further.
   12.17 +
   12.18 +\subsection{Relay-only \MTA{}s}
   12.19 +\label{subsec:relay-only}
   12.20 +This is the most simple kind of \MTA. It transfers mail only to defined \name{smart hosts}\footnote{\name{smart host}s are \MTA{}s that receives email and route it to the actual destination}. \name{Relay-only} \MTA{}s do not receive mail from outside the system, and they do not deliver locally.
   12.21 +
   12.22 +Most \MTA{}s can be configured to act as such a \name{forwarder}. But this is usually an additional functionality.
   12.23 +
   12.24 +One would use such a program to give a system the possibility to send mail, without the need to do lots of configuration. In a local network, usually the clients are set up with a \name{relay-only} \MTA, while there is one \name{mail server} that acts as a \name{smart host}. The ``dumb'' clients send mail to this one \name{mail server} which does all the work.
   12.25 +
   12.26 +Examples for that group are: \name{nullmailer}, \name{ssmtp} and \name{esmtp}.
   12.27 +
   12.28 +
   12.29 +\subsection{Groupware}
   12.30 +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 actual funktionality. Modules for mail transfer, file storage, calendars, resource management, instant messaging, etc., are commonly available.
   12.31 +
   12.32 +One would use one of these program suites if the main work to do is not mail transfer, but providing integrated communication facilities and team working support for a group of people. The most common scenario are companies. They have \name{groupware} running to provide adequate services for their teams to work efficently. But one may use \name{groupware} on the home server for his family members also.
   12.33 +
   12.34 +Examples are: \name{Lotus Notes}, \name{Microsoft Exchange}, \name{OpenGroupware.org} and \name{eGroupWare}.
   12.35 +
   12.36 +
   12.37 +\subsection{``Real'' \MTA{}s}
   12.38 +There is a third type of \mta{}s in between the minimalistic \name{relay-only} \MTA{}s and the bloated \name{groupware}. Those programs may be named ``real \MTA{}s'', or ``proper \MTA{}s'', though there is no common name. They are what is meant with the term ``\mta''.
   12.39 +
   12.40 +Common to them is their focus on transfering email, while being able to act as \name{smart host}. Their variety ranges from ones mostly restricted to mail transfer (\name{qmail}) to others already having interfaces for adding further mail processing modules (\name{postfix})---thus everything in between the other two groups.  %FIXME: are postfix and qmail good examples?
   12.41 +
   12.42 +This group is of importance in this document. The programs selected for the comparison are ``real \MTA{}s''.
   12.43 +
   12.44 +
   12.45 +
   12.46 +\section{Programs to sort out}
   12.47 +
   12.48 +\name{Mail transfer agent}s can be segmented in various ways, apart from the classification above. Groups of programs wiproperties significantly different from \masqmail\ will be sorted out now.
   12.49 +
   12.50 +\subsection{Non-\emph{sendmail-compatible} \MTA{}s}
   12.51 +Due to \sendmail's significance---described in section \ref{sec:sendmail}---compatiblity interfaces for \sendmail\ are of importance for \unix\ \MTA{}s. Being not \emph{sendmail-compatible} does not need to matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on \unix\ systems.
   12.52 +
   12.53 +Hence all \MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility addon, will not be covered here.
   12.54 +
   12.55 +An Examples here is \name{Apache James}.  %FIXME: check if correct
   12.56 +
   12.57 +
   12.58 +\subsection{Non-free software}
   12.59 +Only programs being \freesw\ are regarded, because comparing \freesw\ with proprietary or commercial software is not what typical users of programs like \masqmail\ do. Comparison with those non-free programs may be a point for large \freesw\ projects, trying to step into the business world. Small projects, mostly used by individuals at home, need to be compared against other projects of similar shape.
   12.60 +
   12.61 +The comparison should be seen from \masqmail's point of view, so non-free software is out of the way.
   12.62 +
   12.63 +
   12.64 +
   12.65 +\section{The programs regarded}
   12.66 +The programs remaining are \emph{sendmail-compatible} ``smart'' \MTA{}s that focus on mail transfer and are \freesw. One would not use a program for a job it is not suited for. Therefor only \mta{}s that are mostly similar to \masqmail\ are regarded.
   12.67 +
   12.68 +For the comparision, five programs are taken. These are: \sendmail, \name{qmail}, \name{postfix}, \name{exim}, and \masqmail. The four alternatives to \masqmail\ are the most important representatives of the regarded group. % FIXME: add ref that affirm that
   12.69 +
   12.70 +\name{courier-mta} is also a member of this group, being even closer to \name{groupware} than \name{postfix}. It is excluded here, because the \NAME{IMAP} and webmail parts of the mail server suite are more in focus than its \MTA. Common mail server setups even bundle \name{courier-imap} with \name{postfix}.
   12.71 +
   12.72 +Other members are: \name{smail}, \name{zmailer}, \name{mmdf}, and more; they all are less important and rarely used.
   12.73 +
   12.74 +Following is a small introduction to each of the five programs chosen for comparision.
   12.75 +
   12.76 +\subsection{\sendmail}
   12.77 +\label{sec:sendmail}
   12.78 +\sendmail\ is the most popular \mta. Since it was one of the first \MTA{}s and was shipped by many vendors of \unix\ systems.
   12.79 +
   12.80 +The program was written by Eric Allman as the successor of his program \name{delivermail}. \sendmail\ was first released with \NAME{BSD} 4.1c in 1983. Allman was not the only one working on the program. Other people developed own versions of it and a variety of flavors came up, especially in the late eighties when Allman was inactive.
   12.81 +
   12.82 +\sendmail\ is focused on transfering mails between different protocols and networks, this lead to a very flexible (though complex) configuration.
   12.83 +
   12.84 +The latest version is 8.14.3 from May 2008. The program is distributed under the \name{Sendmail License} as both, \freesw\ and proprietary software of \name{Sendmail, Inc.}.
   12.85 +
   12.86 +Further development will go into the project \name{MeTA1} which succeeds \sendmail.
   12.87 +
   12.88 +More information can be found on the \sendmail\ homepage \citeweb{sendmail:homepage} and on \citeweb{wikipedia:sendmail} and \citeweb{jdebp}.
   12.89 +
   12.90 +
   12.91 +\subsection{\name{qmail}}
   12.92 +\label{sec:qmail}
   12.93 +\name{qmail} is seen by its community as ``a modern SMTP server which makes sendmail obsolete''. It was written by Daniel~J.\ Bernstein starting in 1995. His primary goal was to create a secure \MTA\ to replace the popular, but vulnerable, \sendmail.
   12.94 +
   12.95 +\name{qmail} first introduced may innovative concepts in \mta\ design and is generally seen as the first security-aware \MTA\ developed.
   12.96 +
   12.97 +Since November 2007, \name{qmail} is released in the \name{public domain} which makes it \freesw. The latest release is 1.03 from July 1998.
   12.98 +
   12.99 +The programs homepages are \citeweb{qmail:homepage1} and \citeweb{qmail:homepage2}. Further information about \name{qmail} is available on \citeweb{lifewithqmail}, \citeweb{wikipedia:qmail} and \citeweb{jdebp}.
  12.100 +
  12.101 +
  12.102 +\subsection{\name{postfix}}
  12.103 +\label{sec:postfix}
  12.104 +The \name{postfix} project was started in 1999 at \name{IBM research}, then called \name{VMailer} or \name{IBM Secure Mailer}. Wietse Venema's program ``attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.''\citeweb{postfix:homepage} In fact, \name{postfix} was mainly designed after qmail's architecture to gain security. But in contrast to \name{qmail} it aims much more on being fast and full-featured.
  12.105 +
  12.106 +Today \name{postfix} is taken by many \unix systems and \gnulinux distributions as default \MTA.
  12.107 +
  12.108 +The latest stable version is numbered 2.5.5 from August 2008. \name{postfix} is covered by the \name{IBM Public License 1.0} which is a \freesw\ license.
  12.109 +
  12.110 +Additional information is available on the program's homepage \citeweb{postfix:homepage}, on \citeweb{jdebp} and \citeweb{wikipedia:postfix}.
  12.111 +
  12.112 +
  12.113 +\subsection{\name{exim}}
  12.114 +\label{sec:exim}
  12.115 +\name{exim} was started in 1995 by Philip Hazel at the \name{University of Cambridge}. Its age is about the same as \name{qmail}'s, but the architecture is totally different.
  12.116 +
  12.117 +While \name{qmail} took a completely new approach, \name{exim} forked of \name{smail-3}, and therefor is monolitic like that and like \sendmail. But having no separation of the individual components of the system, like \name{qmail} and \name{postfix} have, did not hurt. Its security is comparably good.
  12.118 +
  12.119 +\name{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. Also interfaces for integration of virus and spam check programs are provided by design.
  12.120 +
  12.121 +The program is \freesw, released under the \GPL. The latest stable version is 4.69 from December 2007.
  12.122 +
  12.123 +One finds \name{exim} on its homepage \citeweb{exim:homepage}. More information about it can be retrieved from \citeweb{wikipedia:exim} and \citeweb{jdebp}.
  12.124 +
  12.125 +
  12.126 +\subsection{\masqmail}
  12.127 +\label{sec:masqmail}
  12.128 +The \masqmail\ program was written by Oliver Kurth, starting in 1999. His aim was to create a small \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ is easy configurable for situations which are rarely solveable with the common \MTA{}s.
  12.129 +
  12.130 +\masqmail\ queues mail for destinations outside the local network if no connection to the internet is online. If the machine goes online, this mail is sent. Mail to local machines is sent immediately.
  12.131 +
  12.132 +While the other \MTA{}s are more general purpose \MTA{}s, \masqmail\ aims on special situations only. Nevertheless can it handle ordinary mail transfers too.
  12.133 +
  12.134 +\masqmail\ is released under the \GPL, which makes it \freesw. The latest stable version is 0.2.21 from November 2005.
  12.135 +
  12.136 +The program's new homepage \citeweb{masqmail:homepage} provides further information about this \MTA.

    13.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    13.2 +++ b/thesis/attic/old/1-Comparision.tex	Thu Jan 15 12:20:21 2009 +0100
    13.3 @@ -0,0 +1,100 @@
    13.4 +\chapter{Comparison of \MTA{}s}
    13.5 +
    13.6 +% http://shearer.org/MTA_Comparison
    13.7 +% http://www.geocities.com/mailsoftware42/
    13.8 +% http://fanf.livejournal.com/50917.html
    13.9 +% http://archives.neohapsis.com/archives/postfix/2006-07/1762.html
   13.10 +% http://www.oreillynet.com/lpt/a/6849
   13.11 +% http://www.mailradar.com/mailstat/
   13.12 +
   13.13 +\section{First release}
   13.14 +sendmail: 1983
   13.15 +
   13.16 +postfix: 1999
   13.17 +
   13.18 +qmail: 1996 (first beta 0.70), 1997 (first general 1.0)
   13.19 +
   13.20 +exim: 1995
   13.21 +
   13.22 +masqmail: 1999
   13.23 +
   13.24 +exchange: 1993
   13.25 +
   13.26 +
   13.27 +\section{Lines of code (with sloccount on debian packages)}
   13.28 +sendmail: 93k
   13.29 +
   13.30 +postfix: 92k
   13.31 +
   13.32 +qmail: 18k
   13.33 +
   13.34 +exim: 54k
   13.35 +
   13.36 +masqmail: 14k
   13.37 +
   13.38 +exchange: (no source available)
   13.39 +
   13.40 +
   13.41 +\section{Architecture}
   13.42 +sendmail: monolitic
   13.43 +
   13.44 +postfix: modular
   13.45 +
   13.46 +qmail: modular
   13.47 +
   13.48 +exim: monolitic
   13.49 +
   13.50 +masqmail: monolitic
   13.51 +
   13.52 +exchange: (unknown)
   13.53 +
   13.54 +
   13.55 +\section{Design goals}
   13.56 +sendmail: flexibility
   13.57 +
   13.58 +postfix: performance and security
   13.59 +
   13.60 +qmail: security
   13.61 +
   13.62 +exim: general, flexible \& extensive facilities for checking
   13.63 +
   13.64 +masqmail: for non-permanent internet connection
   13.65 +
   13.66 +exchange: groupware
   13.67 +
   13.68 +
   13.69 +\section{Market share (by Bernstein in 2001)}
   13.70 +sendmail: 42\%
   13.71 +
   13.72 +postfix: 1.6\%
   13.73 +
   13.74 +qmail: 17\%
   13.75 +
   13.76 +exim: 1.6\%
   13.77 +
   13.78 +masqmail: (unknown)
   13.79 +
   13.80 +exchange: 18\%
   13.81 +
   13.82 +
   13.83 +
   13.84 +
   13.85 +1) complexity
   13.86 +
   13.87 +2) security
   13.88 +
   13.89 +3) simplicity of configuration and administration
   13.90 +
   13.91 +4) flexibility of configuration and administration
   13.92 +
   13.93 +5) code size
   13.94 +
   13.95 +6) code quality
   13.96 +
   13.97 +7) documentation (amount and quality)
   13.98 +
   13.99 +8) community (amount and quality)
  13.100 +
  13.101 +9) used it myself
  13.102 +
  13.103 +10) had problems with it

    14.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    14.2 +++ b/thesis/attic/old/1-Masqmail.tex	Thu Jan 15 12:20:21 2009 +0100
    14.3 @@ -0,0 +1,107 @@
    14.4 +\chapter{\masqmail}
    14.5 +
    14.6 +%TODO: have text by oliver here?
    14.7 +
    14.8 +
    14.9 +\section{Target field}
   14.10 +Its original author, Oliver Kurth, sees \masqmail\ so:
   14.11 +\begin{quote}
   14.12 +MasqMail is a mail server designed for hosts that do not have a permanent internet connection eg. a home network or a single host at home. It has special support for connections to different ISPs. It replaces sendmail or other MTAs such as qmail or exim.
   14.13 +\end{quote}
   14.14 +
   14.15 +\masqmail\ is inteded to cover a specific niche: non-permanent internet connection and different \NAME{ISP}s.
   14.16 +
   14.17 +Although it can basically replace other \MTA{}s, it is not generally aimed to do so. The package description of \debian\citeweb{packages.debian:masqmail} states this more clearly by changing the last sentence to:
   14.18 +\begin{quote}
   14.19 +In these cases, MasqMail is a slim replacement for full-blown MTAs such as sendmail, exim, qmail or postfix.
   14.20 +\end{quote}
   14.21 +\masqmail\ is a good replacement ``in these cases'', but not generally, since is lacks features essential for running on mail servers. It is primarily not secure enough for being accessable from untrusted locations.
   14.22 +
   14.23 +The program is best used in home networks, which are non-permanently connected to the internet. \masqmail\ sends mail to local destinations, like users on the same machine and on other machines in the local net, immediately. Email to recipients outside the local net are queued when offline and sent when a online connection gets established.
   14.24 +
   14.25 +Further more does \masqmail\ respect online connections through different \NAME{ISP}s; a common thing for dial-up connections. In particular can different sender addresses be set, dependent on the \NAME{ISP} that is used. This prevents mail to be likely classified as spam.
   14.26 +
   14.27 +
   14.28 +
   14.29 +\section{Typical usage}
   14.30 +This section describes situations that make senseful use of \masqmail.
   14.31 +
   14.32 +A home network consisting of some workstations without a server. The network is connected to the internet by dial-up or broadband. Going online is initiated by computers inside the local net. \NAME{IP} addresses change at least once every day.
   14.33 +
   14.34 +Every workstation would be equiped with \masqmail. Mail transfer within the same machine or within the local net works straight forward. Outgoing mail to the internet is sent, to the concerning \NAME{ISP} for relaying, whenever the router goes online. Receiving of mail from outside needs to be done by a mail fetch program, like the \masqmail\ internal \NAME{POP3} client or \name{fetchmail} for example. The configuration for \masqmail\ would be the same on every computer, except the hostname.
   14.35 +
   14.36 +For the same network but having a server, one could have \masqmail\ running on the server and using simple forwarders (see \ref{subsec:relay-only}) to the server on the workstations. This setup does only support mail transfer to the server, but not back to a workstation; also sending mail to another user on the same workstation is not possible.
   14.37 +
   14.38 +A better setup is to run \masqmail\ on every machine %FIXME
   14.39 +
   14.40 +
   14.41 +
   14.42 +\section{What makes it special}
   14.43 +
   14.44 +As main advantage, \masqmail\ makes it easy to set up an \MTA\ on workstations or notebooks without the need to do complex configuration or to be an mail server expert.
   14.45 +
   14.46 +Workstations use %FIXME
   14.47 +
   14.48 +
   14.49 +\section{Alternatives?}
   14.50 +% http://anfi.homeunix.org/sendmail/dialup10.html
   14.51 +
   14.52 +
   14.53 +\section{Structure}
   14.54 +Like its anchestor \sendmail, \masqmail\ is a monolitic program. It consists of only one \emph{setuid root}\footnote{Runs as user root, no matter which user invoked it.}\index{setuid root} binary file, named \path{masqmail}. All functionality is included in it; of course some more comes from dynamic libraries linked.
   14.55 +
   14.56 +The \masqmail\ executable can be called under various names for \name{sendmail-compatibility} reasons. This is commonly organized by creating symbolic links with with different names to the \masqmail\ executable. These are \path{/usr/lib/sendmail} and \path{/usr/sbin/sendmail} because many programs expect a \mta\ to be located there. Further more \sendmail\ provides shortcuts by calling it with a different name instead of supplying command line arguments. The best known of it is \path{mailq}, which is equivilent to calling the \MTA\ with the argument \verb+-bq+. \masqmail\ reacts to the names \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The last four are an addition to \sendmail. Not implemented is the name \path{newaliases} because it is not relevant to \masqmail. To provide the command nonetheless, one may write a shell script located at \path{/usr/bin/newaliases}, that simply invokes \verb+masqmail -bi+.
   14.57 +
   14.58 +%masqmail: mailq, mailrm, runq, rmail, smtpd/in.smtpd
   14.59 +%sendmail: hoststat, mailq, newaliases, purgestat, smtpd
   14.60 +
   14.61 +\masqmail\ is written in the \NAME{C} programming language. The program, as of version 0.2.21, consists of 34 source code and eight header files, containing about 9,000 lines of code\footnote{Measured with \name{sloccount} by David A.\ Wheeler.}. Additionally, it includes a \name{base64} implementation (about 300 lines) and \name{md5} code (about 150 lines). For systems that do not provide \name{libident}, this library is distributed as well (circa 600 lines); an available shared library however has higher precedence in linking.
   14.62 +
   14.63 +The only mandatory dependency is \name{glib}---a cross-platform software utility library, originated in the \NAME{GTK+} project. It provides safer replacements for many standard library functions. (The unsafe \verb+sprintf()+ is one example.) Also it offers handy data containers, easy-to-use implementations of data structures, and much more.
   14.64 +
   14.65 +With \masqmail\ comes the small tool \path{mservdetect}; it helps setting up a configuration that uses the \name{mserver} system to detect the online state. Two other binaries get compiled for testing purposes: \path{readtest} and \path{smtpsend}. All three programms use \masqmail\ source code; they only add a file with a \verb+main()+ function each.
   14.66 +
   14.67 +\masqmail\ does not provide an interface for modules with additional functionality. There exists no add-on or module system. But the code is separated by function to the various source files, and some functional parts can be included or excluded by defining symbols. This means adding some argument (like \verb+--enable-maildir+) to the \verb+configure+ call. Thus the concerning code gets not removed by the preprocessor.
   14.68 +
   14.69 +
   14.70 +\section{Features}
   14.71 +This overview regards \masqmail version 0.2.21, the state this document starts off.
   14.72 +
   14.73 +First of all \masqmail\ is an \MTA. Therefor it accepts mail on the command line and via \SMTP. Mail queueing and alias expansion is supported. \masqmail\ is able to deliver mail to local mailboxes (in \name{mbox} or \name{maildir} format) or pass it to a \name{mail delivery agent} (like \name{procmail}). Mail destinated to remote locations is sent via \SMTP. Outgoing \SMTP\ connections feature \name{SMTP-Auth} and \name{SMTP-after-POP} authentication, but incoming \SMTP\ does not.
   14.74 +
   14.75 +As \masqmail\ is focused on non-permanent Internet connections, online state can be queried by three methods: reading from a file, reading the output of a command, or by asking an \name{mserver}. Each method may return a string indicating one of the available routes being online, or returning nothing to indicate offline state.
   14.76 +
   14.77 +Delivery to recipients on the local host or in local nets is done at once; delivery to recipients on the Internet is only done when being online, and queued otherwise. Each online route may have a different mail server to which mail is relayed. Return address headers are modified appropriate if wished.
   14.78 +
   14.79 +Additional to the \mta\ job, \masqmail\ also offers mail retrieval services with being a \NAME{POP3} client. Thus it can fetch mail from remote locations, dependent on the active online route.
   14.80 +
   14.81 +
   14.82 +
   14.83 +\section{History}
   14.84 +%TODO: let oliver prove read it!
   14.85 +%FIXME: add references
   14.86 +%FIXME: where does the name come from: masqdialer (guessed)
   14.87 +
   14.88 +The date of the first release (version 0.0.1) is unknown.
   14.89 +The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999.
   14.90 +Further releases were made every few weeks or month during 2000, 2001 and 2002.
   14.91 +Development ended in mid-2003 in a hard stop.
   14.92 +The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
   14.93 +
   14.94 +During the time of development, Oliver released 53 versions.
   14.95 +That means a new release in less than every 20 days in average!
   14.96 +
   14.97 +Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
   14.98 +
   14.99 +One extra release (version 0.2.21) was made by him in November 2005.
  14.100 +This one is only available from the \debian\ pool.
  14.101 +Comparing it to version 0.2.20 shows, that no source code was altered.
  14.102 +Only building documents (like Makefiles) and \debian\ packageing documents were changed.
  14.103 +That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
  14.104 +
  14.105 +In May 2000 the minor version number increased to `1'.
  14.106 +Nothing special is mentioned in the documentation about that.
  14.107 +When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail.
  14.108 +At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series.
  14.109 +His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.
  14.110 +

    15.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    15.2 +++ b/thesis/attic/old/2-FutureOfCommunication.tex	Thu Jan 15 12:20:21 2009 +0100
    15.3 @@ -0,0 +1,120 @@
    15.4 +\chapter{The future of communication}
    15.5 +\label{chap:future-of-communication}
    15.6 +As globalization proceeds, long distance communication becomes more and more important. This chapter tries to locate trends in communication methods and their impact on the future for communication. The insights gathered from the analysis will be applied to \masqmail, afterwards.
    15.7 +
    15.8 +
    15.9 +\section{Communication methods}
   15.10 +\label{sec:communication-methods}
   15.11 +Today's long distance communication methods are either written or spoken information. And on the other side, they can be classified by the time between responses.
   15.12 +
   15.13 +A classification of long distance communication methods is shown in figure %\ref{fig:}.
   15.14 +% slow     |              |             |
   15.15 +%          |              | letter      | days
   15.16 +%          |              |             |
   15.17 +%          |              |             |
   15.18 +%          | answering    | email       |
   15.19 +%          |   machine    | telefax     | few seconds
   15.20 +%          |              | SMS         |
   15.21 +% fast     |              |             |
   15.22 +%          | telephone    | IM          | real time
   15.23 +% -----------------------------------------------------
   15.24 +% response | spoken       | written     | delivery time
   15.25 +
   15.26 +% TODO: find reference literature
   15.27 +
   15.28 +\subsection{Speed}
   15.29 +Communication gets faster in general. Slow mediums as letters get substituted by electronic mail, which is delivered within seconds. Also communication becomes more transmitted through digital channels. This can be seen at the telephone which's information is now more and more transported in bits over the internet link. Also telefaxes are succeeded by email or are transported within email. Instant messaging can be seen as the written couterpart to the telephone; not to substitute it completely, but to be used if it is more useful for the information to transmit.
   15.30 +
   15.31 +Many of the digital communication methods gained success by beeing cheaper than their counterparts. One example here is instant messaging in contrast to the telephone. As phoning costs fell, it became more popular again. The last years showed, that communication cost degreased dropped generally, caused by the transport through digital channels. And nothing to see, that would make them rise again.
   15.32 +
   15.33 +It seems as if in future will be low-cost communication methods available, which will be digitally transmitted.
   15.34 +
   15.35 +\subsection{Variety}
   15.36 +Regarding the variety of communication methods shows a change, too. Communication systems are more easy to establish today, so more get established. This leads to more methods a person uses. But not only in the amount, also in parallel. For example when two people talk to each other on the phone, one might send a URI\footnote{Uniform Resource Identifier} by email meanwhile, because oral communication is not well suited to exchange such data. Another example for in parallel used communication channels is video chatting. Ony typically sees the other person, talks to it, and additionally has a instant messaging facility for exchanging written information.
   15.37 +
   15.38 +Parallel usage of different kinds of communication channels will be important in future. The most common combinations are one for spoken and one for written information. But one for dialogs and one for sending documents will be important too.
   15.39 +
   15.40 +\subsection{Hardware}
   15.41 +Next about the hardware needed for communicating. On the one side stands the telephone, now available as the mobile phone. It provides spoken dialog by calling, spoken messages with the included answering machine and written messages in form of short message service. On the other side stands the letter and its relatives. They need pen and paper, a telefax machine or in most today's cases a computer. They typically send documents, only instant messaging is focused on dialog.
   15.42 +
   15.43 +The last years finally brought the two groups together, with \name{smart phones} being the merging element. Smart phones are computers in the size of mobile phones. They provide both functions, using it as telephones and as computers.
   15.44 +
   15.45 +It matches well the requirements of telephoning and short message service, for which it was designed of course. Also providing being suitable for instant messaging in what is needed additionally to the telephone and short message service. The only problem is the minimal keyboard available to insert text. This also affects writing documents in case of email. It can be done but not very comfortably. Further communication methods include voice and video messages.
   15.46 +
   15.47 +This leaves us with the need for ordinary computers for the field of exchanging documents, and as better input hardware for all written input.
   15.48 +
   15.49 +
   15.50 +
   15.51 +\section{Trends for electronic mail}
   15.52 +\label{sec:email-trends}
   15.53 +The previous section stated that electronic mail will still be important in future to complete the communication methods provided by phone and instant messaging.
   15.54 +
   15.55 +But will emailing in future not be the same as emailing now. This will mainly affect how email is transfered.
   15.56 +
   15.57 +\subsection{Provider oriented emailing}
   15.58 +Today's email structure is heavily dependent on email providers. This means, most people have email addresses from some provider. These can be the provider of their online connection (e.g.\ \NAME{AOL}, \name{T\~Online}), freemail provider (e.g.\ \NAME{GMX}, \name{Yahoo}, \name{Hotmail}) or provider that offer enhanced mail services that one needs to pay for. Outgoing mail is send either with the webmail client of the provider or using \name{mail user agent}s sending it to the provider for relay. Incoming mail is read with the webmail client or retrieved from the provider via \NAME{POP3} or \NAME{IMAP} to the local computer to be read in the \name{mail user agent}. This means all mail sending and receiving work is done by the provider.
   15.59 +
   15.60 +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.
   15.61 +
   15.62 +\subsection{Provider independence}
   15.63 +Nowadays, dial-up internet access is rare; the majority has broadband internet access paying a flat rate for it. So being online or not does not affect costs anymore, even traffic is unlimited. Today it is possible to have an own mail server running at home. The last technical problem remaining are the changing \NAME{IP} addresses one gets assigned every 24 hours. But this is easily solvable with one of the dynamic \NAME{DNS} services around; they provide the mapping of a fixed domain name to the changing \NAME{IP} addresses.
   15.64 +
   15.65 +Home servers become popular in these days, for central data storage and multi media services. Being assembled of energy efficient elements, power consumption is no big problem anymore. These home servers will replace video recorders and 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 is a logical step to have email and other communication will be provided by the (or one of) the own server aswell.
   15.66 +
   15.67 +After \mta{}s have not been popular for users in the last time, the next years might bring them back to them. Maybe in a few years nearly everyone will have one running at home \dots\ possibly without knowing about it.
   15.68 +
   15.69 +\subsection{Is email future-safe?}
   15.70 +It seems as if electronic mail or a similar technology has good chances to survive the next decades. This bases on the assumption that it always will be important to send information messages. These can be notes from other people, or notifications from systems (like a broken or full hard drive in the home server, or the coffee machine ran out of coffee beans). Other communication technologies are not as suitable for this kind of messages, as email, short message service, voice mail, and the like. Telephone talks are more focused on dialog and normally interrupt people. These kind of messages should not interrupt people, unless urgent, and they do not need two-way information exchange. The second argument appies to instant messaging too. If only one message is to be send, one does not need instant messaging. Thus, one type of one-way message sending technology will survive.
   15.71 +
   15.72 +Whether email will be the one surviving, or short message service, or another one, does not matter. Probably it will be \name{unified messaging}, which includes all of the other ones in it, anyway. \MTA{}s are a kind of software needed for all of these messaging methods---programs that transfer and receive messages.
   15.73 +
   15.74 +\subsection{Pushing versus polling}
   15.75 +The retrieval of email is a field that is about to change now. The old way is to fetch email by polling the server that holds the personal mail box. This polling is done in regular intervals, often once every five to thirty minutes. The mail transfer from the mail box to the \name{mail user agent} is initiated from the mail client side. The disadvantage herewith is the delay between mail actually arriving on the server and the user finally having the message on his screen.
   15.76 +
   15.77 +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 the smart phones; they were able to do emailing, but the traffic caused by polling the server often was expensive. The concept workes well with mobile phones where the provider knows about the client, but it seems not to be a choice for computers since the provider needs to have some kind of login to push data to the computer.
   15.78 +
   15.79 +The push concept, however could swap over to computers when using a home server and no external provider. A possible scenario is a home server receiving mail from the internet and pushing it to computers and smart phones. The configuration could be done by the user through some simple interface, like one configures his telephone system to have different telephone numbers ring on specified phones.
   15.80 +%FIXME: add reference to push email
   15.81 +
   15.82 +\subsection{Internet Mail 2000}
   15.83 +Another concept to redesign the electronic mail system, but this time focused on mail transfer is named ``Internet Mail 2000''. It was proposed by Daniel J.\ Bernstein, the creater of \name{qmail}. Similar approaches were independently introduced by others too.
   15.84 +
   15.85 +As main change it makes the sender have the responsibility of mail storage; only a notification about a mail message gets send to the receiver, who can 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 transfered from the sender to the receiver.
   15.86 +
   15.87 +\name{Mail transfer agent}s are still important in this mail architecture, but in a slightly different way. Their job is not transfering mail anymore---this makes the name missleading---they are used to transport the notifications about new mail to the destinations. This is a quite similar job as they do in the \NAME{SMTP} model. The real transfer of the mail can be done in any way, for example via \NAME{FTP} or \NAME{SCP}.
   15.88 +
   15.89 +%FIXME: add references for IM2000
   15.90 +
   15.91 +
   15.92 +
   15.93 +\section{\NAME{SWOT} analysis}
   15.94 +%TODO
   15.95 +
   15.96 +
   15.97 +
   15.98 +\section{What will be important}
   15.99 +\label{sec:important-for-mtas}
  15.100 +Now that it is explained why email will survive (in some changed but related form), it is time to think about the properties required for \mta{}s in the next years. As the fields and kinds of usage change, the requirement change too.
  15.101 +
  15.102 +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 one's home to set up the systems; like it is already common for problems with the power supply or water supply system. 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 itself 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 on a simple configuration interface like a web interface; non-technical educated users should be able to configure the system.
  15.103 +
  15.104 +\sendmail\ and \name{qmail} appear to have bad positions at this point. Their configuration is complex, thus they would need simplification wrappers around them to provide easy configuration.
  15.105 +
  15.106 +The approach of wrappers around the main program to make it look easier to the outside is a good concept in general. %FIXME: add ref
  15.107 +It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ a graphical program, a website, a command line program; all of them either in a questionaire style or iteractive).
  15.108 +
  15.109 +When \MTA{}s become popular on home servers and maybe even on workstations and smart phones, then performance will be less important. Providers need \mta{}s that process a large amount of mail in short time. Home servers or workstations however, do not see that much mail; they need to handle tens or hundrets of email messages per hour. Thus performance will probably not be a main requirement for an \MTA\ in the future, if they mainly run on private machines.
  15.110 +
  15.111 +\name{postfix} focuses much on performance, this might not be an important point then.
  15.112 +
  15.113 +New mailing concepts and architectures like push email or \name{Internet Mail 2000} will, if they succeed, require \mta{}s to adopt the new technology. \MTA{}s that are not able to change are going to be sorted out by evolution. Thus it is important to not focus too much on one use case, but to stay flexible. Allman saw this property of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}).
  15.114 +
  15.115 +Another important requirement for all kinds of software will be security. There is a constant trend going from completely non-secured software from the 70s and 80s over growing security awareness in the 90s to security being a primary goal now. This leads to the conclusion that software security will even more important in the next years. As more clients get connected to the internet and especially more computers are waiting for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing software systems will be done with increasing effort in future.
  15.116 +
  15.117 +``Plug-and-play''-able hardware with preconfigured software running can be expected to become popular. Like someone buys a set-top box to watch Pay-TV today, he might be buying a box acting as mail server in a few years. He plugs the power cable in, inserts his email address in a web interface and selects the clients (workstation computers or smart phones) to which mail should be send and from which mail is accepted to receive. That's all. It would just work then, like everyone expects it from a set-top box today.
  15.118 +
  15.119 +Containing secure and robust software is a pre-requisite for such boxes to make that vision possible.
  15.120 +
  15.121 +It seems as if all widely used \mta{}s provide good security nowadays. \name{qmail}'s architecture, also used in \name{postfix}, is generally seen to be conceptually more secure, however.
  15.122 +
  15.123 +In summary: easy configuration, aswell as the somehow opposed flexibility will be important for future \mta{}s. Also will it be security, but not performance. \MTA{}s might become more commodity software, like web servers already are today, with the purpose to include it in many systems and the need of minimal configuration.

    16.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    16.2 +++ b/thesis/attic/old/2-FuturesForMasqmail.tex	Thu Jan 15 12:20:21 2009 +0100
    16.3 @@ -0,0 +1,18 @@
    16.4 +\chapter{Futures for \masqmail}
    16.5 +
    16.6 +\section{\masqmail\ in five years}
    16.7 +\label{sec:masqmail-in-5-years}
    16.8 +Now how could \masqmail\ be like in, say, five years?
    16.9 +%requirements
   16.10 +%which parts to do
   16.11 +%how to make masqmail future-safe
   16.12 +
   16.13 +%how to advertise masqmail
   16.14 +%difference for free software
   16.15 +%why is it worth to revive masqmail?
   16.16 +
   16.17 +
   16.18 +\section{A design from scratch}
   16.19 +%what would be needed
   16.20 +%would one create it at all?
   16.21 +

    17.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    17.2 +++ b/thesis/attic/old/3-BecomingProjectLeader.tex	Thu Jan 15 12:20:21 2009 +0100
    17.3 @@ -0,0 +1,4 @@
    17.4 +\chapter{Becoming project leader}
    17.5 +\section{History of \masqmail}
    17.6 +\section{Taking it}
    17.7 +

    18.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    18.2 +++ b/thesis/attic/old/3-FreeSoftwareProjects.tex	Thu Jan 15 12:20:21 2009 +0100
    18.3 @@ -0,0 +1,127 @@
    18.4 +\chapter{About \freesw\ projects}
    18.5 +
    18.6 +% http://www.faqs.org/docs/artu/
    18.7 +
    18.8 +There are several differences between \freesw\ projects and projects about proprietary software.
    18.9 +To understand \freesw\ projects, one needs to understand \freesw\ itself first.
   18.10 +
   18.11 +\section{About \freesw}
   18.12 +The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
   18.13 +Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
   18.14 +One could say, the \GPL\ catalized the \name{Free Software movement}.
   18.15 +
   18.16 +% http://www.fsf.org/about/what-is-free-software
   18.17 +
   18.18 +After all, the \GPL\ was not the first \freesw\ license used.
   18.19 +The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
   18.20 +Licenses providing the same rights have been used since long time ago.
   18.21 +But none of them was so often (re)used by other projects---thus gattering less awareness.
   18.22 +Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
   18.23 +
   18.24 +\freesw\ gives freedoms to its users.
   18.25 +In contrast to proprietary software restricting the users freedom.
   18.26 +The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
   18.27 +% http://www.gnu.org/philosophy/free-sw.html
   18.28 +% http://www.fsf.org/licensing/essays/free-sw.html
   18.29 +\begin{enumerate}
   18.30 +	\item The freedom to run the program, for any purpose (freedom 0).
   18.31 +	\item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
   18.32 +	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
   18.33 +	\item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
   18.34 +\end{enumerate}
   18.35 +
   18.36 +
   18.37 +\section{The term ``Open Source''}
   18.38 +\name{Open Source Software} often stands for the same as \freesw.
   18.39 +But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
   18.40 +
   18.41 +\name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
   18.42 +
   18.43 +% http://www.gnu.org/philosophy/open-source-misses-the-point.html
   18.44 +% http://catb.org/~esr/open-source.html
   18.45 +
   18.46 +
   18.47 +\section{Development of \freesw}
   18.48 +Having source code available and the right to modify it, encouridges programmers to actually do so.
   18.49 +Their modifications are manifoldly.
   18.50 +Some tailor the software to their needs.
   18.51 +Some add features.
   18.52 +Some do it just for fun.
   18.53 +There are no limitations---whoever wants to, may work on it.
   18.54 +
   18.55 +Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
   18.56 +The process of development is watchable by everyone.
   18.57 +
   18.58 +The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
   18.59 +
   18.60 +Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
   18.61 +
   18.62 +The following text will focus on the ``bazaar'' model.
   18.63 +
   18.64 +
   18.65 +\section{The role of the community}
   18.66 +\freesw\ projects rise and fall with their community!
   18.67 +
   18.68 +Most \freesw\ programs are developed by a very small group of programmers, often only one person.
   18.69 +But they are used by many people.
   18.70 +In between the programmers and the users, are people located who are a bit of both.
   18.71 +These are the ones that write documentation, find bugs and probably even fix it.
   18.72 +They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
   18.73 +The program is often spread by their ``advertising''.
   18.74 +
   18.75 +The \emph{community} consists of the actual developers and all users that contribute to the program.
   18.76 +Contribution can be one of the described ways, or others like providing a server for the project website for example.
   18.77 +
   18.78 +\emph{Community} is everyone who is in contact through the project.
   18.79 +Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
   18.80 +
   18.81 +There will hardly be a community if no communication channels are available.
   18.82 +If the development team does not provide them, there is a chance that encouraged users set them up on their own.
   18.83 +But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
   18.84 +
   18.85 +Projects without a good community tend to die sooner or later.
   18.86 +
   18.87 +
   18.88 +\section{Evolution of a community}
   18.89 +Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
   18.90 +He starts developing.
   18.91 +When others get in contact with the project, there may be some who are so much interested that they start co-developing.
   18.92 +Others report bugs, and some only use the program.
   18.93 +
   18.94 +After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
   18.95 +The size ratio of the groups vary by type of project.
   18.96 +
   18.97 +One should have that in mind, when starting a \freesw\ project.
   18.98 +
   18.99 +
  18.100 +\section{Creating a strong community}
  18.101 +Building up a good community needs some effort of the main developers.
  18.102 +%TODO: search for documents about this topic
  18.103 +
  18.104 +First communication channels need to be set up, to enable the growth of a community.
  18.105 +
  18.106 +Second, development should be visible by everyone who is interested in it.
  18.107 +Time between work done on the project and its visibility to the public should be kept short.
  18.108 +This makes it interesting for other developers to join.
  18.109 +Developers are the core of a community.
  18.110 +
  18.111 +Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
  18.112 +Releases are (more) stable versions, primary for users.
  18.113 +They should be created, frequently.
  18.114 +People will more likely use programs of active projects.
  18.115 +
  18.116 +Fourth, the developers should try to get the users ``in the boat''.
  18.117 +Good communities have a large group of users that do not only receive, but also give something back to the project.
  18.118 +The project leaders should motivate users to contribute.
  18.119 +This unlocks a big work force and gets lot of unexiting work done.
  18.120 +
  18.121 +Fifth, documentation matters.
  18.122 +Good documentation makes it easy for users and developers to start.
  18.123 +And it helps to avoid a lot of unsatisfaction.
  18.124 +Documentation is something that shows quality and that people care about the project.
  18.125 +
  18.126 +And sixth, project leaders should be good souvereigns.
  18.127 +They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
  18.128 +
  18.129 +Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
  18.130 +Volunteer work lives by acknowledgement of the effort spent.

    19.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    19.2 +++ b/thesis/attic/old/3-MasqmailProject.tex	Thu Jan 15 12:20:21 2009 +0100
    19.3 @@ -0,0 +1,218 @@
    19.4 +\chapter{The \masqmail\ project}
    19.5 +
    19.6 +%TODO: have text by oliver here?
    19.7 +
    19.8 +\section{Purpose of \masqmail}
    19.9 +
   19.10 +\subsection{Target field}
   19.11 +Its original author, Oliver Kurth, sees \masqmail\ so:
   19.12 +\begin{quote}
   19.13 +MasqMail is a mail server designed for hosts that do not have a permanent internet connection eg. a home network or a single host at home. It has special support for connections to different ISPs. It replaces sendmail or other MTAs such as qmail or exim.
   19.14 +\end{quote}
   19.15 +
   19.16 +\masqmail\ is inteded to cover a specific niche: non-permanent internet connection and different \NAME{ISP}s.
   19.17 +
   19.18 +Although it can basically replace other \MTA{}s, it is not generally aimed to do so. The package description of \debian\citeweb{packages.debian:masqmail} states this more clearly by changing the last sentence to:
   19.19 +\begin{quote}
   19.20 +In these cases, MasqMail is a slim replacement for full-blown MTAs such as sendmail, exim, qmail or postfix.
   19.21 +\end{quote}
   19.22 +\masqmail\ is a good replacement ``in these cases'', but not generally, since is lacks features essential for running on mail servers. It is primarily not secure enough for being accessable from untrusted locations.
   19.23 +
   19.24 +The program is best used in home networks, which are non-permanently connected to the internet. \masqmail\ sends mail to local destinations, like users on the same machine and on other machines in the local net, immediately. Email to recipients outside the local net are queued when offline and sent when a online connection gets established.
   19.25 +
   19.26 +Further more does \masqmail\ respect online connections through different \NAME{ISP}s; a common thing for dial-up connections. In particular can different sender addresses be set, dependent on the \NAME{ISP} that is used. This prevents mail to be likely classified as spam.
   19.27 +
   19.28 +
   19.29 +
   19.30 +\subsection{Typical usage}
   19.31 +This section describes situations that make senseful use of \masqmail.
   19.32 +
   19.33 +A home network consisting of some workstations without a server. The network is connected to the internet by dial-up or broadband. Going online is initiated by computers inside the local net. \NAME{IP} addresses change at least once every day.
   19.34 +
   19.35 +Every workstation would be equiped with \masqmail. Mail transfer within the same machine or within the local net works straight forward. Outgoing mail to the internet is sent, to the concerning \NAME{ISP} for relaying, whenever the router goes online. Receiving of mail from outside needs to be done by a mail fetch program, like the \masqmail\ internal \NAME{POP3} client or \name{fetchmail} for example. The configuration for \masqmail\ would be the same on every computer, except the hostname.
   19.36 +
   19.37 +For the same network but having a server, one could have \masqmail\ running on the server and using simple forwarders (see \ref{subsec:relay-only}) to the server on the workstations. This setup does only support mail transfer to the server, but not back to a workstation; also sending mail to another user on the same workstation is not possible.
   19.38 +
   19.39 +A better setup is to run \masqmail\ on every machine %FIXME
   19.40 +
   19.41 +
   19.42 +
   19.43 +\subsection{What makes it special}
   19.44 +
   19.45 +As main advantage, \masqmail\ makes it easy to set up an \MTA\ on workstations or notebooks without the need to do complex configuration or to be an mail server expert.
   19.46 +
   19.47 +Workstations use %FIXME
   19.48 +
   19.49 +
   19.50 +\subsection{Alternatives?}
   19.51 +% http://anfi.homeunix.org/sendmail/dialup10.html
   19.52 +
   19.53 +\section{History}
   19.54 +%TODO: let oliver prove read it!
   19.55 +%FIXME: add references
   19.56 +%FIXME: where does the name come from: masqdialer (guessed)
   19.57 +
   19.58 +The date of the first release (version 0.0.1) is unknown.
   19.59 +The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999.
   19.60 +Further releases were made every few weeks or month during 2000, 2001 and 2002.
   19.61 +Development ended in mid-2003 in a hard stop.
   19.62 +The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
   19.63 +
   19.64 +During the time of development, Oliver released 53 versions.
   19.65 +That means a new release in less than every 20 days in average!
   19.66 +
   19.67 +Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
   19.68 +
   19.69 +One extra release (version 0.2.21) was made by him in November 2005.
   19.70 +This one is only available from the \debian\ pool.
   19.71 +Comparing it to version 0.2.20 shows, that no source code was altered.
   19.72 +Only building documents (like Makefiles) and \debian\ packageing documents were changed.
   19.73 +That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
   19.74 +
   19.75 +In May 2000 the minor version number increased to `1'.
   19.76 +Nothing special is mentioned in the documentation about that.
   19.77 +When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail.
   19.78 +At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series.
   19.79 +His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.
   19.80 +
   19.81 +
   19.82 +
   19.83 +\section{Taking \masqmail}
   19.84 +
   19.85 +
   19.86 +
   19.87 +
   19.88 +\section{About \freesw\ projects}
   19.89 +
   19.90 +% http://www.faqs.org/docs/artu/
   19.91 +
   19.92 +There are several differences between \freesw\ projects and projects about proprietary software.
   19.93 +To understand \freesw\ projects, one needs to understand \freesw\ itself first.
   19.94 +
   19.95 +\subsection{About \freesw}
   19.96 +The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
   19.97 +Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
   19.98 +One could say, the \GPL\ catalized the \name{Free Software movement}.
   19.99 +
  19.100 +% http://www.fsf.org/about/what-is-free-software
  19.101 +
  19.102 +After all, the \GPL\ was not the first \freesw\ license used.
  19.103 +The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
  19.104 +Licenses providing the same rights have been used since long time ago.
  19.105 +But none of them was so often (re)used by other projects---thus gattering less awareness.
  19.106 +Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
  19.107 +
  19.108 +\freesw\ gives freedoms to its users.
  19.109 +In contrast to proprietary software restricting the users freedom.
  19.110 +The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
  19.111 +% http://www.gnu.org/philosophy/free-sw.html
  19.112 +% http://www.fsf.org/licensing/essays/free-sw.html
  19.113 +\begin{enumerate}
  19.114 +	\item The freedom to run the program, for any purpose (freedom 0).
  19.115 +	\item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
  19.116 +	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
  19.117 +	\item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
  19.118 +\end{enumerate}
  19.119 +
  19.120 +
  19.121 +\subsection{The term ``Open Source''}
  19.122 +\name{Open Source Software} often stands for the same as \freesw.
  19.123 +But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
  19.124 +
  19.125 +\name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
  19.126 +
  19.127 +% http://www.gnu.org/philosophy/open-source-misses-the-point.html
  19.128 +% http://catb.org/~esr/open-source.html
  19.129 +
  19.130 +
  19.131 +\subsection{Development of \freesw}
  19.132 +Having source code available and the right to modify it, encouridges programmers to actually do so.
  19.133 +Their modifications are manifoldly.
  19.134 +Some tailor the software to their needs.
  19.135 +Some add features.
  19.136 +Some do it just for fun.
  19.137 +There are no limitations---whoever wants to, may work on it.
  19.138 +
  19.139 +Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
  19.140 +The process of development is watchable by everyone.
  19.141 +
  19.142 +The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
  19.143 +
  19.144 +Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
  19.145 +
  19.146 +The following text will focus on the ``bazaar'' model.
  19.147 +
  19.148 +
  19.149 +\subsection{The role of the community}
  19.150 +\freesw\ projects rise and fall with their community!
  19.151 +
  19.152 +Most \freesw\ programs are developed by a very small group of programmers, often only one person.
  19.153 +But they are used by many people.
  19.154 +In between the programmers and the users, are people located who are a bit of both.
  19.155 +These are the ones that write documentation, find bugs and probably even fix it.
  19.156 +They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
  19.157 +The program is often spread by their ``advertising''.
  19.158 +
  19.159 +The \emph{community} consists of the actual developers and all users that contribute to the program.
  19.160 +Contribution can be one of the described ways, or others like providing a server for the project website for example.
  19.161 +
  19.162 +\emph{Community} is everyone who is in contact through the project.
  19.163 +Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
  19.164 +
  19.165 +There will hardly be a community if no communication channels are available.
  19.166 +If the development team does not provide them, there is a chance that encouraged users set them up on their own.
  19.167 +But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
  19.168 +
  19.169 +Projects without a good community tend to die sooner or later.
  19.170 +
  19.171 +
  19.172 +\subsection{Evolution of a community}
  19.173 +Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
  19.174 +He starts developing.
  19.175 +When others get in contact with the project, there may be some who are so much interested that they start co-developing.
  19.176 +Others report bugs, and some only use the program.
  19.177 +
  19.178 +After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
  19.179 +The size ratio of the groups vary by type of project.
  19.180 +
  19.181 +One should have that in mind, when starting a \freesw\ project.
  19.182 +
  19.183 +
  19.184 +\subsection{Creating a strong community}
  19.185 +Building up a good community needs some effort of the main developers.
  19.186 +%TODO: search for documents about this topic
  19.187 +
  19.188 +First communication channels need to be set up, to enable the growth of a community.
  19.189 +
  19.190 +Second, development should be visible by everyone who is interested in it.
  19.191 +Time between work done on the project and its visibility to the public should be kept short.
  19.192 +This makes it interesting for other developers to join.
  19.193 +Developers are the core of a community.
  19.194 +
  19.195 +Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
  19.196 +Releases are (more) stable versions, primary for users.
  19.197 +They should be created, frequently.
  19.198 +People will more likely use programs of active projects.
  19.199 +
  19.200 +Fourth, the developers should try to get the users ``in the boat''.
  19.201 +Good communities have a large group of users that do not only receive, but also give something back to the project.
  19.202 +The project leaders should motivate users to contribute.
  19.203 +This unlocks a big work force and gets lot of unexiting work done.
  19.204 +
  19.205 +Fifth, documentation matters.
  19.206 +Good documentation makes it easy for users and developers to start.
  19.207 +And it helps to avoid a lot of unsatisfaction.
  19.208 +Documentation is something that shows quality and that people care about the project.
  19.209 +
  19.210 +And sixth, project leaders should be good souvereigns.
  19.211 +They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
  19.212 +
  19.213 +Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
  19.214 +Volunteer work lives by acknowledgement of the effort spent.
  19.215 +
  19.216 +
  19.217 +
  19.218 +
  19.219 +
  19.220 +\section{Project infrastructure}
  19.221 +

    20.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    20.2 +++ b/thesis/attic/old/3-ProjectManagement.tex	Thu Jan 15 12:20:21 2009 +0100
    20.3 @@ -0,0 +1,8 @@
    20.4 +\chapter{Project management}
    20.5 +\section{Infrastructure}
    20.6 +\section{Community}
    20.7 +\section{Development}
    20.8 +\section{Documentation}
    20.9 +\section{Quality assurance}
   20.10 +\section{Distribution}
   20.11 +

    21.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    21.2 +++ b/thesis/attic/old/4-CodeAnalysis.tex	Thu Jan 15 12:20:21 2009 +0100
    21.3 @@ -0,0 +1,29 @@
    21.4 +\chapter{Code analysis}
    21.5 +
    21.6 +
    21.7 +\section{Architecture}
    21.8 +Like its anchestor \sendmail, \masqmail\ is a monolitic program. It consists of only one \emph{setuid root}\footnote{Runs as user root, no matter which user invoked it.}\index{setuid root} binary file, named \path{masqmail}. All functionality is included in it; of course some more comes from dynamic libraries linked.
    21.9 +
   21.10 +
   21.11 +
   21.12 +\subsection{Structure}
   21.13 +The \masqmail\ executable can be called under various names for \name{sendmail-compatibility} reasons. This is commonly organized by creating symbolic links with with different names to the \masqmail\ executable. These are \path{/usr/lib/sendmail} and \path{/usr/sbin/sendmail} because many programs expect a \mta\ to be located there. Further more \sendmail\ provides shortcuts by calling it with a different name instead of supplying command line arguments. The best known of it is \path{mailq}, which is equivilent to calling the \MTA\ with the argument \verb+-bq+. \masqmail\ reacts to the names \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The last four are an addition to \sendmail. Not implemented is the name \path{newaliases} because it is not relevant to \masqmail. To provide the command nonetheless, one may write a shell script located at \path{/usr/bin/newaliases}, that simply invokes \verb+masqmail -bi+.
   21.14 +
   21.15 +%masqmail: mailq, mailrm, runq, rmail, smtpd/in.smtpd
   21.16 +%sendmail: hoststat, mailq, newaliases, purgestat, smtpd
   21.17 +
   21.18 +\masqmail\ is written in the \NAME{C} programming language. The program, as of version 0.2.21, consists of 34 source code and eight header files, containing about 9,000 lines of code\footnote{Measured with \name{sloccount} by David A.\ Wheeler.}. Additionally, it includes a \name{base64} implementation (about 300 lines) and \name{md5} code (about 150 lines). For systems that do not provide \name{libident}, this library is distributed as well (circa 600 lines); an available shared library however has higher precedence in linking.
   21.19 +
   21.20 +The only mandatory dependency is \name{glib}---a cross-platform software utility library, originated in the \NAME{GTK+} project. It provides safer replacements for many standard library functions. (The unsafe \verb+sprintf()+ is one example.) Also it offers handy data containers, easy-to-use implementations of data structures, and much more.
   21.21 +
   21.22 +With \masqmail\ comes the small tool \path{mservdetect}; it helps setting up a configuration that uses the \name{mserver} system to detect the online state. Two other binaries get compiled for testing purposes: \path{readtest} and \path{smtpsend}. All three programms use \masqmail\ source code; they only add a file with a \verb+main()+ function each.
   21.23 +
   21.24 +\masqmail\ does not provide an interface for modules with additional functionality. There exists no add-on or module system. But the code is separated by function to the various source files, and some functional parts can be included or excluded by defining symbols. This means adding some argument (like \verb+--enable-maildir+) to the \verb+configure+ call. Thus the concerning code gets not removed by the preprocessor.
   21.25 +
   21.26 +
   21.27 +
   21.28 +
   21.29 +\section{Code quality}
   21.30 +
   21.31 +
   21.32 +\section{Security}

    22.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    22.2 +++ b/thesis/attic/old/4-Experience.tex	Thu Jan 15 12:20:21 2009 +0100
    22.3 @@ -0,0 +1,2 @@
    22.4 +\chapter{Experience}
    22.5 +

    23.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    23.2 +++ b/thesis/attic/old/4-Improvements.tex	Thu Jan 15 12:20:21 2009 +0100
    23.3 @@ -0,0 +1,2 @@
    23.4 +\chapter{Improvements}
    23.5 +

    24.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    24.2 +++ b/thesis/attic/old/4-ProjectManagement.tex	Thu Jan 15 12:20:21 2009 +0100
    24.3 @@ -0,0 +1,2 @@
    24.4 +\chapter{Project management 2}
    24.5 +

    25.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    25.2 +++ b/thesis/attic/old/4-Test.tex	Thu Jan 15 12:20:21 2009 +0100
    25.3 @@ -0,0 +1,2 @@
    25.4 +\chapter{Test and validation}
    25.5 +

    26.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    26.2 +++ b/thesis/attic/old/5-Future.tex	Thu Jan 15 12:20:21 2009 +0100
    26.3 @@ -0,0 +1,2 @@
    26.4 +\chapter{The future of \masqmail}
    26.5 +

    27.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    27.2 +++ b/thesis/attic/old/5-Summary.tex	Thu Jan 15 12:20:21 2009 +0100
    27.3 @@ -0,0 +1,2 @@
    27.4 +\chapter{Summary}
    27.5 +

    28.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    28.2 +++ b/thesis/attic/requirements.tex	Thu Jan 15 12:20:21 2009 +0100
    28.3 @@ -0,0 +1,38 @@
    28.4 +\chapter{Use cases}
    28.5 +
    28.6 +Here follow typical use cases for \masqmail. If other \MTA{}s are better suited for certain use cases, it will be mentioned. The use cases are prestage for defining the requirements.
    28.7 +
    28.8 +%FIXME: rewrite!
    28.9 +%       How do I write use cases??
   28.10 +%       Are use cases the right tool for what I need, at all??
   28.11 +
   28.12 +The user writes email with one of the common programs (e.g. \path{/bin/mail} or \name{mutt}). \masqmail\ must provide an interface, to that prepared mail can be handled over.
   28.13 +
   28.14 +\masqmail\ must deliver mail to its destination.
   28.15 +
   28.16 +Mail must be send with different settings, if someone uses more than one internet connection.
   28.17 +
   28.18 +If the machine is offline, no mail, destinated to the internet, must be send. It needs to be queued until an online connection gets established.
   28.19 +
   28.20 +If the computer goes online, all mail for outside destinations, should be send through the active route.
   28.21 +
   28.22 +Local mail should be send at once, independent of the online state.
   28.23 +
   28.24 +\masqmail\ may act as \NAME{SMTP} server. To receive email from other hosts.
   28.25 +
   28.26 +Mail for local users should be delivered by \masqmail\ itself or passed to \name{mail delivery agent}s.
   28.27 +
   28.28 +\masqmail\ needs to provide the same interface as \sendmail\ has, for being a drop-in replacement.
   28.29 +
   28.30 +
   28.31 +%TODO: add Schaeffter's ideas here
   28.32 +\chapter{Requirements}
   28.33 +
   28.34 +\section{Structure}
   28.35 +\section{Security}
   28.36 +\section{Usability}
   28.37 +\chapter{Security issues}
   28.38 +
   28.39 +%TODO: write about:
   28.40 +% #ifdefs in code
   28.41 +% the single setuid root binary

    29.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    29.2 +++ b/thesis/attic/spam-checking.txt	Thu Jan 15 12:20:21 2009 +0100
    29.3 @@ -0,0 +1,89 @@
    29.4 +
    29.5 +%(eisentraut05: page 25) ``Ganz ohne Analyse während der SMTP-Phase kommt sowieso kein MTA aus, und es ist eine Frage der Einschätzung, wie weit man diese Phase belasten möchte.''
    29.6 +
    29.7 +
    29.8 +checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
    29.9 +checks when mail is accepted and queued: external (amavis, spamassassin)
   29.10 +
   29.11 +where to filter what
   29.12 +
   29.13 +
   29.14 +postfix:
   29.15 +content-filter: arbitrary programs that talk smtp, can filter, rewrite or delete mail
   29.16 +- before-queue-c-f: need to be fast, can prevent system load
   29.17 +- after-queue-c-f: need more resources in global, more load
   29.18 +
   29.19 +exim:
   29.20 +acls: to filter, what to accept (hook into smtp dialog) (complex)
   29.21 +routers: take recipient address and choose a matching transport
   29.22 +transports: ways to deliver mail (smtp, local)
   29.23 +
   29.24 +
   29.25 +postfix: after-queue-content-filter (smtp communication)
   29.26 +exim: content-scan-feature (analyses the content: MIME stuff, blacklisted words, virus scanning) (all within smtp dialog)
   29.27 +sendmail: milter (tcp or unix sockets)
   29.28 +
   29.29 +
   29.30 +
   29.31 +
   29.32 +
   29.33 +
   29.34 +
   29.35 +%what do do with recognized mail?
   29.36 +%- reject (only possible if recognized during SMTP dialog)
   29.37 +%- forward with added header line or changed subject
   29.38 +%(eisentraut05: page 18--20)
   29.39 +
   29.40 +check incoming and outgoing mail
   29.41 +(eisentraut05: page 21)
   29.42 +
   29.43 +
   29.44 +milter:
   29.45 +communication with external daemons via a special protocol
   29.46 +at various times in the smtp dialog possible
   29.47 +can reject, delete or alter messages
   29.48 +http://milter.org
   29.49 +(eisentraut05: page 69)
   29.50 +
   29.51 +
   29.52 +use SA with exim:
   29.53 +- with transport: piped into sa
   29.54 +- content-scanning-feature: with ACL during smtp dialog
   29.55 +- plugin: sa-exim
   29.56 +- within amavis
   29.57 +
   29.58 +use SA with sendmail:
   29.59 +- with milter
   29.60 +- within mimedefang or amavis
   29.61 +
   29.62 +use SA with postfix:
   29.63 +- within amavis or mailfilter
   29.64 +
   29.65 +
   29.66 +
   29.67 +
   29.68 +DNSBL can contain:
   29.69 +- open relays
   29.70 +- dynamic IP addresses
   29.71 +- verified spam sources
   29.72 +- open multistage relays
   29.73 +- vulnerable CGI scripts
   29.74 +- open proxy servers
   29.75 +example: NJABL (http://njabl.org)
   29.76 +
   29.77 +DNSBL in smpt dialog is aggressive and can lead to problems (eisentraut05: page 126)
   29.78 +
   29.79 +
   29.80 +greylisting:
   29.81 +if first contact from that address: temp failure and add to list
   29.82 +sender will retry, then accept
   29.83 +
   29.84 +``Das Greylisting zählt derzeit zu den effektivsten Methoden, um gegen unerwünschte E-Mails vorzugehen. Allein durch Greylisting können derzeit rund 70\% des potenziellen Spam-Aufkommens auf einem Mailserver vollständig geblockt werden. Allerdings ist es auch nur eine Frage der Zeit, bis sich die Gemeinde der Spammer und Virenautoren auf diese Methode der Spam-Bekämpfung eingerichtet und entsprechende Queues in ihre Software eingebaut hat.''(eisentraut05: page 138)
   29.85 +Probleme: load balancing using multiple servers with different IPs.
   29.86 +postfix: with policy server
   29.87 +exim: direct in config
   29.88 +sendmail: with greylist milter
   29.89 +
   29.90 +
   29.91 +
   29.92 +hashcash

    30.1 --- a/thesis/pieces/about-masqmail.tex	Thu Jan 15 12:16:43 2009 +0100
    30.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    30.3 @@ -1,24 +0,0 @@
    30.4 -\chapter{About \masqmail}
    30.5 -
    30.6 -%TODO: have text by oliver here
    30.7 -%TODO: let oliver prove read it!
    30.8 -
    30.9 -This chapter describes the history and evolution of \masqmail.
   30.10 -
   30.11 -
   30.12 -\section{History and evolution}
   30.13 -The \masqmail\ program was written by Oliver Kurth, starting in 1999. His aim was to create a \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ handles situations which are rarely solveable with the common \MTA{}s.
   30.14 -
   30.15 -The date of the first release (version 0.0.1) is unknown, but it was packaged for \debian\ at 15\nth\ of September in 1999. Further releases were made every few weeks or month during 2000, 2001 and 2002. Development ended in mid-2003 in a hard stop. The last release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
   30.16 -
   30.17 -During the time of development, Oliver released 53 versions. That means a new release in less than every 20 days in average!
   30.18 -
   30.19 -Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
   30.20 -
   30.21 -One extra release (version 0.2.21) was made by him in November 2005. This one is only available from the \debian\ pool. Comparing it to version 0.2.20 shows, that no source code was altered. Only building documents (like Makefiles) and \debian\ packageing documents were changed. That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
   30.22 -
   30.23 -In May 2000 the minor version number increased to `1'. Nothing special is mentioned in the documentation about that. When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail. At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series. His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.
   30.24 -
   30.25 -
   30.26 -\section{\masqmail\ on the web}
   30.27 -

    31.1 --- a/thesis/pieces/about-mta.tex	Thu Jan 15 12:16:43 2009 +0100
    31.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    31.3 @@ -1,35 +0,0 @@
    31.4 -\chapter{About \name{mail transfer agent}s}
    31.5 -
    31.6 -% TODO: describe content of this chapter here
    31.7 -
    31.8 -
    31.9 -\section{What is a \name{mail transfer agent}?}
   31.10 -The basic job of a \name{mail transfer agent} (or \name{mail transport agent}, short \NAME{MTA}) is to transfer/transport \name{electronic mail} (short \name{email}) from one host to another.
   31.11 -
   31.12 -% TODO: include definitions from others here (cites)
   31.13 -
   31.14 -
   31.15 -\section{History of \NAME{MTA}s}
   31.16 -% FIXME: is that true?
   31.17 -In the old days, the 70s, when Unix was created, computers were expensive. Universities and big firms normally had a single server with an amount of terminals connected to it. The computer filled a whole room somewhere in the cellar. People were operating at the terminals that were located in the offices and wired to the server. At that time, there was hardly no networking at all.
   31.18 -
   31.19 -During the following years, when computers became affordable and so more common (but still no personal computers at that time), connections between single computers were established. Inter-university connections were one of the first networks.
   31.20 -
   31.21 -Electronic mail is a basic concept in Unix. A lot of information gets distributed via system mail on Unix machines. System mail is electronic mail that stays on one machine. In nowadays this is primary notifications from system programs. But back then, there were frequently sent emails between users on the same machine.
   31.22 -
   31.23 -When computers were connected to each other and networks grew, the need appered to send electronic mail from one machine to another. E.g. Alice sitting on a terminal connected to server1 wants to send email to Bob sitting on a terminal connected to server2.
   31.24 -
   31.25 -Unix provided everything for that task, except a good tool to do the mail transport from server1 to server2.
   31.26 -
   31.27 -At that point the fathers of Unix at \name{Bell Labs} wrote the \NAME{UUCP} program and its compagnons. At about the same time in Berkeley a different solution for the same problem was developed: Eric Allman wrote \name{sendmail}.\footnote{To be exact: He wrote \name{delivermail} which he enhanced to \name{sendmail}.}
   31.28 -
   31.29 -
   31.30 -\section{About \name{sendmail}}
   31.31 -\name{sendmail} is the defacto-standard for \name{mail transfer agents}.
   31.32 -
   31.33 -% FIXME: is that true?
   31.34 -It was the first \NAME{MTA} and had no real alternative for a long time.
   31.35 -
   31.36 -All other existing substitutes, which are mainly \name{postfix}, \name{exim}, \name{qmail} and the here regarded \name{masqmail}, mimic \name{sendmail}'s behavior. Especially, they all create a symbolic link named ``sendmail'' pointing to their own executable. This is because a lot of programs assume there is an executable called ``sendmail'' on every computer system.
   31.37 -
   31.38 -Besides being the ``standard'', \name{sendmail} probably is the most scalable and powerful solution for transfering emails and definatly the most flexible one.

    32.1 --- a/thesis/pieces/bcg_ansoff.tex	Thu Jan 15 12:16:43 2009 +0100
    32.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    32.3 @@ -1,53 +0,0 @@
    32.4 -%\subsubsection*{\NAME{BCG} matrix}
    32.5 -%
    32.6 -%\begin{figure}
    32.7 -%	\begin{center}
    32.8 -%		\begin{verbatim}
    32.9 -% ---------------------------------------------------
   32.10 -%             |                  |                  |
   32.11 -% high market |  ?               | *                |
   32.12 -% growth      |                  |                  |
   32.13 -%             |                  |                  |
   32.14 -% ---------------------------------------------------
   32.15 -%             |                  |                  |
   32.16 -% low market  |  dog             | cow              |
   32.17 -% growth      |                  |                  |
   32.18 -%             |                  |                  |
   32.19 -% ---------------------------------------------------
   32.20 -%             |                  |                  |
   32.21 -%             | small rel.       | large rel.       |
   32.22 -%             | market share     | market share     |
   32.23 -%             |                  |                  |
   32.24 -%		\end{verbatim}
   32.25 -%	\end{center}
   32.26 -%	\caption{\NAME{BCG} matrix for electronic communication}
   32.27 -%	\label{fig:comm-bcg}
   32.28 -%\end{figure}
   32.29 -%
   32.30 -%
   32.31 -%
   32.32 -%\subsubsection*{Ansoff matrix}
   32.33 -%
   32.34 -%\begin{figure}
   32.35 -%	\begin{center}
   32.36 -%		\begin{verbatim}
   32.37 -% ---------------------------------------------------
   32.38 -%             |                  |                  |
   32.39 -% current     | email            | im               |
   32.40 -% products    |                  |                  |
   32.41 -%             |                  |                  |
   32.42 -% ---------------------------------------------------
   32.43 -%             |                  |                  |
   32.44 -% new         | UM               |                  |
   32.45 -% products    |                  |                  |
   32.46 -%             |                  |                  |
   32.47 -% ---------------------------------------------------
   32.48 -%             |                  |                  |
   32.49 -%             | current          | new              |
   32.50 -%             | market           | market           |
   32.51 -%             |                  |                  |
   32.52 -%		\end{verbatim}
   32.53 -%	\end{center}
   32.54 -%	\caption{Ansoff matrix for electronic communication}
   32.55 -%	\label{fig:comm-ansoff}
   32.56 -%\end{figure}

    33.1 --- a/thesis/pieces/e-comm-trends.tex	Thu Jan 15 12:16:43 2009 +0100
    33.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    33.3 @@ -1,12 +0,0 @@
    33.4 -\subsubsection*{Speed}
    33.5 -Communication gets faster in general. Slow mediums as letters get substituted by electronic mail, which is delivered within seconds. Also communication becomes more transmitted through digital channels. This can be seen at the telephone which's information is now more and more transported in bits over the internet link. Also telefaxes are succeeded by email or are transported within email. Instant messaging can be seen as the written couterpart to the telephone; not to substitute it completely, but to be used if it is more useful for the information to transmit.
    33.6 -
    33.7 -Many of the digital communication methods gained success by beeing cheaper than their counterparts. One example here is instant messaging in contrast to the telephone. As phoning costs fell, it became more popular again. The last years showed, that communication cost degreased dropped generally, caused by the transport through digital channels. And nothing to see, that would make them rise again.
    33.8 -
    33.9 -It seems as if in future will be low-cost communication methods available, which will be digitally transmitted.
   33.10 -
   33.11 -
   33.12 -\subsubsection*{Parallel usage}
   33.13 -Regarding the variety of communication methods shows a change, too. Communication systems are more easy to establish today, so more get established. This leads to more methods a person uses. But not only in the amount, also in parallel. For example when two people talk to each other on the phone, one might send a \NAME{URI}\footnote{Uniform Resource Identifier} by email meanwhile, because oral communication is not well suited to exchange such data. Another example for in parallel used communication channels is video chatting. Ony typically sees the other person, talks to it, and additionally has a instant messaging facility for exchanging written information.
   33.14 -
   33.15 -Parallel usage of different kinds of communication channels will be important in future. The most common combinations are one for spoken and one for written information. But one for dialogs and one for sending documents will be important too.

    34.1 --- a/thesis/pieces/foo.tex	Thu Jan 15 12:16:43 2009 +0100
    34.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    34.3 @@ -1,152 +0,0 @@
    34.4 -\chapter{something}
    34.5 -laber. \cite{brooks95}
    34.6 -
    34.7 -Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
    34.8 -incididunt ut labore et dolore magna aliqua. \url{http://marmaro.de/docs} Ut enim ad minim veniam, quis
    34.9 -nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   34.10 -
   34.11 -hallo \path{/usr/local/share/man1234} blubb \name{masqmail} laber bla \NAME{ANSI} laber \NAME{RFCs} laber 
   34.12 -
   34.13 -\begin{code}{label}{caption}
   34.14 -\begin{lstlisting}
   34.15 -127.0.0.1       pantheon.schnalke.local localhost.localdomain
   34.16 -127.0.0.1       localhost pantheon
   34.17 -192.168.0.100   serveme intranet deb deb.marmaro.de deb.prog.marmaro.de
   34.18 -192.168.0.100   hg hg.marmaro.de hg.prog.marmaro.de
   34.19 -	192.168.0.40    kugel
   34.20 -192.168.0.102   karton
   34.21 -192.168.0.103   milk
   34.22 -192.168.0.74    dream
   34.23 -
   34.24 -
   34.25 -# The following lines are desirable for IPv6 capable hosts
   34.26 -::1     ip6-localhost ip6-loopback
   34.27 -\end{lstlisting}
   34.28 -\end{code}
   34.29 -
   34.30 -\section{blubb}
   34.31 -
   34.32 -Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
   34.33 -incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
   34.34 -nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   34.35 -
   34.36 -\begin{code}{}{}
   34.37 -\begin{verbatim}
   34.38 -$ make clean
   34.39 -latexmk -c
   34.40 -This is latexmk, John Collins, 2 June 2004, version: 3.07a.
   34.41 -**** Report bugs etc to John Collins <collins at phys.psu.edu>. ****
   34.42 -\end{verbatim}
   34.43 -\end{code}
   34.44 -
   34.45 -\section{blah}
   34.46 -
   34.47 -Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
   34.48 -incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
   34.49 -nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   34.50 -
   34.51 -Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
   34.52 -fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
   34.53 -culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit
   34.54 -amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore
   34.55 -et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation
   34.56 -ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor
   34.57 -in reprehenderit in voluptate velit esse. Cillum dolore eu fugiat nulla
   34.58 -pariatur.
   34.59 -
   34.60 -Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia
   34.61 -deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur
   34.62 -adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
   34.63 -aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
   34.64 -ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
   34.65 -voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
   34.66 -occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim\index{Texteditor}
   34.67 -id est laborum.
   34.68 -
   34.69 -Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
   34.70 -aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
   34.71 -voluptate velit esse cillum dolore eu fugiat nulla pariatur. Duis aute irure
   34.72 -dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
   34.73 -pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
   34.74 -officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,
   34.75 -consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et
   34.76 -dolore magna aliqua.
   34.77 -
   34.78 -\chapter{muh}
   34.79 -
   34.80 -Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
   34.81 -aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
   34.82 -voluptate velit esse cillum dolore eu fugiat nulla pariatur. Duis aute irure
   34.83 -dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
   34.84 -pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
   34.85 -officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,
   34.86 -consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et
   34.87 -dolore magna aliqua.
   34.88 -
   34.89 -
   34.90 -\section{mäh}
   34.91 -
   34.92 -Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
   34.93 -incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis\index{Texteditor}
   34.94 -nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   34.95 -
   34.96 -Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
   34.97 -fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
   34.98 -culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit
   34.99 -amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore
  34.100 -et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation
  34.101 -ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor
  34.102 -in reprehenderit in voluptate velit esse. Cillum dolore eu fugiat nulla
  34.103 -pariatur.
  34.104 -
  34.105 -Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia
  34.106 -deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur
  34.107 -adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
  34.108 -aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
  34.109 -ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
  34.110 -voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
  34.111 -occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim
  34.112 -id est laborum.
  34.113 -
  34.114 -Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
  34.115 -aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
  34.116 -voluptate velit esse cillum dolore eu fugiat nulla pariatur. Duis aute irure
  34.117 -dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
  34.118 -pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
  34.119 -officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,
  34.120 -consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et
  34.121 -dolore magna aliqua.
  34.122 -
  34.123 -\section{miau}
  34.124 -
  34.125 -Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
  34.126 -incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
  34.127 -nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
  34.128 -
  34.129 -Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
  34.130 -fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
  34.131 -culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit
  34.132 -amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore
  34.133 -et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation
  34.134 -ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor
  34.135 -in reprehenderit in voluptate velit esse. Cillum dolore eu fugiat nulla
  34.136 -pariatur.
  34.137 -
  34.138 -Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia
  34.139 -deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur
  34.140 -\index{Prototyp}
  34.141 -adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
  34.142 -aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
  34.143 -ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in\index{Daten}
  34.144 -voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
  34.145 -occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim
  34.146 -id est laborum.
  34.147 -
  34.148 -Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
  34.149 -aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in
  34.150 -voluptate velit esse cillum dolore eu fugiat nulla pariatur. Duis aute irure
  34.151 -dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
  34.152 -pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
  34.153 -officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet,\index{Texteditor}
  34.154 -consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et
  34.155 -dolore magna aliqua.

    35.1 --- a/thesis/pieces/free-software-projects.tex	Thu Jan 15 12:16:43 2009 +0100
    35.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    35.3 @@ -1,128 +0,0 @@
    35.4 -\section{About \freesw\ projects}
    35.5 -
    35.6 -% http://www.faqs.org/docs/artu/
    35.7 -
    35.8 -There are several differences between \freesw\ projects and projects about proprietary software.
    35.9 -To understand \freesw\ projects, one needs to understand \freesw\ itself first.
   35.10 -
   35.11 -\subsection{About \freesw}
   35.12 -The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
   35.13 -Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
   35.14 -One could say, the \GPL\ catalized the \name{Free Software movement}.
   35.15 -
   35.16 -% http://www.fsf.org/about/what-is-free-software
   35.17 -
   35.18 -After all, the \GPL\ was not the first \freesw\ license used.
   35.19 -The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
   35.20 -Licenses providing the same rights have been used since long time ago.
   35.21 -But none of them was so often (re)used by other projects---thus gattering less awareness.
   35.22 -Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
   35.23 -
   35.24 -\freesw\ gives freedoms to its users.
   35.25 -In contrast to proprietary software restricting the users freedom.
   35.26 -The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
   35.27 -% http://www.gnu.org/philosophy/free-sw.html
   35.28 -% http://www.fsf.org/licensing/essays/free-sw.html
   35.29 -\begin{enumerate}
   35.30 -	\item The freedom to run the program, for any purpose (freedom 0).
   35.31 -	\item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
   35.32 -	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
   35.33 -	\item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
   35.34 -\end{enumerate}
   35.35 -
   35.36 -
   35.37 -\subsection{The term ``Open Source''}
   35.38 -\name{Open Source Software} often stands for the same as \freesw.
   35.39 -But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
   35.40 -
   35.41 -\name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
   35.42 -
   35.43 -% http://www.gnu.org/philosophy/open-source-misses-the-point.html
   35.44 -% http://catb.org/~esr/open-source.html
   35.45 -
   35.46 -
   35.47 -\subsection{Development of \freesw}
   35.48 -Having source code available and the right to modify it, encouridges programmers to actually do so.
   35.49 -Their modifications are manifoldly.
   35.50 -Some tailor the software to their needs.
   35.51 -Some add features.
   35.52 -Some do it just for fun.
   35.53 -There are no limitations---whoever wants to, may work on it.
   35.54 -
   35.55 -Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
   35.56 -The process of development is watchable by everyone.
   35.57 -
   35.58 -The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
   35.59 -
   35.60 -Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
   35.61 -
   35.62 -The following text will focus on the ``bazaar'' model.
   35.63 -
   35.64 -
   35.65 -\subsection{The role of the community}
   35.66 -\freesw\ projects rise and fall with their community!
   35.67 -
   35.68 -Most \freesw\ programs are developed by a very small group of programmers, often only one person.
   35.69 -But they are used by many people.
   35.70 -In between the programmers and the users, are people located who are a bit of both.
   35.71 -These are the ones that write documentation, find bugs and probably even fix it.
   35.72 -They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
   35.73 -The program is often spread by their ``advertising''.
   35.74 -
   35.75 -The \emph{community} consists of the actual developers and all users that contribute to the program.
   35.76 -Contribution can be one of the described ways, or others like providing a server for the project website for example.
   35.77 -
   35.78 -\emph{Community} is everyone who is in contact through the project.
   35.79 -Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
   35.80 -
   35.81 -There will hardly be a community if no communication channels are available.
   35.82 -If the development team does not provide them, there is a chance that encouraged users set them up on their own.
   35.83 -But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
   35.84 -
   35.85 -Projects without a good community tend to die sooner or later.
   35.86 -
   35.87 -
   35.88 -\subsection{Evolution of a community}
   35.89 -Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
   35.90 -He starts developing.
   35.91 -When others get in contact with the project, there may be some who are so much interested that they start co-developing.
   35.92 -Others report bugs, and some only use the program.
   35.93 -
   35.94 -After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
   35.95 -The size ratio of the groups vary by type of project.
   35.96 -
   35.97 -One should have that in mind, when starting a \freesw\ project.
   35.98 -
   35.99 -
  35.100 -\subsection{Creating a strong community}
  35.101 -Building up a good community needs some effort of the main developers.
  35.102 -%TODO: search for documents about this topic
  35.103 -
  35.104 -First communication channels need to be set up, to enable the growth of a community.
  35.105 -
  35.106 -Second, development should be visible by everyone who is interested in it.
  35.107 -Time between work done on the project and its visibility to the public should be kept short.
  35.108 -This makes it interesting for other developers to join.
  35.109 -Developers are the core of a community.
  35.110 -
  35.111 -Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
  35.112 -Releases are (more) stable versions, primary for users.
  35.113 -They should be created, frequently.
  35.114 -People will more likely use programs of active projects.
  35.115 -
  35.116 -Fourth, the developers should try to get the users ``in the boat''.
  35.117 -Good communities have a large group of users that do not only receive, but also give something back to the project.
  35.118 -The project leaders should motivate users to contribute.
  35.119 -This unlocks a big work force and gets lot of unexiting work done.
  35.120 -
  35.121 -Fifth, documentation matters.
  35.122 -Good documentation makes it easy for users and developers to start.
  35.123 -And it helps to avoid a lot of unsatisfaction.
  35.124 -Documentation is something that shows quality and that people care about the project.
  35.125 -
  35.126 -And sixth, project leaders should be good souvereigns.
  35.127 -They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
  35.128 -
  35.129 -Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
  35.130 -Volunteer work lives by acknowledgement of the effort spent.
  35.131 -

    36.1 --- a/thesis/pieces/masqmail-history.tex	Thu Jan 15 12:16:43 2009 +0100
    36.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    36.3 @@ -1,27 +0,0 @@
    36.4 -\section{History}
    36.5 -%TODO: let oliver prove read it!
    36.6 -%FIXME: add references
    36.7 -%FIXME: where does the name come from: masqdialer (guessed)
    36.8 -
    36.9 -The date of the first release (version 0.0.1) is unknown.
   36.10 -The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999.
   36.11 -Further releases were made every few weeks or month during 2000, 2001 and 2002.
   36.12 -Development ended in mid-2003 in a hard stop.
   36.13 -The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
   36.14 -
   36.15 -During the time of development, Oliver released 53 versions.
   36.16 -That means a new release in less than every 20 days in average!
   36.17 -
   36.18 -Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
   36.19 -
   36.20 -One extra release (version 0.2.21) was made by him in November 2005.
   36.21 -This one is only available from the \debian\ pool.
   36.22 -Comparing it to version 0.2.20 shows, that no source code was altered.
   36.23 -Only building documents (like Makefiles) and \debian\ packageing documents were changed.
   36.24 -That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
   36.25 -
   36.26 -In May 2000 the minor version number increased to `1'.
   36.27 -Nothing special is mentioned in the documentation about that.
   36.28 -When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail.
   36.29 -At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series.
   36.30 -His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.

    37.1 --- a/thesis/pieces/masqmail-sendmail-replacement.tex	Thu Jan 15 12:16:43 2009 +0100
    37.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    37.3 @@ -1,14 +0,0 @@
    37.4 -Hence it must be secure enough. It either needs the security features or must drop the unsecure funtionality. The second option, however, leads to being \emph{no} replacement for other \MTA{}s. It is a valid decision to not be a replacement for \sendmail\ or thelike, but this is a design decision---the change of a primary goal.
    37.5 -
    37.6 -If \masqmail\ should be an \MTA\ to replace others, a switch to a better suited architecture that provides good security and extendability by design, seems required. But if \masqmail\ is wanted to cover some special jobs, not to replace common \MTA{}s, then its architecture depends on the special requirements of the specific job; \MTA\ architectures, like discussed by \person{Hafiz}, may be inadequate.
    37.7 -
    37.8 -What future is to choose for \masqmail---one to be a full featured \MTA, or one to be a stipped down \MTA\ for special jobs?
    37.9 -
   37.10 -The critical point to discuss upon is surely the listening on a port to accepte messages from outside via \NAME{SMTP} (herafter also refered to as the \NAME{SMTP}-in channel). This feature is required for an \MTA\ to be a \name{smart host}, to relay mail. But running as deamon and listening on a port requires much more security effort, because the program is put in direct contact with attackers and other bad guys.
   37.11 -
   37.12 -\MTA{}s without \SMTP-in channels can not receive mail from arbitrary outside hosts. They are only invoked by local users. This lowers the security need a lot---however, security is a general goal and still required, but on a lower level. Unfortunately, as they do not receive mail anymore (except by local submission), they are just better \name{forwarders} that are able to send mail directly to the destination.
   37.13 -
   37.14 -This is not what \masqmail\ was intended to be. Programs that cover this purpose are available; one is \name{msmtp}.
   37.15 -
   37.16 -\masqmail\ shall be a complete \mta. It shall be able to replace ones like \sendmail.
   37.17 -

    38.1 --- a/thesis/pieces/matrix-graphs.tex	Thu Jan 15 12:16:43 2009 +0100
    38.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    38.3 @@ -1,32 +0,0 @@
    38.4 -%		\begin{picture}(300,200)
    38.5 -%			\put(20,150){messages}
    38.6 -%			\put(100,110){\framebox(100,75){email, SMS}}
    38.7 -%			\put(200,110){\framebox(100,75){voicemail, video messages}}
    38.8 -%
    38.9 -%			\put(20,75){dialog}
   38.10 -%			\put(100,35){\framebox(100,75){IM, chat}}
   38.11 -%			\put(200,35){\framebox(100,75){VoIP, GSM/UMTS}}
   38.12 -%
   38.13 -%			\put(130,10){written}
   38.14 -%			\put(230,10){spoken}
   38.15 -%		\end{picture}
   38.16 -
   38.17 -%\begin{table}
   38.18 -%	\begin{tabular}[htb]{r||p{3cm}|p{3cm}|}
   38.19 -%		&&\\
   38.20 -%		& \textit{written} & \textit{spoken}\\[1ex]
   38.21 -%		\hline
   38.22 -%		\hline
   38.23 -%		\textit{messages (asynchron)} &
   38.24 -%		\parbox[t]{3cm}{\quad\\email\\SMS\\\quad} &
   38.25 -%		\parbox[t]{3cm}{\quad\\voicemail\\video messages\\\quad} \\
   38.26 -%		\hline
   38.27 -%		\textit{dialog (synchron)} &
   38.28 -%		\parbox[m]{3cm}{eIM\\chat} &
   38.29 -%		\parbox[m]{3cm}{eVoIP\\GSM/UMTS} \\
   38.30 -%		\hline
   38.31 -%	\end{tabular}
   38.32 -%	\caption{Classification of electronic communication}
   38.33 -%	\label{tab:comm-classification}
   38.34 -%\end{table}
   38.35 -

    39.1 --- a/thesis/pieces/mta-history-definition-sendmail.tex	Thu Jan 15 12:16:43 2009 +0100
    39.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    39.3 @@ -1,92 +0,0 @@
    39.4 -\subsection{History of electronic mail}
    39.5 -%FIXME: shorter!!!
    39.6 -
    39.7 -Electronic mail\index{electronic mail} (short: \name{email})\citeweb{wikipedia:email} is a basic concept in \unix.\citeweb{unix-mail-intro} On \unix\ machines, a lot of information is distributed by \name{system mail}, which is email sent by the operating system. Beside that, email is the common communication system between humans working on computers.
    39.8 -
    39.9 -The \unix\ operating system supports email through the \name{mail user agent} (short: \NAME{MUA}) \name{/bin/mail}.
   39.10 -
   39.11 -Development of \unix\ was not only made in the \name{Bell Labratories} of \NAME{AT\&T}. The \name{Univerity of California at Berkeley} worked on their version of a \unix\ operating system, too. It is refered to as \NAME{UCB} \unix, or \name{Berkeley} \unix\index{Berkeley Unix}.
   39.12 -
   39.13 -The few features of \name{/bin/mail} lead to a second \NAME{MUA} from Berkeley: \name{Mail} (with a capital `M'). Later, the superior functionality of \name{Mail} went back to \name{Bell Labs} and into the program \name{mailx}, the successor of \name{/bin/mail}.
   39.14 -
   39.15 -Nowadays, \name{mailx} and \name{Mail} are quite equivalent and \name{/bin/mail} is linked to either of them---whichever is installed.
   39.16 -
   39.17 -At that time, computers were connected by various kinds of networks. \name{Bell Labs} had invented the \NAME{UUCP} program and protocol suite (for ``\unix\ to \unix\ copy'')\citeweb{wikipedia:uucp}. Berkeley however had an own creation called \name{Berknet} in use. And the \name{United States Department of Defence Advanded Research Projects Agency}'s (\NAME{ARPA}) effort on designing a new wide area network, led to the \NAME{ARPANET}\citeweb{wikipedia:arpanet}, based on the \name{transmission control protocol} (\NAME{TCP}). There were also other, minor, kinds of networks in use.
   39.18 -
   39.19 -Email was transfered between different machines within the same networks. The file transfer itself was made uniformly using \NAME{FTP}, but the higher layered logic of the transfer was different. For example was addressing done different: \NAME{UUCP} used a flat-style schema, while \NAME{ARPANET}'s was hierachical.
   39.20 -
   39.21 -Mail transport from one machine connected to one kind of network to a second machine connected to another was a problem. This showed up at Berkeley where some departments of the university had switched to \NAME{ARPANET}, and some to \NAME{UUCP}, while the rest used \name{Berknet}.
   39.22 -
   39.23 -It was around 1982, when Eric Allman, then a student at Berkeley, wrote \name{delivermail}. Its purpose was to transform email from one network to another. \name{delivermail}, like its successor---the more flexible \sendmail---intermediated between the different networks. They were able to transform email messages from any network to any other.
   39.24 -
   39.25 -Todays email structure is basicly the same as then. The major difference is the uniformity of the underlying network, which is nearly always the \NAME{ARPANET}-based \name{Internet}. Hence lowering the importance of the transformation capabilities of \MTA{}s, that was essential to \sendmail's success---yet being the primary motivation for the program.
   39.26 -
   39.27 -More information about the history of electronic mail can be found at: \citeweb{email:griffiths}, \citeweb{email:crocker}, \citeweb{email:vleck}, \citeweb{email:akkad}, \citeweb{email:murakami}, and \citeweb{email:tomlinson}. A good starting point for general information on internet history is \citeweb{wikipedia:historyoftheinternet}.
   39.28 -%TODO: check the websites which ones are the important ones; remove unnessesary ones
   39.29 -
   39.30 -
   39.31 -
   39.32 -\subsection{Definition of \MTA}
   39.33 -%FIXME: better title; work text over!
   39.34 -%TODO: when was the term ``mail transfer agent'' established?
   39.35 -% shorter!
   39.36 -
   39.37 -This thesis is about a \name{mail transfer agent} (or \index{mail transport agent|see{mail transfer agent}}\name{mail transport agent}, short \NAME{MTA}): \masqmail. \sendmail\ is one too---the most important one.
   39.38 -
   39.39 -The basic job of a \mta\ is to transfer/transport electronic mail from one host to another.
   39.40 -
   39.41 -Here are definitions from others:
   39.42 -
   39.43 -\begin{quote}
   39.44 -A mail transfer agent (MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office.
   39.45 -\cite{costales97}
   39.46 -\end{quote}
   39.47 -
   39.48 -\begin{quote}
   39.49 -A mail transfer agent (MTA) (also called a mail transport agent, message transfer agent, or smtpd (short for SMTP daemon)), is a computer program or software agent that transfers electronic mail messages from one computer to another.
   39.50 -\citeweb{wikipedia:mta}
   39.51 -\end{quote}
   39.52 -
   39.53 -\begin{quote}
   39.54 -mail server (also known as a mail transfer agent or MTA, a mail transport agent, a mail router or an Internet mailer) is an application that receives incoming e-mail from local users (people within the same domain) and remote senders and forwards outgoing e-mail for delivery.
   39.55 -\citeweb{website:techtarget}
   39.56 -\end{quote}
   39.57 -
   39.58 -\begin{quote}
   39.59 -Message Transfer Agent - (MTA, Mail Transfer Agent): Any program responsible for delivering e-mail messages. Upon receiving a message from a Mail User Agent or another MTA, [...] it [...] delivers it to any local addressees and/or forwards it to other remote MTAs (routing) for delivery to remote recipients.
   39.60 -%Any program responsible for delivering e-mail messages. Upon receiving a message from a Mail User Agent or another MTA, often by SMTP over the Internet, it stores it temporarily locally and analyses the recipients and delivers it to any local addressees and/or forwards it to other remote MTAs (routing) for delivery to remote recipients. In either case it may edit and/or add to the message headers.
   39.61 -%
   39.62 -%The most widely used MTA for Unix is sendmail, which communicates using SMTP.
   39.63 -%
   39.64 -%RFC 2821 (SMTP) expands MTA as ``Mail Transfer Agent'' though this is less common. Alternatives with ``Transport'' are also seen but less correct.
   39.65 -\citeweb{website:thefreedictionary}
   39.66 -\end{quote}
   39.67 -
   39.68 -Common is the transfer of mail to other machines; this is the actual job. \MTA{}s work with mail, received from local users and/or remote machines. Mail delivery however is \emph{not} what \mta{}s are for, although probably every \MTA\ is able to deliver mail, and many do. \name{mail delivery agents} (short: \NAME{MDA}) are the programs for this job. Two of the best known \NAME{MDA}s are \name{procmail} and \name{maildrop}.
   39.69 -
   39.70 -
   39.71 -
   39.72 -\subsection{\name{sendmail-compatibility}}
   39.73 -\label{sec:sendmail}
   39.74 -%FIXME: rewrite!
   39.75 -% shorter!
   39.76 -
   39.77 -Allman wrote it to transfer emails between different networks, thus giving \sendmail\ mighty address rewriting abilities. In contrast to its predecessor \name{delivermail}, was \sendmail\ designed to offer greatest flexiblity in configuration; this enabled it to deal with any type of network.
   39.78 -
   39.79 -\sendmail\ was, and still is, very successful. So successful that it stands, like no other, for the whole group of \MTA{}s: \name{sendmail} actually is the \emph{de facto standard} for \mta{}s.
   39.80 -
   39.81 -Its author, Allman, sees three reasons for the huge success: the ``sloopy'' approach (accepting badly formed messages); its focus on the routing function; and the flexible configuration (this was important in \sendmail's early days).
   39.82 -\cite[page xviii]{costales97}
   39.83 -
   39.84 -Others see \sendmail's success more critical. One of them is quoted in the \name{MMDF} FAQs \citeweb{faqs:mmdf}:
   39.85 -\begin{quote}
   39.86 -Sendmail was once compared by one old Internet hand to ``those killer bees that escaped from the laboratory---and now they're everywhere and you can't get rid of 'em''.
   39.87 -\end{quote}
   39.88 -He definately hints here at \sendmail's many security vulnerabilities that came to light and on its complexity, in particular its obscure configuration file \path{sendmail.cf}.
   39.89 -
   39.90 -No matter how \sendmail\ is seen, one must admit its influence on \unix\ emailing programs. Most existing substitutes mimic \sendmail's interface and behavior. Most notable, they create a symbolic link named ``sendmail'' pointing to their own executable. The reason herefor are the many programs assuming an executable called ``sendmail'' on every computer system existing.
   39.91 -
   39.92 -\sendmail\ is not only ported to many platforms, even including \name{Microsoft Windows}, but also it is still the prefered \MTA\ on many systems.
   39.93 -
   39.94 -For deeper knowledge on \sendmail's history, see \cite{costales97} and \cite{vixie01}.
   39.95 -

    40.1 --- a/thesis/pieces/new-queue-permissions.txt	Thu Jan 15 12:16:43 2009 +0100
    40.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    40.3 @@ -1,56 +0,0 @@
    40.4 -\begin{tabular}[hbt]{ l l }
    40.5 -
    40.6 -\mbox{ queue-in:} & \mbox{
    40.7 -\begin{tabular}[hbt]{| c | c | c |}
    40.8 -	\hline
    40.9 - incoming & outgoing & pool \\
   40.10 -	\hline
   40.11 -	\hline
   40.12 - - & - & - \\
   40.13 -	\hline
   40.14 - 0600 & - & - \\
   40.15 -	\hline
   40.16 - 0600 & - & 0600 \\
   40.17 -	\hline
   40.18 - 0700 & - & 0600 \\
   40.19 -	\hline
   40.20 -\end{tabular}
   40.21 -} \\
   40.22 -
   40.23 -\quad & \\
   40.24 -
   40.25 -\mbox{scanning:} & \mbox{
   40.26 -\begin{tabular}[hbt]{| c | c | c |}
   40.27 -	\hline
   40.28 - incoming & outgoing & pool \\
   40.29 -	\hline
   40.30 -	\hline
   40.31 - 0700 & - & 0600 \\
   40.32 -	\hline
   40.33 - 0700 & 0600 & 0600 \\
   40.34 -	\hline
   40.35 - 0700 & 0700 & 0600 \\
   40.36 -	\hline
   40.37 - - & 0700 & 0600 \\
   40.38 -	\hline
   40.39 -\end{tabular}
   40.40 -} \\
   40.41 -
   40.42 -\quad & \\
   40.43 -
   40.44 -\mbox{queue-out:} & \mbox{
   40.45 -\begin{tabular}[hbt]{| c | c | c |}
   40.46 -	\hline
   40.47 - incoming & outgoing & pool \\
   40.48 -	\hline
   40.49 -	\hline
   40.50 - - & 0700 & 0600 \\
   40.51 -	\hline
   40.52 - - & 0700 & - \\
   40.53 -	\hline
   40.54 - - & - & - \\
   40.55 -	\hline
   40.56 -\end{tabular}
   40.57 -} \\
   40.58 -
   40.59 -\end{tabular}

    41.1 --- a/thesis/pieces/old/1-Candidates.tex	Thu Jan 15 12:16:43 2009 +0100
    41.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    41.3 @@ -1,133 +0,0 @@
    41.4 -\chapter{\unix\ \MTA{}s}
    41.5 -
    41.6 -After having read about the history of electronic mail and the basics of \mta{}s in the last chapter, this chapter introduces a group of \mta{}s. Among them, the already mentioned \sendmail. The selected group will be delimited against other groups of \MTA{}s, which are described as well.
    41.7 -
    41.8 -The chosen programs will be presented to the reader in a short overview and with the most important facts. The next chapter will show a comparison of these programs in several disciplines.
    41.9 -
   41.10 -
   41.11 -\section{Types of \MTA{}s}
   41.12 -``Mail transfer agent'' is a term covering a variety of programs. One thing is common to them: they transfer email from one \emph{thing} to another. These \emph{things} can be hosts, meaning independent machines, or protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transfered.\footnote{\sendmail{}'s initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.}
   41.13 -
   41.14 -Beside this common property, \MTA{}s can be very different. Some of them have \NAME{POP3} and/or \NAME{IMAP} servers included. Some can fetch mails through these protocols. Others have have all features you can think of. And maybe there are some that do nothing else but transporting email.
   41.15 -
   41.16 -Following are groups of \mta{}s that will \emph{not} be regarded further.
   41.17 -
   41.18 -\subsection{Relay-only \MTA{}s}
   41.19 -\label{subsec:relay-only}
   41.20 -This is the most simple kind of \MTA. It transfers mail only to defined \name{smart hosts}\footnote{\name{smart host}s are \MTA{}s that receives email and route it to the actual destination}. \name{Relay-only} \MTA{}s do not receive mail from outside the system, and they do not deliver locally.
   41.21 -
   41.22 -Most \MTA{}s can be configured to act as such a \name{forwarder}. But this is usually an additional functionality.
   41.23 -
   41.24 -One would use such a program to give a system the possibility to send mail, without the need to do lots of configuration. In a local network, usually the clients are set up with a \name{relay-only} \MTA, while there is one \name{mail server} that acts as a \name{smart host}. The ``dumb'' clients send mail to this one \name{mail server} which does all the work.
   41.25 -
   41.26 -Examples for that group are: \name{nullmailer}, \name{ssmtp} and \name{esmtp}.
   41.27 -
   41.28 -
   41.29 -\subsection{Groupware}
   41.30 -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 actual funktionality. Modules for mail transfer, file storage, calendars, resource management, instant messaging, etc., are commonly available.
   41.31 -
   41.32 -One would use one of these program suites if the main work to do is not mail transfer, but providing integrated communication facilities and team working support for a group of people. The most common scenario are companies. They have \name{groupware} running to provide adequate services for their teams to work efficently. But one may use \name{groupware} on the home server for his family members also.
   41.33 -
   41.34 -Examples are: \name{Lotus Notes}, \name{Microsoft Exchange}, \name{OpenGroupware.org} and \name{eGroupWare}.
   41.35 -
   41.36 -
   41.37 -\subsection{``Real'' \MTA{}s}
   41.38 -There is a third type of \mta{}s in between the minimalistic \name{relay-only} \MTA{}s and the bloated \name{groupware}. Those programs may be named ``real \MTA{}s'', or ``proper \MTA{}s'', though there is no common name. They are what is meant with the term ``\mta''.
   41.39 -
   41.40 -Common to them is their focus on transfering email, while being able to act as \name{smart host}. Their variety ranges from ones mostly restricted to mail transfer (\name{qmail}) to others already having interfaces for adding further mail processing modules (\name{postfix})---thus everything in between the other two groups.  %FIXME: are postfix and qmail good examples?
   41.41 -
   41.42 -This group is of importance in this document. The programs selected for the comparison are ``real \MTA{}s''.
   41.43 -
   41.44 -
   41.45 -
   41.46 -\section{Programs to sort out}
   41.47 -
   41.48 -\name{Mail transfer agent}s can be segmented in various ways, apart from the classification above. Groups of programs wiproperties significantly different from \masqmail\ will be sorted out now.
   41.49 -
   41.50 -\subsection{Non-\emph{sendmail-compatible} \MTA{}s}
   41.51 -Due to \sendmail's significance---described in section \ref{sec:sendmail}---compatiblity interfaces for \sendmail\ are of importance for \unix\ \MTA{}s. Being not \emph{sendmail-compatible} does not need to matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on \unix\ systems.
   41.52 -
   41.53 -Hence all \MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility addon, will not be covered here.
   41.54 -
   41.55 -An Examples here is \name{Apache James}.  %FIXME: check if correct
   41.56 -
   41.57 -
   41.58 -\subsection{Non-free software}
   41.59 -Only programs being \freesw\ are regarded, because comparing \freesw\ with proprietary or commercial software is not what typical users of programs like \masqmail\ do. Comparison with those non-free programs may be a point for large \freesw\ projects, trying to step into the business world. Small projects, mostly used by individuals at home, need to be compared against other projects of similar shape.
   41.60 -
   41.61 -The comparison should be seen from \masqmail's point of view, so non-free software is out of the way.
   41.62 -
   41.63 -
   41.64 -
   41.65 -\section{The programs regarded}
   41.66 -The programs remaining are \emph{sendmail-compatible} ``smart'' \MTA{}s that focus on mail transfer and are \freesw. One would not use a program for a job it is not suited for. Therefor only \mta{}s that are mostly similar to \masqmail\ are regarded.
   41.67 -
   41.68 -For the comparision, five programs are taken. These are: \sendmail, \name{qmail}, \name{postfix}, \name{exim}, and \masqmail. The four alternatives to \masqmail\ are the most important representatives of the regarded group. % FIXME: add ref that affirm that
   41.69 -
   41.70 -\name{courier-mta} is also a member of this group, being even closer to \name{groupware} than \name{postfix}. It is excluded here, because the \NAME{IMAP} and webmail parts of the mail server suite are more in focus than its \MTA. Common mail server setups even bundle \name{courier-imap} with \name{postfix}.
   41.71 -
   41.72 -Other members are: \name{smail}, \name{zmailer}, \name{mmdf}, and more; they all are less important and rarely used.
   41.73 -
   41.74 -Following is a small introduction to each of the five programs chosen for comparision.
   41.75 -
   41.76 -\subsection{\sendmail}
   41.77 -\label{sec:sendmail}
   41.78 -\sendmail\ is the most popular \mta. Since it was one of the first \MTA{}s and was shipped by many vendors of \unix\ systems.
   41.79 -
   41.80 -The program was written by Eric Allman as the successor of his program \name{delivermail}. \sendmail\ was first released with \NAME{BSD} 4.1c in 1983. Allman was not the only one working on the program. Other people developed own versions of it and a variety of flavors came up, especially in the late eighties when Allman was inactive.
   41.81 -
   41.82 -\sendmail\ is focused on transfering mails between different protocols and networks, this lead to a very flexible (though complex) configuration.
   41.83 -
   41.84 -The latest version is 8.14.3 from May 2008. The program is distributed under the \name{Sendmail License} as both, \freesw\ and proprietary software of \name{Sendmail, Inc.}.
   41.85 -
   41.86 -Further development will go into the project \name{MeTA1} which succeeds \sendmail.
   41.87 -
   41.88 -More information can be found on the \sendmail\ homepage \citeweb{sendmail:homepage} and on \citeweb{wikipedia:sendmail} and \citeweb{jdebp}.
   41.89 -
   41.90 -
   41.91 -\subsection{\name{qmail}}
   41.92 -\label{sec:qmail}
   41.93 -\name{qmail} is seen by its community as ``a modern SMTP server which makes sendmail obsolete''. It was written by Daniel~J.\ Bernstein starting in 1995. His primary goal was to create a secure \MTA\ to replace the popular, but vulnerable, \sendmail.
   41.94 -
   41.95 -\name{qmail} first introduced may innovative concepts in \mta\ design and is generally seen as the first security-aware \MTA\ developed.
   41.96 -
   41.97 -Since November 2007, \name{qmail} is released in the \name{public domain} which makes it \freesw. The latest release is 1.03 from July 1998.
   41.98 -
   41.99 -The programs homepages are \citeweb{qmail:homepage1} and \citeweb{qmail:homepage2}. Further information about \name{qmail} is available on \citeweb{lifewithqmail}, \citeweb{wikipedia:qmail} and \citeweb{jdebp}.
  41.100 -
  41.101 -
  41.102 -\subsection{\name{postfix}}
  41.103 -\label{sec:postfix}
  41.104 -The \name{postfix} project was started in 1999 at \name{IBM research}, then called \name{VMailer} or \name{IBM Secure Mailer}. Wietse Venema's program ``attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.''\citeweb{postfix:homepage} In fact, \name{postfix} was mainly designed after qmail's architecture to gain security. But in contrast to \name{qmail} it aims much more on being fast and full-featured.
  41.105 -
  41.106 -Today \name{postfix} is taken by many \unix systems and \gnulinux distributions as default \MTA.
  41.107 -
  41.108 -The latest stable version is numbered 2.5.5 from August 2008. \name{postfix} is covered by the \name{IBM Public License 1.0} which is a \freesw\ license.
  41.109 -
  41.110 -Additional information is available on the program's homepage \citeweb{postfix:homepage}, on \citeweb{jdebp} and \citeweb{wikipedia:postfix}.
  41.111 -
  41.112 -
  41.113 -\subsection{\name{exim}}
  41.114 -\label{sec:exim}
  41.115 -\name{exim} was started in 1995 by Philip Hazel at the \name{University of Cambridge}. Its age is about the same as \name{qmail}'s, but the architecture is totally different.
  41.116 -
  41.117 -While \name{qmail} took a completely new approach, \name{exim} forked of \name{smail-3}, and therefor is monolitic like that and like \sendmail. But having no separation of the individual components of the system, like \name{qmail} and \name{postfix} have, did not hurt. Its security is comparably good.
  41.118 -
  41.119 -\name{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. Also interfaces for integration of virus and spam check programs are provided by design.
  41.120 -
  41.121 -The program is \freesw, released under the \GPL. The latest stable version is 4.69 from December 2007.
  41.122 -
  41.123 -One finds \name{exim} on its homepage \citeweb{exim:homepage}. More information about it can be retrieved from \citeweb{wikipedia:exim} and \citeweb{jdebp}.
  41.124 -
  41.125 -
  41.126 -\subsection{\masqmail}
  41.127 -\label{sec:masqmail}
  41.128 -The \masqmail\ program was written by Oliver Kurth, starting in 1999. His aim was to create a small \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ is easy configurable for situations which are rarely solveable with the common \MTA{}s.
  41.129 -
  41.130 -\masqmail\ queues mail for destinations outside the local network if no connection to the internet is online. If the machine goes online, this mail is sent. Mail to local machines is sent immediately.
  41.131 -
  41.132 -While the other \MTA{}s are more general purpose \MTA{}s, \masqmail\ aims on special situations only. Nevertheless can it handle ordinary mail transfers too.
  41.133 -
  41.134 -\masqmail\ is released under the \GPL, which makes it \freesw. The latest stable version is 0.2.21 from November 2005.
  41.135 -
  41.136 -The program's new homepage \citeweb{masqmail:homepage} provides further information about this \MTA.

    42.1 --- a/thesis/pieces/old/1-Comparision.tex	Thu Jan 15 12:16:43 2009 +0100
    42.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    42.3 @@ -1,100 +0,0 @@
    42.4 -\chapter{Comparison of \MTA{}s}
    42.5 -
    42.6 -% http://shearer.org/MTA_Comparison
    42.7 -% http://www.geocities.com/mailsoftware42/
    42.8 -% http://fanf.livejournal.com/50917.html
    42.9 -% http://archives.neohapsis.com/archives/postfix/2006-07/1762.html
   42.10 -% http://www.oreillynet.com/lpt/a/6849
   42.11 -% http://www.mailradar.com/mailstat/
   42.12 -
   42.13 -\section{First release}
   42.14 -sendmail: 1983
   42.15 -
   42.16 -postfix: 1999
   42.17 -
   42.18 -qmail: 1996 (first beta 0.70), 1997 (first general 1.0)
   42.19 -
   42.20 -exim: 1995
   42.21 -
   42.22 -masqmail: 1999
   42.23 -
   42.24 -exchange: 1993
   42.25 -
   42.26 -
   42.27 -\section{Lines of code (with sloccount on debian packages)}
   42.28 -sendmail: 93k
   42.29 -
   42.30 -postfix: 92k
   42.31 -
   42.32 -qmail: 18k
   42.33 -
   42.34 -exim: 54k
   42.35 -
   42.36 -masqmail: 14k
   42.37 -
   42.38 -exchange: (no source available)
   42.39 -
   42.40 -
   42.41 -\section{Architecture}
   42.42 -sendmail: monolitic
   42.43 -
   42.44 -postfix: modular
   42.45 -
   42.46 -qmail: modular
   42.47 -
   42.48 -exim: monolitic
   42.49 -
   42.50 -masqmail: monolitic
   42.51 -
   42.52 -exchange: (unknown)
   42.53 -
   42.54 -
   42.55 -\section{Design goals}
   42.56 -sendmail: flexibility
   42.57 -
   42.58 -postfix: performance and security
   42.59 -
   42.60 -qmail: security
   42.61 -
   42.62 -exim: general, flexible \& extensive facilities for checking
   42.63 -
   42.64 -masqmail: for non-permanent internet connection
   42.65 -
   42.66 -exchange: groupware
   42.67 -
   42.68 -
   42.69 -\section{Market share (by Bernstein in 2001)}
   42.70 -sendmail: 42\%
   42.71 -
   42.72 -postfix: 1.6\%
   42.73 -
   42.74 -qmail: 17\%
   42.75 -
   42.76 -exim: 1.6\%
   42.77 -
   42.78 -masqmail: (unknown)
   42.79 -
   42.80 -exchange: 18\%
   42.81 -
   42.82 -
   42.83 -
   42.84 -
   42.85 -1) complexity
   42.86 -
   42.87 -2) security
   42.88 -
   42.89 -3) simplicity of configuration and administration
   42.90 -
   42.91 -4) flexibility of configuration and administration
   42.92 -
   42.93 -5) code size
   42.94 -
   42.95 -6) code quality
   42.96 -
   42.97 -7) documentation (amount and quality)
   42.98 -
   42.99 -8) community (amount and quality)
  42.100 -
  42.101 -9) used it myself
  42.102 -
  42.103 -10) had problems with it

    43.1 --- a/thesis/pieces/old/1-Masqmail.tex	Thu Jan 15 12:16:43 2009 +0100
    43.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    43.3 @@ -1,107 +0,0 @@
    43.4 -\chapter{\masqmail}
    43.5 -
    43.6 -%TODO: have text by oliver here?
    43.7 -
    43.8 -
    43.9 -\section{Target field}
   43.10 -Its original author, Oliver Kurth, sees \masqmail\ so:
   43.11 -\begin{quote}
   43.12 -MasqMail is a mail server designed for hosts that do not have a permanent internet connection eg. a home network or a single host at home. It has special support for connections to different ISPs. It replaces sendmail or other MTAs such as qmail or exim.
   43.13 -\end{quote}
   43.14 -
   43.15 -\masqmail\ is inteded to cover a specific niche: non-permanent internet connection and different \NAME{ISP}s.
   43.16 -
   43.17 -Although it can basically replace other \MTA{}s, it is not generally aimed to do so. The package description of \debian\citeweb{packages.debian:masqmail} states this more clearly by changing the last sentence to:
   43.18 -\begin{quote}
   43.19 -In these cases, MasqMail is a slim replacement for full-blown MTAs such as sendmail, exim, qmail or postfix.
   43.20 -\end{quote}
   43.21 -\masqmail\ is a good replacement ``in these cases'', but not generally, since is lacks features essential for running on mail servers. It is primarily not secure enough for being accessable from untrusted locations.
   43.22 -
   43.23 -The program is best used in home networks, which are non-permanently connected to the internet. \masqmail\ sends mail to local destinations, like users on the same machine and on other machines in the local net, immediately. Email to recipients outside the local net are queued when offline and sent when a online connection gets established.
   43.24 -
   43.25 -Further more does \masqmail\ respect online connections through different \NAME{ISP}s; a common thing for dial-up connections. In particular can different sender addresses be set, dependent on the \NAME{ISP} that is used. This prevents mail to be likely classified as spam.
   43.26 -
   43.27 -
   43.28 -
   43.29 -\section{Typical usage}
   43.30 -This section describes situations that make senseful use of \masqmail.
   43.31 -
   43.32 -A home network consisting of some workstations without a server. The network is connected to the internet by dial-up or broadband. Going online is initiated by computers inside the local net. \NAME{IP} addresses change at least once every day.
   43.33 -
   43.34 -Every workstation would be equiped with \masqmail. Mail transfer within the same machine or within the local net works straight forward. Outgoing mail to the internet is sent, to the concerning \NAME{ISP} for relaying, whenever the router goes online. Receiving of mail from outside needs to be done by a mail fetch program, like the \masqmail\ internal \NAME{POP3} client or \name{fetchmail} for example. The configuration for \masqmail\ would be the same on every computer, except the hostname.
   43.35 -
   43.36 -For the same network but having a server, one could have \masqmail\ running on the server and using simple forwarders (see \ref{subsec:relay-only}) to the server on the workstations. This setup does only support mail transfer to the server, but not back to a workstation; also sending mail to another user on the same workstation is not possible.
   43.37 -
   43.38 -A better setup is to run \masqmail\ on every machine %FIXME
   43.39 -
   43.40 -
   43.41 -
   43.42 -\section{What makes it special}
   43.43 -
   43.44 -As main advantage, \masqmail\ makes it easy to set up an \MTA\ on workstations or notebooks without the need to do complex configuration or to be an mail server expert.
   43.45 -
   43.46 -Workstations use %FIXME
   43.47 -
   43.48 -
   43.49 -\section{Alternatives?}
   43.50 -% http://anfi.homeunix.org/sendmail/dialup10.html
   43.51 -
   43.52 -
   43.53 -\section{Structure}
   43.54 -Like its anchestor \sendmail, \masqmail\ is a monolitic program. It consists of only one \emph{setuid root}\footnote{Runs as user root, no matter which user invoked it.}\index{setuid root} binary file, named \path{masqmail}. All functionality is included in it; of course some more comes from dynamic libraries linked.
   43.55 -
   43.56 -The \masqmail\ executable can be called under various names for \name{sendmail-compatibility} reasons. This is commonly organized by creating symbolic links with with different names to the \masqmail\ executable. These are \path{/usr/lib/sendmail} and \path{/usr/sbin/sendmail} because many programs expect a \mta\ to be located there. Further more \sendmail\ provides shortcuts by calling it with a different name instead of supplying command line arguments. The best known of it is \path{mailq}, which is equivilent to calling the \MTA\ with the argument \verb+-bq+. \masqmail\ reacts to the names \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The last four are an addition to \sendmail. Not implemented is the name \path{newaliases} because it is not relevant to \masqmail. To provide the command nonetheless, one may write a shell script located at \path{/usr/bin/newaliases}, that simply invokes \verb+masqmail -bi+.
   43.57 -
   43.58 -%masqmail: mailq, mailrm, runq, rmail, smtpd/in.smtpd
   43.59 -%sendmail: hoststat, mailq, newaliases, purgestat, smtpd
   43.60 -
   43.61 -\masqmail\ is written in the \NAME{C} programming language. The program, as of version 0.2.21, consists of 34 source code and eight header files, containing about 9,000 lines of code\footnote{Measured with \name{sloccount} by David A.\ Wheeler.}. Additionally, it includes a \name{base64} implementation (about 300 lines) and \name{md5} code (about 150 lines). For systems that do not provide \name{libident}, this library is distributed as well (circa 600 lines); an available shared library however has higher precedence in linking.
   43.62 -
   43.63 -The only mandatory dependency is \name{glib}---a cross-platform software utility library, originated in the \NAME{GTK+} project. It provides safer replacements for many standard library functions. (The unsafe \verb+sprintf()+ is one example.) Also it offers handy data containers, easy-to-use implementations of data structures, and much more.
   43.64 -
   43.65 -With \masqmail\ comes the small tool \path{mservdetect}; it helps setting up a configuration that uses the \name{mserver} system to detect the online state. Two other binaries get compiled for testing purposes: \path{readtest} and \path{smtpsend}. All three programms use \masqmail\ source code; they only add a file with a \verb+main()+ function each.
   43.66 -
   43.67 -\masqmail\ does not provide an interface for modules with additional functionality. There exists no add-on or module system. But the code is separated by function to the various source files, and some functional parts can be included or excluded by defining symbols. This means adding some argument (like \verb+--enable-maildir+) to the \verb+configure+ call. Thus the concerning code gets not removed by the preprocessor.
   43.68 -
   43.69 -
   43.70 -\section{Features}
   43.71 -This overview regards \masqmail version 0.2.21, the state this document starts off.
   43.72 -
   43.73 -First of all \masqmail\ is an \MTA. Therefor it accepts mail on the command line and via \SMTP. Mail queueing and alias expansion is supported. \masqmail\ is able to deliver mail to local mailboxes (in \name{mbox} or \name{maildir} format) or pass it to a \name{mail delivery agent} (like \name{procmail}). Mail destinated to remote locations is sent via \SMTP. Outgoing \SMTP\ connections feature \name{SMTP-Auth} and \name{SMTP-after-POP} authentication, but incoming \SMTP\ does not.
   43.74 -
   43.75 -As \masqmail\ is focused on non-permanent Internet connections, online state can be queried by three methods: reading from a file, reading the output of a command, or by asking an \name{mserver}. Each method may return a string indicating one of the available routes being online, or returning nothing to indicate offline state.
   43.76 -
   43.77 -Delivery to recipients on the local host or in local nets is done at once; delivery to recipients on the Internet is only done when being online, and queued otherwise. Each online route may have a different mail server to which mail is relayed. Return address headers are modified appropriate if wished.
   43.78 -
   43.79 -Additional to the \mta\ job, \masqmail\ also offers mail retrieval services with being a \NAME{POP3} client. Thus it can fetch mail from remote locations, dependent on the active online route.
   43.80 -
   43.81 -
   43.82 -
   43.83 -\section{History}
   43.84 -%TODO: let oliver prove read it!
   43.85 -%FIXME: add references
   43.86 -%FIXME: where does the name come from: masqdialer (guessed)
   43.87 -
   43.88 -The date of the first release (version 0.0.1) is unknown.
   43.89 -The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999.
   43.90 -Further releases were made every few weeks or month during 2000, 2001 and 2002.
   43.91 -Development ended in mid-2003 in a hard stop.
   43.92 -The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
   43.93 -
   43.94 -During the time of development, Oliver released 53 versions.
   43.95 -That means a new release in less than every 20 days in average!
   43.96 -
   43.97 -Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
   43.98 -
   43.99 -One extra release (version 0.2.21) was made by him in November 2005.
  43.100 -This one is only available from the \debian\ pool.
  43.101 -Comparing it to version 0.2.20 shows, that no source code was altered.
  43.102 -Only building documents (like Makefiles) and \debian\ packageing documents were changed.
  43.103 -That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
  43.104 -
  43.105 -In May 2000 the minor version number increased to `1'.
  43.106 -Nothing special is mentioned in the documentation about that.
  43.107 -When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail.
  43.108 -At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series.
  43.109 -His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.
  43.110 -

    44.1 --- a/thesis/pieces/old/2-FutureOfCommunication.tex	Thu Jan 15 12:16:43 2009 +0100
    44.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    44.3 @@ -1,120 +0,0 @@
    44.4 -\chapter{The future of communication}
    44.5 -\label{chap:future-of-communication}
    44.6 -As globalization proceeds, long distance communication becomes more and more important. This chapter tries to locate trends in communication methods and their impact on the future for communication. The insights gathered from the analysis will be applied to \masqmail, afterwards.
    44.7 -
    44.8 -
    44.9 -\section{Communication methods}
   44.10 -\label{sec:communication-methods}
   44.11 -Today's long distance communication methods are either written or spoken information. And on the other side, they can be classified by the time between responses.
   44.12 -
   44.13 -A classification of long distance communication methods is shown in figure %\ref{fig:}.
   44.14 -% slow     |              |             |
   44.15 -%          |              | letter      | days
   44.16 -%          |              |             |
   44.17 -%          |              |             |
   44.18 -%          | answering    | email       |
   44.19 -%          |   machine    | telefax     | few seconds
   44.20 -%          |              | SMS         |
   44.21 -% fast     |              |             |
   44.22 -%          | telephone    | IM          | real time
   44.23 -% -----------------------------------------------------
   44.24 -% response | spoken       | written     | delivery time
   44.25 -
   44.26 -% TODO: find reference literature
   44.27 -
   44.28 -\subsection{Speed}
   44.29 -Communication gets faster in general. Slow mediums as letters get substituted by electronic mail, which is delivered within seconds. Also communication becomes more transmitted through digital channels. This can be seen at the telephone which's information is now more and more transported in bits over the internet link. Also telefaxes are succeeded by email or are transported within email. Instant messaging can be seen as the written couterpart to the telephone; not to substitute it completely, but to be used if it is more useful for the information to transmit.
   44.30 -
   44.31 -Many of the digital communication methods gained success by beeing cheaper than their counterparts. One example here is instant messaging in contrast to the telephone. As phoning costs fell, it became more popular again. The last years showed, that communication cost degreased dropped generally, caused by the transport through digital channels. And nothing to see, that would make them rise again.
   44.32 -
   44.33 -It seems as if in future will be low-cost communication methods available, which will be digitally transmitted.
   44.34 -
   44.35 -\subsection{Variety}
   44.36 -Regarding the variety of communication methods shows a change, too. Communication systems are more easy to establish today, so more get established. This leads to more methods a person uses. But not only in the amount, also in parallel. For example when two people talk to each other on the phone, one might send a URI\footnote{Uniform Resource Identifier} by email meanwhile, because oral communication is not well suited to exchange such data. Another example for in parallel used communication channels is video chatting. Ony typically sees the other person, talks to it, and additionally has a instant messaging facility for exchanging written information.
   44.37 -
   44.38 -Parallel usage of different kinds of communication channels will be important in future. The most common combinations are one for spoken and one for written information. But one for dialogs and one for sending documents will be important too.
   44.39 -
   44.40 -\subsection{Hardware}
   44.41 -Next about the hardware needed for communicating. On the one side stands the telephone, now available as the mobile phone. It provides spoken dialog by calling, spoken messages with the included answering machine and written messages in form of short message service. On the other side stands the letter and its relatives. They need pen and paper, a telefax machine or in most today's cases a computer. They typically send documents, only instant messaging is focused on dialog.
   44.42 -
   44.43 -The last years finally brought the two groups together, with \name{smart phones} being the merging element. Smart phones are computers in the size of mobile phones. They provide both functions, using it as telephones and as computers.
   44.44 -
   44.45 -It matches well the requirements of telephoning and short message service, for which it was designed of course. Also providing being suitable for instant messaging in what is needed additionally to the telephone and short message service. The only problem is the minimal keyboard available to insert text. This also affects writing documents in case of email. It can be done but not very comfortably. Further communication methods include voice and video messages.
   44.46 -
   44.47 -This leaves us with the need for ordinary computers for the field of exchanging documents, and as better input hardware for all written input.
   44.48 -
   44.49 -
   44.50 -
   44.51 -\section{Trends for electronic mail}
   44.52 -\label{sec:email-trends}
   44.53 -The previous section stated that electronic mail will still be important in future to complete the communication methods provided by phone and instant messaging.
   44.54 -
   44.55 -But will emailing in future not be the same as emailing now. This will mainly affect how email is transfered.
   44.56 -
   44.57 -\subsection{Provider oriented emailing}
   44.58 -Today's email structure is heavily dependent on email providers. This means, most people have email addresses from some provider. These can be the provider of their online connection (e.g.\ \NAME{AOL}, \name{T\~Online}), freemail provider (e.g.\ \NAME{GMX}, \name{Yahoo}, \name{Hotmail}) or provider that offer enhanced mail services that one needs to pay for. Outgoing mail is send either with the webmail client of the provider or using \name{mail user agent}s sending it to the provider for relay. Incoming mail is read with the webmail client or retrieved from the provider via \NAME{POP3} or \NAME{IMAP} to the local computer to be read in the \name{mail user agent}. This means all mail sending and receiving work is done by the provider.
   44.59 -
   44.60 -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.
   44.61 -
   44.62 -\subsection{Provider independence}
   44.63 -Nowadays, dial-up internet access is rare; the majority has broadband internet access paying a flat rate for it. So being online or not does not affect costs anymore, even traffic is unlimited. Today it is possible to have an own mail server running at home. The last technical problem remaining are the changing \NAME{IP} addresses one gets assigned every 24 hours. But this is easily solvable with one of the dynamic \NAME{DNS} services around; they provide the mapping of a fixed domain name to the changing \NAME{IP} addresses.
   44.64 -
   44.65 -Home servers become popular in these days, for central data storage and multi media services. Being assembled of energy efficient elements, power consumption is no big problem anymore. These home servers will replace video recorders and 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 is a logical step to have email and other communication will be provided by the (or one of) the own server aswell.
   44.66 -
   44.67 -After \mta{}s have not been popular for users in the last time, the next years might bring them back to them. Maybe in a few years nearly everyone will have one running at home \dots\ possibly without knowing about it.
   44.68 -
   44.69 -\subsection{Is email future-safe?}
   44.70 -It seems as if electronic mail or a similar technology has good chances to survive the next decades. This bases on the assumption that it always will be important to send information messages. These can be notes from other people, or notifications from systems (like a broken or full hard drive in the home server, or the coffee machine ran out of coffee beans). Other communication technologies are not as suitable for this kind of messages, as email, short message service, voice mail, and the like. Telephone talks are more focused on dialog and normally interrupt people. These kind of messages should not interrupt people, unless urgent, and they do not need two-way information exchange. The second argument appies to instant messaging too. If only one message is to be send, one does not need instant messaging. Thus, one type of one-way message sending technology will survive.
   44.71 -
   44.72 -Whether email will be the one surviving, or short message service, or another one, does not matter. Probably it will be \name{unified messaging}, which includes all of the other ones in it, anyway. \MTA{}s are a kind of software needed for all of these messaging methods---programs that transfer and receive messages.
   44.73 -
   44.74 -\subsection{Pushing versus polling}
   44.75 -The retrieval of email is a field that is about to change now. The old way is to fetch email by polling the server that holds the personal mail box. This polling is done in regular intervals, often once every five to thirty minutes. The mail transfer from the mail box to the \name{mail user agent} is initiated from the mail client side. The disadvantage herewith is the delay between mail actually arriving on the server and the user finally having the message on his screen.
   44.76 -
   44.77 -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 the smart phones; they were able to do emailing, but the traffic caused by polling the server often was expensive. The concept workes well with mobile phones where the provider knows about the client, but it seems not to be a choice for computers since the provider needs to have some kind of login to push data to the computer.
   44.78 -
   44.79 -The push concept, however could swap over to computers when using a home server and no external provider. A possible scenario is a home server receiving mail from the internet and pushing it to computers and smart phones. The configuration could be done by the user through some simple interface, like one configures his telephone system to have different telephone numbers ring on specified phones.
   44.80 -%FIXME: add reference to push email
   44.81 -
   44.82 -\subsection{Internet Mail 2000}
   44.83 -Another concept to redesign the electronic mail system, but this time focused on mail transfer is named ``Internet Mail 2000''. It was proposed by Daniel J.\ Bernstein, the creater of \name{qmail}. Similar approaches were independently introduced by others too.
   44.84 -
   44.85 -As main change it makes the sender have the responsibility of mail storage; only a notification about a mail message gets send to the receiver, who can 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 transfered from the sender to the receiver.
   44.86 -
   44.87 -\name{Mail transfer agent}s are still important in this mail architecture, but in a slightly different way. Their job is not transfering mail anymore---this makes the name missleading---they are used to transport the notifications about new mail to the destinations. This is a quite similar job as they do in the \NAME{SMTP} model. The real transfer of the mail can be done in any way, for example via \NAME{FTP} or \NAME{SCP}.
   44.88 -
   44.89 -%FIXME: add references for IM2000
   44.90 -
   44.91 -
   44.92 -
   44.93 -\section{\NAME{SWOT} analysis}
   44.94 -%TODO
   44.95 -
   44.96 -
   44.97 -
   44.98 -\section{What will be important}
   44.99 -\label{sec:important-for-mtas}
  44.100 -Now that it is explained why email will survive (in some changed but related form), it is time to think about the properties required for \mta{}s in the next years. As the fields and kinds of usage change, the requirement change too.
  44.101 -
  44.102 -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 one's home to set up the systems; like it is already common for problems with the power supply or water supply system. 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 itself 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 on a simple configuration interface like a web interface; non-technical educated users should be able to configure the system.
  44.103 -
  44.104 -\sendmail\ and \name{qmail} appear to have bad positions at this point. Their configuration is complex, thus they would need simplification wrappers around them to provide easy configuration.
  44.105 -
  44.106 -The approach of wrappers around the main program to make it look easier to the outside is a good concept in general. %FIXME: add ref
  44.107 -It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ a graphical program, a website, a command line program; all of them either in a questionaire style or iteractive).
  44.108 -
  44.109 -When \MTA{}s become popular on home servers and maybe even on workstations and smart phones, then performance will be less important. Providers need \mta{}s that process a large amount of mail in short time. Home servers or workstations however, do not see that much mail; they need to handle tens or hundrets of email messages per hour. Thus performance will probably not be a main requirement for an \MTA\ in the future, if they mainly run on private machines.
  44.110 -
  44.111 -\name{postfix} focuses much on performance, this might not be an important point then.
  44.112 -
  44.113 -New mailing concepts and architectures like push email or \name{Internet Mail 2000} will, if they succeed, require \mta{}s to adopt the new technology. \MTA{}s that are not able to change are going to be sorted out by evolution. Thus it is important to not focus too much on one use case, but to stay flexible. Allman saw this property of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}).
  44.114 -
  44.115 -Another important requirement for all kinds of software will be security. There is a constant trend going from completely non-secured software from the 70s and 80s over growing security awareness in the 90s to security being a primary goal now. This leads to the conclusion that software security will even more important in the next years. As more clients get connected to the internet and especially more computers are waiting for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing software systems will be done with increasing effort in future.
  44.116 -
  44.117 -``Plug-and-play''-able hardware with preconfigured software running can be expected to become popular. Like someone buys a set-top box to watch Pay-TV today, he might be buying a box acting as mail server in a few years. He plugs the power cable in, inserts his email address in a web interface and selects the clients (workstation computers or smart phones) to which mail should be send and from which mail is accepted to receive. That's all. It would just work then, like everyone expects it from a set-top box today.
  44.118 -
  44.119 -Containing secure and robust software is a pre-requisite for such boxes to make that vision possible.
  44.120 -
  44.121 -It seems as if all widely used \mta{}s provide good security nowadays. \name{qmail}'s architecture, also used in \name{postfix}, is generally seen to be conceptually more secure, however.
  44.122 -
  44.123 -In summary: easy configuration, aswell as the somehow opposed flexibility will be important for future \mta{}s. Also will it be security, but not performance. \MTA{}s might become more commodity software, like web servers already are today, with the purpose to include it in many systems and the need of minimal configuration.

    45.1 --- a/thesis/pieces/old/2-FuturesForMasqmail.tex	Thu Jan 15 12:16:43 2009 +0100
    45.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    45.3 @@ -1,18 +0,0 @@
    45.4 -\chapter{Futures for \masqmail}
    45.5 -
    45.6 -\section{\masqmail\ in five years}
    45.7 -\label{sec:masqmail-in-5-years}
    45.8 -Now how could \masqmail\ be like in, say, five years?
    45.9 -%requirements
   45.10 -%which parts to do
   45.11 -%how to make masqmail future-safe
   45.12 -
   45.13 -%how to advertise masqmail
   45.14 -%difference for free software
   45.15 -%why is it worth to revive masqmail?
   45.16 -
   45.17 -
   45.18 -\section{A design from scratch}
   45.19 -%what would be needed
   45.20 -%would one create it at all?
   45.21 -

    46.1 --- a/thesis/pieces/old/3-BecomingProjectLeader.tex	Thu Jan 15 12:16:43 2009 +0100
    46.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    46.3 @@ -1,4 +0,0 @@
    46.4 -\chapter{Becoming project leader}
    46.5 -\section{History of \masqmail}
    46.6 -\section{Taking it}
    46.7 -

    47.1 --- a/thesis/pieces/old/3-FreeSoftwareProjects.tex	Thu Jan 15 12:16:43 2009 +0100
    47.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    47.3 @@ -1,127 +0,0 @@
    47.4 -\chapter{About \freesw\ projects}
    47.5 -
    47.6 -% http://www.faqs.org/docs/artu/
    47.7 -
    47.8 -There are several differences between \freesw\ projects and projects about proprietary software.
    47.9 -To understand \freesw\ projects, one needs to understand \freesw\ itself first.
   47.10 -
   47.11 -\section{About \freesw}
   47.12 -The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
   47.13 -Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
   47.14 -One could say, the \GPL\ catalized the \name{Free Software movement}.
   47.15 -
   47.16 -% http://www.fsf.org/about/what-is-free-software
   47.17 -
   47.18 -After all, the \GPL\ was not the first \freesw\ license used.
   47.19 -The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
   47.20 -Licenses providing the same rights have been used since long time ago.
   47.21 -But none of them was so often (re)used by other projects---thus gattering less awareness.
   47.22 -Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
   47.23 -
   47.24 -\freesw\ gives freedoms to its users.
   47.25 -In contrast to proprietary software restricting the users freedom.
   47.26 -The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
   47.27 -% http://www.gnu.org/philosophy/free-sw.html
   47.28 -% http://www.fsf.org/licensing/essays/free-sw.html
   47.29 -\begin{enumerate}
   47.30 -	\item The freedom to run the program, for any purpose (freedom 0).
   47.31 -	\item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
   47.32 -	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
   47.33 -	\item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
   47.34 -\end{enumerate}
   47.35 -
   47.36 -
   47.37 -\section{The term ``Open Source''}
   47.38 -\name{Open Source Software} often stands for the same as \freesw.
   47.39 -But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
   47.40 -
   47.41 -\name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
   47.42 -
   47.43 -% http://www.gnu.org/philosophy/open-source-misses-the-point.html
   47.44 -% http://catb.org/~esr/open-source.html
   47.45 -
   47.46 -
   47.47 -\section{Development of \freesw}
   47.48 -Having source code available and the right to modify it, encouridges programmers to actually do so.
   47.49 -Their modifications are manifoldly.
   47.50 -Some tailor the software to their needs.
   47.51 -Some add features.
   47.52 -Some do it just for fun.
   47.53 -There are no limitations---whoever wants to, may work on it.
   47.54 -
   47.55 -Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
   47.56 -The process of development is watchable by everyone.
   47.57 -
   47.58 -The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
   47.59 -
   47.60 -Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
   47.61 -
   47.62 -The following text will focus on the ``bazaar'' model.
   47.63 -
   47.64 -
   47.65 -\section{The role of the community}
   47.66 -\freesw\ projects rise and fall with their community!
   47.67 -
   47.68 -Most \freesw\ programs are developed by a very small group of programmers, often only one person.
   47.69 -But they are used by many people.
   47.70 -In between the programmers and the users, are people located who are a bit of both.
   47.71 -These are the ones that write documentation, find bugs and probably even fix it.
   47.72 -They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
   47.73 -The program is often spread by their ``advertising''.
   47.74 -
   47.75 -The \emph{community} consists of the actual developers and all users that contribute to the program.
   47.76 -Contribution can be one of the described ways, or others like providing a server for the project website for example.
   47.77 -
   47.78 -\emph{Community} is everyone who is in contact through the project.
   47.79 -Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
   47.80 -
   47.81 -There will hardly be a community if no communication channels are available.
   47.82 -If the development team does not provide them, there is a chance that encouraged users set them up on their own.
   47.83 -But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
   47.84 -
   47.85 -Projects without a good community tend to die sooner or later.
   47.86 -
   47.87 -
   47.88 -\section{Evolution of a community}
   47.89 -Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
   47.90 -He starts developing.
   47.91 -When others get in contact with the project, there may be some who are so much interested that they start co-developing.
   47.92 -Others report bugs, and some only use the program.
   47.93 -
   47.94 -After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
   47.95 -The size ratio of the groups vary by type of project.
   47.96 -
   47.97 -One should have that in mind, when starting a \freesw\ project.
   47.98 -
   47.99 -
  47.100 -\section{Creating a strong community}
  47.101 -Building up a good community needs some effort of the main developers.
  47.102 -%TODO: search for documents about this topic
  47.103 -
  47.104 -First communication channels need to be set up, to enable the growth of a community.
  47.105 -
  47.106 -Second, development should be visible by everyone who is interested in it.
  47.107 -Time between work done on the project and its visibility to the public should be kept short.
  47.108 -This makes it interesting for other developers to join.
  47.109 -Developers are the core of a community.
  47.110 -
  47.111 -Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
  47.112 -Releases are (more) stable versions, primary for users.
  47.113 -They should be created, frequently.
  47.114 -People will more likely use programs of active projects.
  47.115 -
  47.116 -Fourth, the developers should try to get the users ``in the boat''.
  47.117 -Good communities have a large group of users that do not only receive, but also give something back to the project.
  47.118 -The project leaders should motivate users to contribute.
  47.119 -This unlocks a big work force and gets lot of unexiting work done.
  47.120 -
  47.121 -Fifth, documentation matters.
  47.122 -Good documentation makes it easy for users and developers to start.
  47.123 -And it helps to avoid a lot of unsatisfaction.
  47.124 -Documentation is something that shows quality and that people care about the project.
  47.125 -
  47.126 -And sixth, project leaders should be good souvereigns.
  47.127 -They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
  47.128 -
  47.129 -Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
  47.130 -Volunteer work lives by acknowledgement of the effort spent.

    48.1 --- a/thesis/pieces/old/3-MasqmailProject.tex	Thu Jan 15 12:16:43 2009 +0100
    48.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    48.3 @@ -1,218 +0,0 @@
    48.4 -\chapter{The \masqmail\ project}
    48.5 -
    48.6 -%TODO: have text by oliver here?
    48.7 -
    48.8 -\section{Purpose of \masqmail}
    48.9 -
   48.10 -\subsection{Target field}
   48.11 -Its original author, Oliver Kurth, sees \masqmail\ so:
   48.12 -\begin{quote}
   48.13 -MasqMail is a mail server designed for hosts that do not have a permanent internet connection eg. a home network or a single host at home. It has special support for connections to different ISPs. It replaces sendmail or other MTAs such as qmail or exim.
   48.14 -\end{quote}
   48.15 -
   48.16 -\masqmail\ is inteded to cover a specific niche: non-permanent internet connection and different \NAME{ISP}s.
   48.17 -
   48.18 -Although it can basically replace other \MTA{}s, it is not generally aimed to do so. The package description of \debian\citeweb{packages.debian:masqmail} states this more clearly by changing the last sentence to:
   48.19 -\begin{quote}
   48.20 -In these cases, MasqMail is a slim replacement for full-blown MTAs such as sendmail, exim, qmail or postfix.
   48.21 -\end{quote}
   48.22 -\masqmail\ is a good replacement ``in these cases'', but not generally, since is lacks features essential for running on mail servers. It is primarily not secure enough for being accessable from untrusted locations.
   48.23 -
   48.24 -The program is best used in home networks, which are non-permanently connected to the internet. \masqmail\ sends mail to local destinations, like users on the same machine and on other machines in the local net, immediately. Email to recipients outside the local net are queued when offline and sent when a online connection gets established.
   48.25 -
   48.26 -Further more does \masqmail\ respect online connections through different \NAME{ISP}s; a common thing for dial-up connections. In particular can different sender addresses be set, dependent on the \NAME{ISP} that is used. This prevents mail to be likely classified as spam.
   48.27 -
   48.28 -
   48.29 -
   48.30 -\subsection{Typical usage}
   48.31 -This section describes situations that make senseful use of \masqmail.
   48.32 -
   48.33 -A home network consisting of some workstations without a server. The network is connected to the internet by dial-up or broadband. Going online is initiated by computers inside the local net. \NAME{IP} addresses change at least once every day.
   48.34 -
   48.35 -Every workstation would be equiped with \masqmail. Mail transfer within the same machine or within the local net works straight forward. Outgoing mail to the internet is sent, to the concerning \NAME{ISP} for relaying, whenever the router goes online. Receiving of mail from outside needs to be done by a mail fetch program, like the \masqmail\ internal \NAME{POP3} client or \name{fetchmail} for example. The configuration for \masqmail\ would be the same on every computer, except the hostname.
   48.36 -
   48.37 -For the same network but having a server, one could have \masqmail\ running on the server and using simple forwarders (see \ref{subsec:relay-only}) to the server on the workstations. This setup does only support mail transfer to the server, but not back to a workstation; also sending mail to another user on the same workstation is not possible.
   48.38 -
   48.39 -A better setup is to run \masqmail\ on every machine %FIXME
   48.40 -
   48.41 -
   48.42 -
   48.43 -\subsection{What makes it special}
   48.44 -
   48.45 -As main advantage, \masqmail\ makes it easy to set up an \MTA\ on workstations or notebooks without the need to do complex configuration or to be an mail server expert.
   48.46 -
   48.47 -Workstations use %FIXME
   48.48 -
   48.49 -
   48.50 -\subsection{Alternatives?}
   48.51 -% http://anfi.homeunix.org/sendmail/dialup10.html
   48.52 -
   48.53 -\section{History}
   48.54 -%TODO: let oliver prove read it!
   48.55 -%FIXME: add references
   48.56 -%FIXME: where does the name come from: masqdialer (guessed)
   48.57 -
   48.58 -The date of the first release (version 0.0.1) is unknown.
   48.59 -The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999.
   48.60 -Further releases were made every few weeks or month during 2000, 2001 and 2002.
   48.61 -Development ended in mid-2003 in a hard stop.
   48.62 -The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
   48.63 -
   48.64 -During the time of development, Oliver released 53 versions.
   48.65 -That means a new release in less than every 20 days in average!
   48.66 -
   48.67 -Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
   48.68 -
   48.69 -One extra release (version 0.2.21) was made by him in November 2005.
   48.70 -This one is only available from the \debian\ pool.
   48.71 -Comparing it to version 0.2.20 shows, that no source code was altered.
   48.72 -Only building documents (like Makefiles) and \debian\ packageing documents were changed.
   48.73 -That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
   48.74 -
   48.75 -In May 2000 the minor version number increased to `1'.
   48.76 -Nothing special is mentioned in the documentation about that.
   48.77 -When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail.
   48.78 -At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series.
   48.79 -His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.
   48.80 -
   48.81 -
   48.82 -
   48.83 -\section{Taking \masqmail}
   48.84 -
   48.85 -
   48.86 -
   48.87 -
   48.88 -\section{About \freesw\ projects}
   48.89 -
   48.90 -% http://www.faqs.org/docs/artu/
   48.91 -
   48.92 -There are several differences between \freesw\ projects and projects about proprietary software.
   48.93 -To understand \freesw\ projects, one needs to understand \freesw\ itself first.
   48.94 -
   48.95 -\subsection{About \freesw}
   48.96 -The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
   48.97 -Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
   48.98 -One could say, the \GPL\ catalized the \name{Free Software movement}.
   48.99 -
  48.100 -% http://www.fsf.org/about/what-is-free-software
  48.101 -
  48.102 -After all, the \GPL\ was not the first \freesw\ license used.
  48.103 -The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
  48.104 -Licenses providing the same rights have been used since long time ago.
  48.105 -But none of them was so often (re)used by other projects---thus gattering less awareness.
  48.106 -Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
  48.107 -
  48.108 -\freesw\ gives freedoms to its users.
  48.109 -In contrast to proprietary software restricting the users freedom.
  48.110 -The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
  48.111 -% http://www.gnu.org/philosophy/free-sw.html
  48.112 -% http://www.fsf.org/licensing/essays/free-sw.html
  48.113 -\begin{enumerate}
  48.114 -	\item The freedom to run the program, for any purpose (freedom 0).
  48.115 -	\item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
  48.116 -	\item The freedom to redistribute copies so you can help your neighbor (freedom 2).
  48.117 -	\item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
  48.118 -\end{enumerate}
  48.119 -
  48.120 -
  48.121 -\subsection{The term ``Open Source''}
  48.122 -\name{Open Source Software} often stands for the same as \freesw.
  48.123 -But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
  48.124 -
  48.125 -\name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
  48.126 -
  48.127 -% http://www.gnu.org/philosophy/open-source-misses-the-point.html
  48.128 -% http://catb.org/~esr/open-source.html
  48.129 -
  48.130 -
  48.131 -\subsection{Development of \freesw}
  48.132 -Having source code available and the right to modify it, encouridges programmers to actually do so.
  48.133 -Their modifications are manifoldly.
  48.134 -Some tailor the software to their needs.
  48.135 -Some add features.
  48.136 -Some do it just for fun.
  48.137 -There are no limitations---whoever wants to, may work on it.
  48.138 -
  48.139 -Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
  48.140 -The process of development is watchable by everyone.
  48.141 -
  48.142 -The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
  48.143 -
  48.144 -Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
  48.145 -
  48.146 -The following text will focus on the ``bazaar'' model.
  48.147 -
  48.148 -
  48.149 -\subsection{The role of the community}
  48.150 -\freesw\ projects rise and fall with their community!
  48.151 -
  48.152 -Most \freesw\ programs are developed by a very small group of programmers, often only one person.
  48.153 -But they are used by many people.
  48.154 -In between the programmers and the users, are people located who are a bit of both.
  48.155 -These are the ones that write documentation, find bugs and probably even fix it.
  48.156 -They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
  48.157 -The program is often spread by their ``advertising''.
  48.158 -
  48.159 -The \emph{community} consists of the actual developers and all users that contribute to the program.
  48.160 -Contribution can be one of the described ways, or others like providing a server for the project website for example.
  48.161 -
  48.162 -\emph{Community} is everyone who is in contact through the project.
  48.163 -Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
  48.164 -
  48.165 -There will hardly be a community if no communication channels are available.
  48.166 -If the development team does not provide them, there is a chance that encouraged users set them up on their own.
  48.167 -But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
  48.168 -
  48.169 -Projects without a good community tend to die sooner or later.
  48.170 -
  48.171 -
  48.172 -\subsection{Evolution of a community}
  48.173 -Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
  48.174 -He starts developing.
  48.175 -When others get in contact with the project, there may be some who are so much interested that they start co-developing.
  48.176 -Others report bugs, and some only use the program.
  48.177 -
  48.178 -After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
  48.179 -The size ratio of the groups vary by type of project.
  48.180 -
  48.181 -One should have that in mind, when starting a \freesw\ project.
  48.182 -
  48.183 -
  48.184 -\subsection{Creating a strong community}
  48.185 -Building up a good community needs some effort of the main developers.
  48.186 -%TODO: search for documents about this topic
  48.187 -
  48.188 -First communication channels need to be set up, to enable the growth of a community.
  48.189 -
  48.190 -Second, development should be visible by everyone who is interested in it.
  48.191 -Time between work done on the project and its visibility to the public should be kept short.
  48.192 -This makes it interesting for other developers to join.
  48.193 -Developers are the core of a community.
  48.194 -
  48.195 -Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
  48.196 -Releases are (more) stable versions, primary for users.
  48.197 -They should be created, frequently.
  48.198 -People will more likely use programs of active projects.
  48.199 -
  48.200 -Fourth, the developers should try to get the users ``in the boat''.
  48.201 -Good communities have a large group of users that do not only receive, but also give something back to the project.
  48.202 -The project leaders should motivate users to contribute.
  48.203 -This unlocks a big work force and gets lot of unexiting work done.
  48.204 -
  48.205 -Fifth, documentation matters.
  48.206 -Good documentation makes it easy for users and developers to start.
  48.207 -And it helps to avoid a lot of unsatisfaction.
  48.208 -Documentation is something that shows quality and that people care about the project.
  48.209 -
  48.210 -And sixth, project leaders should be good souvereigns.
  48.211 -They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
  48.212 -
  48.213 -Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
  48.214 -Volunteer work lives by acknowledgement of the effort spent.
  48.215 -
  48.216 -
  48.217 -
  48.218 -
  48.219 -
  48.220 -\section{Project infrastructure}
  48.221 -

    49.1 --- a/thesis/pieces/old/3-ProjectManagement.tex	Thu Jan 15 12:16:43 2009 +0100
    49.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    49.3 @@ -1,8 +0,0 @@
    49.4 -\chapter{Project management}
    49.5 -\section{Infrastructure}
    49.6 -\section{Community}
    49.7 -\section{Development}
    49.8 -\section{Documentation}
    49.9 -\section{Quality assurance}
   49.10 -\section{Distribution}
   49.11 -

    50.1 --- a/thesis/pieces/old/4-CodeAnalysis.tex	Thu Jan 15 12:16:43 2009 +0100
    50.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    50.3 @@ -1,29 +0,0 @@
    50.4 -\chapter{Code analysis}
    50.5 -
    50.6 -
    50.7 -\section{Architecture}
    50.8 -Like its anchestor \sendmail, \masqmail\ is a monolitic program. It consists of only one \emph{setuid root}\footnote{Runs as user root, no matter which user invoked it.}\index{setuid root} binary file, named \path{masqmail}. All functionality is included in it; of course some more comes from dynamic libraries linked.
    50.9 -
   50.10 -
   50.11 -
   50.12 -\subsection{Structure}
   50.13 -The \masqmail\ executable can be called under various names for \name{sendmail-compatibility} reasons. This is commonly organized by creating symbolic links with with different names to the \masqmail\ executable. These are \path{/usr/lib/sendmail} and \path{/usr/sbin/sendmail} because many programs expect a \mta\ to be located there. Further more \sendmail\ provides shortcuts by calling it with a different name instead of supplying command line arguments. The best known of it is \path{mailq}, which is equivilent to calling the \MTA\ with the argument \verb+-bq+. \masqmail\ reacts to the names \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The last four are an addition to \sendmail. Not implemented is the name \path{newaliases} because it is not relevant to \masqmail. To provide the command nonetheless, one may write a shell script located at \path{/usr/bin/newaliases}, that simply invokes \verb+masqmail -bi+.
   50.14 -
   50.15 -%masqmail: mailq, mailrm, runq, rmail, smtpd/in.smtpd
   50.16 -%sendmail: hoststat, mailq, newaliases, purgestat, smtpd
   50.17 -
   50.18 -\masqmail\ is written in the \NAME{C} programming language. The program, as of version 0.2.21, consists of 34 source code and eight header files, containing about 9,000 lines of code\footnote{Measured with \name{sloccount} by David A.\ Wheeler.}. Additionally, it includes a \name{base64} implementation (about 300 lines) and \name{md5} code (about 150 lines). For systems that do not provide \name{libident}, this library is distributed as well (circa 600 lines); an available shared library however has higher precedence in linking.
   50.19 -
   50.20 -The only mandatory dependency is \name{glib}---a cross-platform software utility library, originated in the \NAME{GTK+} project. It provides safer replacements for many standard library functions. (The unsafe \verb+sprintf()+ is one example.) Also it offers handy data containers, easy-to-use implementations of data structures, and much more.
   50.21 -
   50.22 -With \masqmail\ comes the small tool \path{mservdetect}; it helps setting up a configuration that uses the \name{mserver} system to detect the online state. Two other binaries get compiled for testing purposes: \path{readtest} and \path{smtpsend}. All three programms use \masqmail\ source code; they only add a file with a \verb+main()+ function each.
   50.23 -
   50.24 -\masqmail\ does not provide an interface for modules with additional functionality. There exists no add-on or module system. But the code is separated by function to the various source files, and some functional parts can be included or excluded by defining symbols. This means adding some argument (like \verb+--enable-maildir+) to the \verb+configure+ call. Thus the concerning code gets not removed by the preprocessor.
   50.25 -
   50.26 -
   50.27 -
   50.28 -
   50.29 -\section{Code quality}
   50.30 -
   50.31 -
   50.32 -\section{Security}

    51.1 --- a/thesis/pieces/old/4-Experience.tex	Thu Jan 15 12:16:43 2009 +0100
    51.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    51.3 @@ -1,2 +0,0 @@
    51.4 -\chapter{Experience}
    51.5 -

    52.1 --- a/thesis/pieces/old/4-Improvements.tex	Thu Jan 15 12:16:43 2009 +0100
    52.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    52.3 @@ -1,2 +0,0 @@
    52.4 -\chapter{Improvements}
    52.5 -

    53.1 --- a/thesis/pieces/old/4-ProjectManagement.tex	Thu Jan 15 12:16:43 2009 +0100
    53.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    53.3 @@ -1,2 +0,0 @@
    53.4 -\chapter{Project management 2}
    53.5 -

    54.1 --- a/thesis/pieces/old/4-Test.tex	Thu Jan 15 12:16:43 2009 +0100
    54.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    54.3 @@ -1,2 +0,0 @@
    54.4 -\chapter{Test and validation}
    54.5 -

    55.1 --- a/thesis/pieces/old/5-Future.tex	Thu Jan 15 12:16:43 2009 +0100
    55.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    55.3 @@ -1,2 +0,0 @@
    55.4 -\chapter{The future of \masqmail}
    55.5 -

    56.1 --- a/thesis/pieces/old/5-Summary.tex	Thu Jan 15 12:16:43 2009 +0100
    56.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    56.3 @@ -1,2 +0,0 @@
    56.4 -\chapter{Summary}
    56.5 -

    57.1 --- a/thesis/pieces/requirements.tex	Thu Jan 15 12:16:43 2009 +0100
    57.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    57.3 @@ -1,38 +0,0 @@
    57.4 -\chapter{Use cases}
    57.5 -
    57.6 -Here follow typical use cases for \masqmail. If other \MTA{}s are better suited for certain use cases, it will be mentioned. The use cases are prestage for defining the requirements.
    57.7 -
    57.8 -%FIXME: rewrite!
    57.9 -%       How do I write use cases??
   57.10 -%       Are use cases the right tool for what I need, at all??
   57.11 -
   57.12 -The user writes email with one of the common programs (e.g. \path{/bin/mail} or \name{mutt}). \masqmail\ must provide an interface, to that prepared mail can be handled over.
   57.13 -
   57.14 -\masqmail\ must deliver mail to its destination.
   57.15 -
   57.16 -Mail must be send with different settings, if someone uses more than one internet connection.
   57.17 -
   57.18 -If the machine is offline, no mail, destinated to the internet, must be send. It needs to be queued until an online connection gets established.
   57.19 -
   57.20 -If the computer goes online, all mail for outside destinations, should be send through the active route.
   57.21 -
   57.22 -Local mail should be send at once, independent of the online state.
   57.23 -
   57.24 -\masqmail\ may act as \NAME{SMTP} server. To receive email from other hosts.
   57.25 -
   57.26 -Mail for local users should be delivered by \masqmail\ itself or passed to \name{mail delivery agent}s.
   57.27 -
   57.28 -\masqmail\ needs to provide the same interface as \sendmail\ has, for being a drop-in replacement.
   57.29 -
   57.30 -
   57.31 -%TODO: add Schaeffter's ideas here
   57.32 -\chapter{Requirements}
   57.33 -
   57.34 -\section{Structure}
   57.35 -\section{Security}
   57.36 -\section{Usability}
   57.37 -\chapter{Security issues}
   57.38 -
   57.39 -%TODO: write about:
   57.40 -% #ifdefs in code
   57.41 -% the single setuid root binary

    58.1 --- a/thesis/pieces/spam-checking.txt	Thu Jan 15 12:16:43 2009 +0100
    58.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
    58.3 @@ -1,89 +0,0 @@
    58.4 -
    58.5 -%(eisentraut05: page 25) ``Ganz ohne Analyse während der SMTP-Phase kommt sowieso kein MTA aus, und es ist eine Frage der Einschätzung, wie weit man diese Phase belasten möchte.''
    58.6 -
    58.7 -
    58.8 -checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
    58.9 -checks when mail is accepted and queued: external (amavis, spamassassin)
   58.10 -
   58.11 -where to filter what
   58.12 -
   58.13 -
   58.14 -postfix:
   58.15 -content-filter: arbitrary programs that talk smtp, can filter, rewrite or delete mail
   58.16 -- before-queue-c-f: need to be fast, can prevent system load
   58.17 -- after-queue-c-f: need more resources in global, more load
   58.18 -
   58.19 -exim:
   58.20 -acls: to filter, what to accept (hook into smtp dialog) (complex)
   58.21 -routers: take recipient address and choose a matching transport
   58.22 -transports: ways to deliver mail (smtp, local)
   58.23 -
   58.24 -
   58.25 -postfix: after-queue-content-filter (smtp communication)
   58.26 -exim: content-scan-feature (analyses the content: MIME stuff, blacklisted words, virus scanning) (all within smtp dialog)
   58.27 -sendmail: milter (tcp or unix sockets)
   58.28 -
   58.29 -
   58.30 -
   58.31 -
   58.32 -
   58.33 -
   58.34 -
   58.35 -%what do do with recognized mail?
   58.36 -%- reject (only possible if recognized during SMTP dialog)
   58.37 -%- forward with added header line or changed subject
   58.38 -%(eisentraut05: page 18--20)
   58.39 -
   58.40 -check incoming and outgoing mail
   58.41 -(eisentraut05: page 21)
   58.42 -
   58.43 -
   58.44 -milter:
   58.45 -communication with external daemons via a special protocol
   58.46 -at various times in the smtp dialog possible
   58.47 -can reject, delete or alter messages
   58.48 -http://milter.org
   58.49 -(eisentraut05: page 69)
   58.50 -
   58.51 -
   58.52 -use SA with exim:
   58.53 -- with transport: piped into sa
   58.54 -- content-scanning-feature: with ACL during smtp dialog
   58.55 -- plugin: sa-exim
   58.56 -- within amavis
   58.57 -
   58.58 -use SA with sendmail:
   58.59 -- with milter
   58.60 -- within mimedefang or amavis
   58.61 -
   58.62 -use SA with postfix:
   58.63 -- within amavis or mailfilter
   58.64 -
   58.65 -
   58.66 -
   58.67 -
   58.68 -DNSBL can contain:
   58.69 -- open relays
   58.70 -- dynamic IP addresses
   58.71 -- verified spam sources
   58.72 -- open multistage relays
   58.73 -- vulnerable CGI scripts
   58.74 -- open proxy servers
   58.75 -example: NJABL (http://njabl.org)
   58.76 -
   58.77 -DNSBL in smpt dialog is aggressive and can lead to problems (eisentraut05: page 126)
   58.78 -
   58.79 -
   58.80 -greylisting:
   58.81 -if first contact from that address: temp failure and add to list
   58.82 -sender will retry, then accept
   58.83 -
   58.84 -``Das Greylisting zählt derzeit zu den effektivsten Methoden, um gegen unerwünschte E-Mails vorzugehen. Allein durch Greylisting können derzeit rund 70\% des potenziellen Spam-Aufkommens auf einem Mailserver vollständig geblockt werden. Allerdings ist es auch nur eine Frage der Zeit, bis sich die Gemeinde der Spammer und Virenautoren auf diese Methode der Spam-Bekämpfung eingerichtet und entsprechende Queues in ihre Software eingebaut hat.''(eisentraut05: page 138)
   58.85 -Probleme: load balancing using multiple servers with different IPs.
   58.86 -postfix: with policy server
   58.87 -exim: direct in config
   58.88 -sendmail: with greylist milter
   58.89 -
   58.90 -
   58.91 -
   58.92 -hashcash