1.1 --- a/thesis/tex/2-MailTransferAgents.tex	Wed Nov 26 22:08:55 2008 +0100
     1.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.3 @@ -1,247 +0,0 @@
     1.4 -\chapter{Mail transfer agents}
     1.5 -
     1.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.
     1.7 -
     1.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.
     1.9 -
    1.10 -
    1.11 -\section{Types of \MTA{}s}
    1.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}.}
    1.13 -
    1.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.
    1.15 -
    1.16 -Following are groups of \mta{}s that will \emph{not} be regarded further.
    1.17 -
    1.18 -\subsection*{Relay-only \MTA{}s}
    1.19 -\label{subsec:relay-only}
    1.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.
    1.21 -
    1.22 -Most \MTA{}s can be configured to act as such a \name{forwarder}. But this is usually an additional functionality.
    1.23 -
    1.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.
    1.25 -
    1.26 -Examples for that group are: \name{nullmailer}, \name{ssmtp} and \name{esmtp}.
    1.27 -
    1.28 -
    1.29 -\subsection*{Groupware}
    1.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.
    1.31 -
    1.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.
    1.33 -
    1.34 -Examples are: \name{Lotus Notes}, \name{Microsoft Exchange}, \name{OpenGroupware.org} and \name{eGroupWare}.
    1.35 -
    1.36 -
    1.37 -\subsection*{``Real'' \MTA{}s}
    1.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''.
    1.39 -
    1.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?
    1.41 -
    1.42 -This group is of importance in this document. The programs selected for the comparison are ``real \MTA{}s''.
    1.43 -
    1.44 -
    1.45 -
    1.46 -\subsection*{Non-\emph{sendmail-compatible} \MTA{}s}
    1.47 -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.
    1.48 -
    1.49 -Hence all \MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility addon, will not be covered here.
    1.50 -
    1.51 -An Examples here is \name{Apache James}.  %FIXME: check if correct
    1.52 -
    1.53 -
    1.54 -\subsection*{Non-free software}
    1.55 -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.
    1.56 -
    1.57 -The comparison should be seen from \masqmail's point of view, so non-free software is out of the way.
    1.58 -
    1.59 -
    1.60 -
    1.61 -\section{Popular \MTA{}s}
    1.62 -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.
    1.63 -
    1.64 -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
    1.65 -
    1.66 -\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}.
    1.67 -
    1.68 -Other members are: \name{smail}, \name{zmailer}, \name{mmdf}, and more; they all are less important and rarely used.
    1.69 -
    1.70 -Following is a small introduction to each of the five programs chosen for comparision.
    1.71 -
    1.72 -\subsection*{\sendmail}
    1.73 -\label{sec:sendmail}
    1.74 -\sendmail\ is the most popular \mta. Since it was one of the first \MTA{}s and was shipped by many vendors of \unix\ systems.
    1.75 -
    1.76 -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.
    1.77 -
    1.78 -\sendmail\ is focused on transfering mails between different protocols and networks, this lead to a very flexible (though complex) configuration.
    1.79 -
    1.80 -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.}.
    1.81 -
    1.82 -Further development will go into the project \name{MeTA1} which succeeds \sendmail.
    1.83 -
    1.84 -More information can be found on the \sendmail\ homepage \citeweb{sendmail:homepage} and on \citeweb{wikipedia:sendmail} and \citeweb{jdebp}.
    1.85 -
    1.86 -
    1.87 -\subsection*{\name{qmail}}
    1.88 -\label{sec:qmail}
    1.89 -\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.
    1.90 -
    1.91 -\name{qmail} first introduced may innovative concepts in \mta\ design and is generally seen as the first security-aware \MTA\ developed.
    1.92 -
    1.93 -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.
    1.94 -
    1.95 -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}.
    1.96 -
    1.97 -
    1.98 -\subsection*{\name{postfix}}
    1.99 -\label{sec:postfix}
   1.100 -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.
   1.101 -
   1.102 -Today \name{postfix} is taken by many \unix systems and \gnulinux distributions as default \MTA.
   1.103 -
   1.104 -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.
   1.105 -
   1.106 -Additional information is available on the program's homepage \citeweb{postfix:homepage}, on \citeweb{jdebp} and \citeweb{wikipedia:postfix}.
   1.107 -
   1.108 -
   1.109 -\subsection*{\name{exim}}
   1.110 -\label{sec:exim}
   1.111 -\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.
   1.112 -
   1.113 -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.
   1.114 -
   1.115 -\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.
   1.116 -
   1.117 -The program is \freesw, released under the \GPL. The latest stable version is 4.69 from December 2007.
   1.118 -
   1.119 -One finds \name{exim} on its homepage \citeweb{exim:homepage}. More information about it can be retrieved from \citeweb{wikipedia:exim} and \citeweb{jdebp}.
   1.120 -
   1.121 -
   1.122 -
   1.123 -
   1.124 -
   1.125 -
   1.126 -\section{Comparison of \MTA{}s}
   1.127 -
   1.128 -% http://shearer.org/MTA_Comparison
   1.129 -% http://www.geocities.com/mailsoftware42/
   1.130 -% http://fanf.livejournal.com/50917.html
   1.131 -% http://archives.neohapsis.com/archives/postfix/2006-07/1762.html
   1.132 -% http://www.oreillynet.com/lpt/a/6849
   1.133 -% http://www.mailradar.com/mailstat/
   1.134 -
   1.135 -\subsection{First release}
   1.136 -sendmail: 1983
   1.137 -
   1.138 -postfix: 1999
   1.139 -
   1.140 -qmail: 1996 (first beta 0.70), 1997 (first general 1.0)
   1.141 -
   1.142 -exim: 1995
   1.143 -
   1.144 -masqmail: 1999
   1.145 -
   1.146 -exchange: 1993
   1.147 -
   1.148 -
   1.149 -\subsection{Lines of code (with sloccount on debian packages)}
   1.150 -sendmail: 93k
   1.151 -
   1.152 -postfix: 92k
   1.153 -
   1.154 -qmail: 18k
   1.155 -
   1.156 -exim: 54k
   1.157 -
   1.158 -masqmail: 14k
   1.159 -
   1.160 -exchange: (no source available)
   1.161 -
   1.162 -
   1.163 -\subsection{Architecture}
   1.164 -sendmail: monolitic
   1.165 -
   1.166 -postfix: modular
   1.167 -
   1.168 -qmail: modular
   1.169 -
   1.170 -exim: monolitic
   1.171 -
   1.172 -masqmail: monolitic
   1.173 -
   1.174 -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.
   1.175 -
   1.176 -
   1.177 -exchange: (unknown)
   1.178 -
   1.179 -
   1.180 -\subsection{Design goals}
   1.181 -sendmail: flexibility
   1.182 -
   1.183 -postfix: performance and security
   1.184 -
   1.185 -qmail: security
   1.186 -
   1.187 -exim: general, flexible \& extensive facilities for checking
   1.188 -
   1.189 -masqmail: for non-permanent internet connection
   1.190 -
   1.191 -exchange: groupware
   1.192 -
   1.193 -
   1.194 -\subsection{Market share (by Bernstein in 2001)}
   1.195 -sendmail: 42\%
   1.196 -
   1.197 -postfix: 1.6\%
   1.198 -
   1.199 -qmail: 17\%
   1.200 -
   1.201 -exim: 1.6\%
   1.202 -
   1.203 -masqmail: (unknown)
   1.204 -
   1.205 -exchange: 18\%
   1.206 -
   1.207 -
   1.208 -
   1.209 -
   1.210 -<< complexity >>
   1.211 -
   1.212 -<< security >>
   1.213 -
   1.214 -<< simplicity of configuration and administration >>
   1.215 -
   1.216 -<< flexibility of configuration and administration >>
   1.217 -
   1.218 -<< code size >>
   1.219 -
   1.220 -<< code quality >>
   1.221 -
   1.222 -<< documentation (amount and quality) >>
   1.223 -
   1.224 -<< community (amount and quality) >>
   1.225 -
   1.226 -<< used it myself >>
   1.227 -
   1.228 -<<  had problems with it >>
   1.229 -
   1.230 -
   1.231 -
   1.232 -
   1.233 -<< quality criteria >> %FIXME
   1.234 -
   1.235 -<< standards of any kind >> %FIXME
   1.236 -
   1.237 -<< how to compare? >> %FIXME
   1.238 -
   1.239 -<< (bewertungsmatrix) objectivity >> %FIXME
   1.240 -
   1.241 -<< how many criterias for ``good''? >> %FIXME
   1.242 -
   1.243 -
   1.244 -
   1.245 -% from the practice of programming
   1.246 -% names: are they good?
   1.247 -% check the significant number of characters. (intern: 31char, extern: 6char caseless; ProgC p.184)
   1.248 -
   1.249 -
   1.250 -

     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Wed Nov 26 22:11:08 2008 +0100
     2.3 @@ -0,0 +1,312 @@
     2.4 +\chapter{Market analysis}
     2.5 +\label{chap:market-analysis}
     2.6 +
     2.7 +This chapter analyses the current situation and future trends, for electronic communication in general and email in particular. First electronic mail's position within other electronic communication technologies is located. Then trends for the whole field of electronic communication are shown. Afterwards opportunities and threats in the market are located and trends for email are figured out. The insights of these analysis result in a summary of things that are important for developing future-prove email software.
     2.8 +
     2.9 +
    2.10 +
    2.11 +\section{Electronic communication technologies}
    2.12 +
    2.13 +Electronic communication is ``communication by computer'', according to the \name{WordNet} database of \name{Princeton University} \citeweb{wordnet}. Mobile phones and telefax machines should be seen as computers here too. The \name{Science Glossary} of the \name{Pennsylvania Department of Education} describes electronic communication as ``System for the transmission of information using electronic technology (e.g., digital cameras, cellular telephones, Internet, television, fiber optics).'' \citeweb{science-glossary-pa}.
    2.14 +
    2.15 +Electronic communication needs no transport of tangible things, only electrons, photons, or radio waves need to be transmitted. Thus electronic communication is fast in general. With having costs mainly for infrastructure and very low costs for data transmission, electronic communication is also cheap communication. As underlying transport infrastructure, mostly the Internet is used; this makes it available nearly everywhere around the world. These properties---fast, cheap, everywhere---make electronic communication well suited for long distance communication.
    2.16 +
    2.17 +As globalization proceeds and long distance communication becomes more and more important. The future of electronic communication is bright.
    2.18 +
    2.19 +Electronic communication includes the following technologies: electronic mail (email), instant messaging (\name{IM}), chats (e.g.\ \NAME{IRC}), short message service (\NAME{SMS}), voicemail, video messages, and Voice over \NAME{IP} (VoIP).
    2.20 +
    2.21 +
    2.22 +\subsection{Classification}
    2.23 +Types of electronic communication can be divided in synchron and asynchron communication. Syncron communication are direct dialogs with little delay. Telephone conversation is an example. Asynchron communication are one-way message systems. Dialogs are possible as well, but not in the same direct fashion. These two groups can also be split by the time needed for data delivery. Synchron communication requires nearly real-time delivery, whereas message delivery times of several seconds or even minutes are sufficent for asynchron communication.
    2.24 +
    2.25 +Another possible separation is to distinguished written and recorded information. Recorded information, like audio or video data, is accessable only in a linear way by spooling and replay. Written information, on the other hand, can be accessed in arbitary sequence, detail and speed.
    2.26 +
    2.27 +%fixme: add ref to Lenke & Schmitz here
    2.28 +
    2.29 +Figure \ref{fig:comm-classification} shows a classification of communication technologies sorted by these two criteria. Email and \NAME{SMS} are written and asynchron communication; \NAME{IM} and chats are written information too, but synchron. Recorded information are voicemail and video messages as examples for asynchron communication. VoIP is an example for synchron communication.
    2.30 +
    2.31 +One might be surprised to find Instant \emph{Messaging} not in the group of \emph{message} communication. Instant Messaging could be put in both groups because it allows asynchron communication additional to being a chat system. The reasons why it is sorted to dialog communication are its primary use for dialog communication and the very fast---instant---delivery time.
    2.32 +
    2.33 +Email is not limited to written information, at least since the advent of \NAME{MIME}, which allows to include multimedia content in textual email messages. Thus recorded information can be sent as subparts of emails. The same applies to Instant Messaging too, where file transfer is an additional subservice offered by most systems. In general recorded information can be transmitted in an encoded textual form.
    2.34 +
    2.35 +
    2.36 +
    2.37 +%\begin{figure}
    2.38 +%	\begin{center}
    2.39 +%\begin{verbatim}
    2.40 +% ---------------------------------------------------
    2.41 +%             |                  |                  |
    2.42 +% messages    |  email           | voicemail        |
    2.43 +% asynchron   |  SMS             | video messages   |
    2.44 +%             |                  |                  |
    2.45 +% ---------------------------------------------------
    2.46 +%             |                  |                  |
    2.47 +% dialog      |  IM              | VoIP             |
    2.48 +% synchron    |  chat            | video conference |
    2.49 +%             |                  |                  |
    2.50 +% ---------------------------------------------------
    2.51 +%             |                  |                  |
    2.52 +%             | written          | recorded         |
    2.53 +%             |                  |                  |
    2.54 +%\end{verbatim}
    2.55 +%	\end{center}
    2.56 +%	\caption{Classification of electronic communication}
    2.57 +%	\label{fig:comm-classification}
    2.58 +%\end{figure}
    2.59 +
    2.60 +
    2.61 +\input{kvmacros}
    2.62 +\kvunitlength=3cm
    2.63 +\kvnoindex
    2.64 +
    2.65 +\begin{figure}
    2.66 +	\begin{center}
    2.67 +\karnaughmap{2}{}{
    2.68 +  {\parbox{\kvunitlength}{asynchron\\(messages)}}
    2.69 +  {written}
    2.70 +  {\parbox{\kvunitlength}{synchron\\(dialog)}}
    2.71 +  {recorded}
    2.72 +}{
    2.73 +	{\parbox{0.8\kvunitlength}{email\\\NAME{SMS}}}
    2.74 +	{\parbox{0.8\kvunitlength}{voicemail\\video messages}}
    2.75 +	{\parbox{0.8\kvunitlength}{\NAME{IM}\\chat}}
    2.76 +	{\parbox{0.8\kvunitlength}{VoIP\\video conferencing}}
    2.77 +}{}
    2.78 +	\end{center}
    2.79 +	\caption{Classification of electronic communication}
    2.80 +	\label{fig:comm-classification}
    2.81 +\end{figure}
    2.82 +
    2.83 +
    2.84 +
    2.85 +
    2.86 +\subsection{Life cycle analysis}
    2.87 +Life cycle analysis are common for products but also for technologies. This one here is for electronic communication technologies. The first dimensions regarded is the life time of the subject. It is segmented into the introduction, growth, mature, saturation, and decline phases. The second dimension can display sales, market share, importance, or similar values. The graph has always an S-line shape, with a slow start, a rapidly increasing first half, the highest level in the third quater, and a slowly declining end. Reaching the end of the life cycle means, the subject is inherited by its successor or the market situation changed thus making it oldfashioned.
    2.88 +
    2.89 +The current position on the life cycle of the introduced communication technologies is depicted in figure \ref{fig:comm-lifecycle}. It is important to notice that there is no time line matching for all of them---some life cycles are shorter than others---the shape of the graph, however, is the same.
    2.90 +
    2.91 +Video messages and voicemail are technologies in the introduction phase. Voice over \NAME{IP} is heavily growing these days. Instant Messaging has reached maturation, but still growing. Email is an example for a technology in the saturation phase. Declining does none of the above mentioned; telefax is an example for a declining technology.
    2.92 +
    2.93 +\begin{figure}
    2.94 +	\begin{center}
    2.95 +		\begin{verbatim}
    2.96 +|            |             |          |    *******  |          |
    2.97 +|            |             |          |*#**       **|  telefax |
    2.98 +|            |             |      ***** email       ***#**     |
    2.99 +|            |             |    **    |             |     *****|
   2.100 +|            |             |*#**      |             |          |
   2.101 +|            |           *** IM       |             |          |
   2.102 +|            |         **  |          |             |          |
   2.103 +|            |      *#*    |          |             |          |
   2.104 +|            |    ** VoIP  |          |             |          |
   2.105 +|            |  **         |          |             |          |
   2.106 +|        voice *           |          |             |          |
   2.107 +| video  mail**            |          |             |          |
   2.108 +| mess.   #**|             |          |             |          |
   2.109 +|    #****   |             |          |             |          |
   2.110 +|****        |             |          |             |          |
   2.111 +----------------------------------------------------------------
   2.112 +|            |             |          |             |          |
   2.113 +| introduct. | growth      | mature   | saturation  | decline  |
   2.114 +		\end{verbatim}
   2.115 +	\end{center}
   2.116 +	\caption{Life cycle of electronic communication technologies}
   2.117 +	\label{fig:comm-lifecycle}
   2.118 +\end{figure}
   2.119 +
   2.120 +Email ranges in the saturation phase, which is defined by a saturated market, no more products are needed, there is no more growth. This means, email is a technology used by everyone who want to use it. It is a standard technology. The current form of email in the current market is on the top of its life cycle. The future is decline, sooner or later.
   2.121 +
   2.122 +But life cycles positions change as the subject or the market changes. An examples is the \name{Flash} animation software. The product's change from a drawing and animation system to a technology for website building, advertising, and movie distribution, and the then changing target market, made it slip back on the life cycle. If the email system would evolve to become the basis for Unified Messaging (see section \ref{sec:unified-messaging}), a similar slip back would be the consequence. An example for a changing market are the \NAME{DVD} standards \NAME{DVD+} and \NAME{DVD-}. With the upcoming next generation formats BlueRay and \NAME{HD-DVD}, a much sooner decline of \NAME{DVD+} and \NAME{DVD-} started, even before reaching their last development steps in storage size. Such can happen to email too, if Unified Messaging is a revolution to the email system instead of an evolution.
   2.123 +
   2.124 +
   2.125 +
   2.126 +
   2.127 +\subsection{Trends}
   2.128 +Following are the trends for electronic communication. The trends are shown from the view point of \mta{}s. Nevertheless are these trends common for all of the communication technology.
   2.129 +
   2.130 +\subsubsection*{Consolidation}
   2.131 +There is a consolidation of communication technologies with similar transport characteristics, nowadays. Email is the most flexible kind of asynchron communication technology already in major use. Hence email is the best choice for transfering messages of any kind today. But in future it probably will be \name{Unified Messaging}, which tries to group all kinds of asynchron messaging into one communication system. It aims to provide a single transport protocol for all content and a flexible access interface for all kinds of clients. Unified messaging seems to have the potential to be the successor of all asynchron communication technologies, including email.
   2.132 +
   2.133 +Today email still is the major asynchron communication technology and it probably will be it for the next years. As Unified Messaging needs similar transfer facilities to email, it may to be an evolution not a revolution. Hence \mta{}s will still have importance in future, maybe in a modified way.
   2.134 +%todo: decentral organization, like the internet -> MTAs are well suited -> further technologies will need something similar
   2.135 +
   2.136 +
   2.137 +\subsubsection*{Integration}
   2.138 +Integration of communication technologies becomes popular. This goes beyond consolidation, because communication technologies of different kinds are bundled together to make communication more convenient for human. User interfaces tend to this direction. The underlying technologies will get grouped, but it seems as if synchron and asynchron communication can not be joined together in a sane way, so they will probably only merge at the surface.
   2.139 +
   2.140 +
   2.141 +
   2.142 +\subsubsection*{Communication hardware}
   2.143 +Hardware needed for communicating comes from two different roots: On the one side, the telephone, now available as mobile phones. This group centers around recorded data and dialog, but messages are supported by the answering machine and \NAME{SMS}. On the other side, mail and its relatives like email, using computers as main hardware. They center around document messages, support dialog communication in Instant Messaging and Voice over \NAME{IP}.
   2.144 +
   2.145 +The last years finally brought the two groups together, with \name{smart phones} being the merging hardware element. Smart phones are computers in the size of mobile phones or mobile phones with the capabilities of computers, however one likes to see it. They provide both functions, being telephones and computers.
   2.146 +
   2.147 +Smart Phones match well the requirements of recorded data, for which they were designed. Writing text is not good to do with the minimal keyboards available for smart phones; speech to text converters may provide help in future. This leaves us with the need for ordinary computers for the field of exchanging documents and as better input hardware for all written information.
   2.148 +
   2.149 +It seems as if a combination of computers and smart phones will be the hardware used for communication in future. Both specialized to the best matching communication technologies, but supporting the others too. Hence facilities for transfering information off and onto the devices will be needed.
   2.150 +
   2.151 +
   2.152 +
   2.153 +\subsubsection*{Unified Communication}
   2.154 +\name{Unified communication} is the technology aiming to consolidate and integrate all electronic communication and providing access for all kinds of hardware clients. Unified communication tries to bring the tree trends here mentioned together. The \name{PC Magazine} has the following definition in its Encyclopedia \citeweb{pcmag:uc}: ``[Unified communications is] The real-time redirection of a voice, text or e-mail message to the device closest to the intended recipient at any given time.'' The main goal is to integrate all kinds of communication (asynchronous and synchronous) into one system, hence this requires real-time delivery of data.
   2.155 +
   2.156 +According to Michael Osterman \citeweb{howto-def-uc}, unified communications is already possible as far as various incoming sources are routed to one storage where messages can be accessed by one or a few clients. But a system with an ``intelligent parser of a single data stream into separate streams that are designed to meet the real-time needs of the user'' is a goal for the future, he says.
   2.157 +
   2.158 +The question is, if the integration of synchronous and asynchronous message transfer does make sense. A communication between one person talking on the phone and the other replying using his instant messenger, certainly does, if the text-to-speech and speech-to-text convertion is fast and the quality good enough. But transfering large video messages and real-time communication data with the same technology, possibly does not.
   2.159 +
   2.160 +
   2.161 +
   2.162 +\subsubsection*{Unified Messaging}
   2.163 +\label{sec:unified-messaging}
   2.164 +\name{Unified messaging}, although often used exchangeable with unified communications, is only a subset of it. It does not require real-time data transmission and is therefor only usable for asynchronous communication \citeweb{wikipedia:uc}. Unified messaging's function is basically: Receiveing incoming messages from various channels, converting it to a common format, and storeing it into a single space. The stored messages can then be accessed from different devices. \citeweb{wikipedia:um}
   2.165 +
   2.166 +The easiest way of unified messaging is to base it on either email and convert all input sources to email messages (as attachments for instance) and store them in the user's mail box. Or use the telephone system as basis and convert text messages to speech. Both is no problem for asynchronous communication.
   2.167 +
   2.168 +Finally a critical voice from Jesse Freund, who voted unified messaging on top of a hype list for \name{Wired.com}, ten years ago \cite{wired:hype}. His description of the technology ended with the humorous sentences: ``Unified messaging is a nice idea, but a tough sell: The reason you bought a cell phone, a pager, and a fax/modem is because each does its job well. No one wants to download voicemail as a series of RealAudio messages or sit through a voicemail bot spelling out email, complete with "semicolon dash end-parenthesis" for ;-).''
   2.169 +
   2.170 +
   2.171 +%todo: have a result here?
   2.172 +
   2.173 +
   2.174 +
   2.175 +
   2.176 +\section{Electronic mail}
   2.177 +
   2.178 +After viewing the whole market of electronic communication, a zoom in to the market of electronic mail follows. Email is an asynchron communication technology that transports textual information primary. This thesis is about a \mta, so the market situation for email is important. Interesting questions are: Is email future-safe? How will electronic mail change? Will it change at all? Which are the critical parts? These questions matter when deciding on the directions for further development of an \MTA. They are discussed in this section.
   2.179 +
   2.180 +
   2.181 +
   2.182 +\subsection{\NAME{SWOT} analysis}
   2.183 +
   2.184 +A \NAME{SWOT} analysis regards the strengths and weaknesses of a subject against the opportunities and threats of its market. The slightly altered form called Dialectical SWOT analysis, which is used here, is described in \cite{powerof2x2}. SWOT analysises should always focus on a specific specific goal to reach with the product. In this case, the main goal is to make email future-safe.
   2.185 +
   2.186 +The market's main threat is \emph{spam}, also named \name{junk mail} or \name{unsolicited commercial email} (\NAME{UCE}). Panda Security and Commtouch state in their \name{Email Threats Trend Report} for the second Quater of 2008: ``Spam levels throughout the second quarter averaged 77\%, ranging from a low of 64\% to a peak of 94\% of all email [...]''\cite[page 4]{panda:email-threats}. The report sees the main reason in the botnets consisting of zombie computers: ``Spam and malware levels remain high for yet another quarter, powered by the brawny yet agile networks of zombie IPs.''\cite[page 1]{panda:email-threats} This is supported by IronPort Systems: ``More than 80 percent of spam now comes from a `zombie'---an infected PC, typically in a consumer broadband network, that has been hijacked by spammers.''\cite{ironport:zombie-computers}. Positiv for MTAs is, that they are not the main source for spam, but it is only a small delight. Spam is a general weakness of the email system, because it can not prevent it.
   2.187 +
   2.188 +Opportunities of the market are large data transfers, coming from multimedia content, which becomes popular. If email is used as basis for unified messaging, lots of voice and video mail will need to be transfered. Email is weak related to that kind of data: the data needs to be encoded to \NAME{ASCII} and and stresses mail servers a lot.
   2.189 +
   2.190 +The use of various hardware to access mail is another opportunity of the market. The software and infrastructure needed to transfer mail within this network might be a weakness of the email system. %fixme: think about that
   2.191 +
   2.192 +An opportunity of the market and at the same time a strength of electronic mail is its standardization. Few other communication technologies are standardized and thus freely available in a similar way. %fixme: ref
   2.193 +Another opportunity and strength is the modular and extendable structure of electronic mail; it can easily evolve to new requirements. %fixme: ref
   2.194 +
   2.195 +The increasing integration of communication channels, is an opportunity for the market. But deciding weather it is a weakness or strength of email is not so easy. It is a weakness because the not possible integration of stream data and the not good integration of large binary data. It is also a strength, because arbitary asynchron communication data already can be integrated. On the other hand, the integration might be a threat too, because it easily leads to complexity of software. Complex software is more error prone and thus less reliable. This could be a strength of electronic mail because of its modular design that decreases complexity, but real integration is harder to do than in monolitic systems.
   2.196 +
   2.197 +Figure \ref{fig:email-swot} displays the \NAME{SWOT} analysis in a handy overview. It is easy to see, that the opportunities outweigh. This indicates a still increasing technology. %fixme: ref
   2.198 +
   2.199 +\begin{figure}
   2.200 +	\begin{center}
   2.201 +		\begin{verbatim}
   2.202 + ---------------------------------------------------
   2.203 +             |                  |                  |
   2.204 + strength    | standard         |                  |
   2.205 + of email    | modular,extendabl|                  |
   2.206 +             |                  |                  |
   2.207 + ---------------------------------------------------
   2.208 +             | big data transfer|                  |
   2.209 + weaknesses  | too big for phone|                  |
   2.210 + of email    |                  | spam             |
   2.211 +             |                  |                  |
   2.212 + ---------------------------------------------------
   2.213 +             |                  |                  |
   2.214 +             | opportunities of | threats of       |
   2.215 +             | market           | market           |
   2.216 +             |                  |                  |
   2.217 +		\end{verbatim}
   2.218 +	\end{center}
   2.219 +	\caption{SWOT analysis for email}
   2.220 +	\label{fig:email-swot}
   2.221 +\end{figure}
   2.222 +
   2.223 +The analysis shows what should be done to achieve the goal (Making email future-safe). Spam mail should be reduced as good as possible. Solutions for large data transfers and infrastructures with more nodes moving within the net should be developed, there is a lot of potential. Standardization, modularity and extendability should be used to go even further, these are the key advantages of email.
   2.224 +%fixme: a bit more concrete, see description of swot analysis
   2.225 +
   2.226 +
   2.227 +
   2.228 +\subsubsection*{Differences in \freesw}
   2.229 +%fixme: where to put this comment ... appears to be relevant
   2.230 +<< what consumers choose >>
   2.231 +%todo: is it _really_ important?
   2.232 +
   2.233 +
   2.234 +
   2.235 +
   2.236 +
   2.237 +\subsection{Trends for electronic mail}
   2.238 +
   2.239 +Trends and possible trend, or just plans to think about, are presented now.
   2.240 +%Emailing in future will not be the same as emailing today. This will mainly affect how email is transfered.
   2.241 +
   2.242 +
   2.243 +\subsubsection*{Provider independence}
   2.244 +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}),
   2.245 +%fixme: check for non-breakable dash
   2.246 +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.
   2.247 +
   2.248 +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.
   2.249 +
   2.250 +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.
   2.251 +
   2.252 +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.
   2.253 +
   2.254 +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.
   2.255 +
   2.256 +
   2.257 +\subsubsection*{Pushing versus polling}
   2.258 +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.
   2.259 +
   2.260 +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.
   2.261 +
   2.262 +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.
   2.263 +%FIXME: add reference to push email
   2.264 +
   2.265 +
   2.266 +\subsubsection*{Internet Mail 2000}
   2.267 +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.
   2.268 +
   2.269 +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.
   2.270 +
   2.271 +\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}.
   2.272 +%FIXME: add references for IM2000
   2.273 +
   2.274 +
   2.275 +
   2.276 +
   2.277 +
   2.278 +\subsection{Future-safety of email}
   2.279 +%fixme: rework
   2.280 +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.
   2.281 +
   2.282 +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.
   2.283 +
   2.284 +
   2.285 +
   2.286 +
   2.287 +
   2.288 +\section{What will be important}
   2.289 +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. Because as the fields and kinds of usage change, the requirement change too.
   2.290 +
   2.291 +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 and water supply systems. Or configuration needs to be easy and fool-prove, to be done by the owner himself. The latter solution depends on standardized parts that fit together seamlessly. The technology must not be a problem itself. Only settings custom to the users environment should be left open for him to set. This of course needs to be doable using a simple configuration interface like a web interface. Non-technical educated users should be able to configure the system.
   2.292 +
   2.293 +\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.
   2.294 +
   2.295 +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
   2.296 +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.\ graphical programs, websites, command line programs; all of them either in a questionaire style or iteractive).
   2.297 +
   2.298 +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 large amounts of mail in short time. Home servers or workstations however, do not see that much mail; they need to handle only tens or hundreds of email messages per hour. Thus performance will probably not be a main requirement for an \MTA\ in future, if they mainly run on private machines.
   2.299 +
   2.300 +\name{postfix} focuses much on performance, this might not be an important point then.
   2.301 +
   2.302 +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 the flexibility of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}).
   2.303 +
   2.304 +Another important requirement for all kinds of software will be security. There is a constant trend coming from completely non-secured software, in 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 be even more important in the next years. As more clients get connected to the Internet and especially more computers are listening for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing of software systems will be done with increasing effort in future.
   2.305 +
   2.306 +``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-\NAME{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.
   2.307 +
   2.308 +Secure and robust software is a pre-requisite for such boxes to make that vision possible.
   2.309 +
   2.310 +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.
   2.311 +
   2.312 +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.
   2.313 +
   2.314 +
   2.315 +

     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Wed Nov 26 22:11:08 2008 +0100
     3.3 @@ -0,0 +1,247 @@
     3.4 +\chapter{Mail transfer agents}
     3.5 +
     3.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.
     3.7 +
     3.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.
     3.9 +
    3.10 +
    3.11 +\section{Types of \MTA{}s}
    3.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}.}
    3.13 +
    3.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.
    3.15 +
    3.16 +Following are groups of \mta{}s that will \emph{not} be regarded further.
    3.17 +
    3.18 +\subsection*{Relay-only \MTA{}s}
    3.19 +\label{subsec:relay-only}
    3.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.
    3.21 +
    3.22 +Most \MTA{}s can be configured to act as such a \name{forwarder}. But this is usually an additional functionality.
    3.23 +
    3.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.
    3.25 +
    3.26 +Examples for that group are: \name{nullmailer}, \name{ssmtp} and \name{esmtp}.
    3.27 +
    3.28 +
    3.29 +\subsection*{Groupware}
    3.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.
    3.31 +
    3.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.
    3.33 +
    3.34 +Examples are: \name{Lotus Notes}, \name{Microsoft Exchange}, \name{OpenGroupware.org} and \name{eGroupWare}.
    3.35 +
    3.36 +
    3.37 +\subsection*{``Real'' \MTA{}s}
    3.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''.
    3.39 +
    3.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?
    3.41 +
    3.42 +This group is of importance in this document. The programs selected for the comparison are ``real \MTA{}s''.
    3.43 +
    3.44 +
    3.45 +
    3.46 +\subsection*{Non-\emph{sendmail-compatible} \MTA{}s}
    3.47 +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.
    3.48 +
    3.49 +Hence all \MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility addon, will not be covered here.
    3.50 +
    3.51 +An Examples here is \name{Apache James}.  %FIXME: check if correct
    3.52 +
    3.53 +
    3.54 +\subsection*{Non-free software}
    3.55 +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.
    3.56 +
    3.57 +The comparison should be seen from \masqmail's point of view, so non-free software is out of the way.
    3.58 +
    3.59 +
    3.60 +
    3.61 +\section{Popular \MTA{}s}
    3.62 +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.
    3.63 +
    3.64 +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
    3.65 +
    3.66 +\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}.
    3.67 +
    3.68 +Other members are: \name{smail}, \name{zmailer}, \name{mmdf}, and more; they all are less important and rarely used.
    3.69 +
    3.70 +Following is a small introduction to each of the five programs chosen for comparision.
    3.71 +
    3.72 +\subsection*{\sendmail}
    3.73 +\label{sec:sendmail}
    3.74 +\sendmail\ is the most popular \mta. Since it was one of the first \MTA{}s and was shipped by many vendors of \unix\ systems.
    3.75 +
    3.76 +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.
    3.77 +
    3.78 +\sendmail\ is focused on transfering mails between different protocols and networks, this lead to a very flexible (though complex) configuration.
    3.79 +
    3.80 +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.}.
    3.81 +
    3.82 +Further development will go into the project \name{MeTA1} which succeeds \sendmail.
    3.83 +
    3.84 +More information can be found on the \sendmail\ homepage \citeweb{sendmail:homepage} and on \citeweb{wikipedia:sendmail} and \citeweb{jdebp}.
    3.85 +
    3.86 +
    3.87 +\subsection*{\name{qmail}}
    3.88 +\label{sec:qmail}
    3.89 +\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.
    3.90 +
    3.91 +\name{qmail} first introduced may innovative concepts in \mta\ design and is generally seen as the first security-aware \MTA\ developed.
    3.92 +
    3.93 +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.
    3.94 +
    3.95 +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}.
    3.96 +
    3.97 +
    3.98 +\subsection*{\name{postfix}}
    3.99 +\label{sec:postfix}
   3.100 +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.
   3.101 +
   3.102 +Today \name{postfix} is taken by many \unix systems and \gnulinux distributions as default \MTA.
   3.103 +
   3.104 +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.
   3.105 +
   3.106 +Additional information is available on the program's homepage \citeweb{postfix:homepage}, on \citeweb{jdebp} and \citeweb{wikipedia:postfix}.
   3.107 +
   3.108 +
   3.109 +\subsection*{\name{exim}}
   3.110 +\label{sec:exim}
   3.111 +\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.
   3.112 +
   3.113 +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.
   3.114 +
   3.115 +\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.
   3.116 +
   3.117 +The program is \freesw, released under the \GPL. The latest stable version is 4.69 from December 2007.
   3.118 +
   3.119 +One finds \name{exim} on its homepage \citeweb{exim:homepage}. More information about it can be retrieved from \citeweb{wikipedia:exim} and \citeweb{jdebp}.
   3.120 +
   3.121 +
   3.122 +
   3.123 +
   3.124 +
   3.125 +
   3.126 +\section{Comparison of \MTA{}s}
   3.127 +
   3.128 +% http://shearer.org/MTA_Comparison
   3.129 +% http://www.geocities.com/mailsoftware42/
   3.130 +% http://fanf.livejournal.com/50917.html
   3.131 +% http://archives.neohapsis.com/archives/postfix/2006-07/1762.html
   3.132 +% http://www.oreillynet.com/lpt/a/6849
   3.133 +% http://www.mailradar.com/mailstat/
   3.134 +
   3.135 +\subsection{First release}
   3.136 +sendmail: 1983
   3.137 +
   3.138 +postfix: 1999
   3.139 +
   3.140 +qmail: 1996 (first beta 0.70), 1997 (first general 1.0)
   3.141 +
   3.142 +exim: 1995
   3.143 +
   3.144 +masqmail: 1999
   3.145 +
   3.146 +exchange: 1993
   3.147 +
   3.148 +
   3.149 +\subsection{Lines of code (with sloccount on debian packages)}
   3.150 +sendmail: 93k
   3.151 +
   3.152 +postfix: 92k
   3.153 +
   3.154 +qmail: 18k
   3.155 +
   3.156 +exim: 54k
   3.157 +
   3.158 +masqmail: 14k
   3.159 +
   3.160 +exchange: (no source available)
   3.161 +
   3.162 +
   3.163 +\subsection{Architecture}
   3.164 +sendmail: monolitic
   3.165 +
   3.166 +postfix: modular
   3.167 +
   3.168 +qmail: modular
   3.169 +
   3.170 +exim: monolitic
   3.171 +
   3.172 +masqmail: monolitic
   3.173 +
   3.174 +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.
   3.175 +
   3.176 +
   3.177 +exchange: (unknown)
   3.178 +
   3.179 +
   3.180 +\subsection{Design goals}
   3.181 +sendmail: flexibility
   3.182 +
   3.183 +postfix: performance and security
   3.184 +
   3.185 +qmail: security
   3.186 +
   3.187 +exim: general, flexible \& extensive facilities for checking
   3.188 +
   3.189 +masqmail: for non-permanent internet connection
   3.190 +
   3.191 +exchange: groupware
   3.192 +
   3.193 +
   3.194 +\subsection{Market share (by Bernstein in 2001)}
   3.195 +sendmail: 42\%
   3.196 +
   3.197 +postfix: 1.6\%
   3.198 +
   3.199 +qmail: 17\%
   3.200 +
   3.201 +exim: 1.6\%
   3.202 +
   3.203 +masqmail: (unknown)
   3.204 +
   3.205 +exchange: 18\%
   3.206 +
   3.207 +
   3.208 +
   3.209 +
   3.210 +<< complexity >>
   3.211 +
   3.212 +<< security >>
   3.213 +
   3.214 +<< simplicity of configuration and administration >>
   3.215 +
   3.216 +<< flexibility of configuration and administration >>
   3.217 +
   3.218 +<< code size >>
   3.219 +
   3.220 +<< code quality >>
   3.221 +
   3.222 +<< documentation (amount and quality) >>
   3.223 +
   3.224 +<< community (amount and quality) >>
   3.225 +
   3.226 +<< used it myself >>
   3.227 +
   3.228 +<<  had problems with it >>
   3.229 +
   3.230 +
   3.231 +
   3.232 +
   3.233 +<< quality criteria >> %FIXME
   3.234 +
   3.235 +<< standards of any kind >> %FIXME
   3.236 +
   3.237 +<< how to compare? >> %FIXME
   3.238 +
   3.239 +<< (bewertungsmatrix) objectivity >> %FIXME
   3.240 +
   3.241 +<< how many criterias for ``good''? >> %FIXME
   3.242 +
   3.243 +
   3.244 +
   3.245 +% from the practice of programming
   3.246 +% names: are they good?
   3.247 +% check the significant number of characters. (intern: 31char, extern: 6char caseless; ProgC p.184)
   3.248 +
   3.249 +
   3.250 +

     4.1 --- a/thesis/tex/3-MarketAnalysis.tex	Wed Nov 26 22:08:55 2008 +0100
     4.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     4.3 @@ -1,312 +0,0 @@
     4.4 -\chapter{Market analysis}
     4.5 -\label{chap:market-analysis}
     4.6 -
     4.7 -This chapter analyses the current situation and future trends, for electronic communication in general and email in particular. First electronic mail's position within other electronic communication technologies is located. Then trends for the whole field of electronic communication are shown. Afterwards opportunities and threats in the market are located and trends for email are figured out. The insights of these analysis result in a summary of things that are important for developing future-prove email software.
     4.8 -
     4.9 -
    4.10 -
    4.11 -\section{Electronic communication technologies}
    4.12 -
    4.13 -Electronic communication is ``communication by computer'', according to the \name{WordNet} database of \name{Princeton University} \citeweb{wordnet}. Mobile phones and telefax machines should be seen as computers here too. The \name{Science Glossary} of the \name{Pennsylvania Department of Education} describes electronic communication as ``System for the transmission of information using electronic technology (e.g., digital cameras, cellular telephones, Internet, television, fiber optics).'' \citeweb{science-glossary-pa}.
    4.14 -
    4.15 -Electronic communication needs no transport of tangible things, only electrons, photons, or radio waves need to be transmitted. Thus electronic communication is fast in general. With having costs mainly for infrastructure and very low costs for data transmission, electronic communication is also cheap communication. As underlying transport infrastructure, mostly the Internet is used; this makes it available nearly everywhere around the world. These properties---fast, cheap, everywhere---make electronic communication well suited for long distance communication.
    4.16 -
    4.17 -As globalization proceeds and long distance communication becomes more and more important. The future of electronic communication is bright.
    4.18 -
    4.19 -Electronic communication includes the following technologies: electronic mail (email), instant messaging (\name{IM}), chats (e.g.\ \NAME{IRC}), short message service (\NAME{SMS}), voicemail, video messages, and Voice over \NAME{IP} (VoIP).
    4.20 -
    4.21 -
    4.22 -\subsection{Classification}
    4.23 -Types of electronic communication can be divided in synchron and asynchron communication. Syncron communication are direct dialogs with little delay. Telephone conversation is an example. Asynchron communication are one-way message systems. Dialogs are possible as well, but not in the same direct fashion. These two groups can also be split by the time needed for data delivery. Synchron communication requires nearly real-time delivery, whereas message delivery times of several seconds or even minutes are sufficent for asynchron communication.
    4.24 -
    4.25 -Another possible separation is to distinguished written and recorded information. Recorded information, like audio or video data, is accessable only in a linear way by spooling and replay. Written information, on the other hand, can be accessed in arbitary sequence, detail and speed.
    4.26 -
    4.27 -%fixme: add ref to Lenke & Schmitz here
    4.28 -
    4.29 -Figure \ref{fig:comm-classification} shows a classification of communication technologies sorted by these two criteria. Email and \NAME{SMS} are written and asynchron communication; \NAME{IM} and chats are written information too, but synchron. Recorded information are voicemail and video messages as examples for asynchron communication. VoIP is an example for synchron communication.
    4.30 -
    4.31 -One might be surprised to find Instant \emph{Messaging} not in the group of \emph{message} communication. Instant Messaging could be put in both groups because it allows asynchron communication additional to being a chat system. The reasons why it is sorted to dialog communication are its primary use for dialog communication and the very fast---instant---delivery time.
    4.32 -
    4.33 -Email is not limited to written information, at least since the advent of \NAME{MIME}, which allows to include multimedia content in textual email messages. Thus recorded information can be sent as subparts of emails. The same applies to Instant Messaging too, where file transfer is an additional subservice offered by most systems. In general recorded information can be transmitted in an encoded textual form.
    4.34 -
    4.35 -
    4.36 -
    4.37 -%\begin{figure}
    4.38 -%	\begin{center}
    4.39 -%\begin{verbatim}
    4.40 -% ---------------------------------------------------
    4.41 -%             |                  |                  |
    4.42 -% messages    |  email           | voicemail        |
    4.43 -% asynchron   |  SMS             | video messages   |
    4.44 -%             |                  |                  |
    4.45 -% ---------------------------------------------------
    4.46 -%             |                  |                  |
    4.47 -% dialog      |  IM              | VoIP             |
    4.48 -% synchron    |  chat            | video conference |
    4.49 -%             |                  |                  |
    4.50 -% ---------------------------------------------------
    4.51 -%             |                  |                  |
    4.52 -%             | written          | recorded         |
    4.53 -%             |                  |                  |
    4.54 -%\end{verbatim}
    4.55 -%	\end{center}
    4.56 -%	\caption{Classification of electronic communication}
    4.57 -%	\label{fig:comm-classification}
    4.58 -%\end{figure}
    4.59 -
    4.60 -
    4.61 -\input{kvmacros}
    4.62 -\kvunitlength=3cm
    4.63 -\kvnoindex
    4.64 -
    4.65 -\begin{figure}
    4.66 -	\begin{center}
    4.67 -\karnaughmap{2}{}{
    4.68 -  {\parbox{\kvunitlength}{asynchron\\(messages)}}
    4.69 -  {written}
    4.70 -  {\parbox{\kvunitlength}{synchron\\(dialog)}}
    4.71 -  {recorded}
    4.72 -}{
    4.73 -	{\parbox{0.8\kvunitlength}{email\\\NAME{SMS}}}
    4.74 -	{\parbox{0.8\kvunitlength}{voicemail\\video messages}}
    4.75 -	{\parbox{0.8\kvunitlength}{\NAME{IM}\\chat}}
    4.76 -	{\parbox{0.8\kvunitlength}{VoIP\\video conferencing}}
    4.77 -}{}
    4.78 -	\end{center}
    4.79 -	\caption{Classification of electronic communication}
    4.80 -	\label{fig:comm-classification}
    4.81 -\end{figure}
    4.82 -
    4.83 -
    4.84 -
    4.85 -
    4.86 -\subsection{Life cycle analysis}
    4.87 -Life cycle analysis are common for products but also for technologies. This one here is for electronic communication technologies. The first dimensions regarded is the life time of the subject. It is segmented into the introduction, growth, mature, saturation, and decline phases. The second dimension can display sales, market share, importance, or similar values. The graph has always an S-line shape, with a slow start, a rapidly increasing first half, the highest level in the third quater, and a slowly declining end. Reaching the end of the life cycle means, the subject is inherited by its successor or the market situation changed thus making it oldfashioned.
    4.88 -
    4.89 -The current position on the life cycle of the introduced communication technologies is depicted in figure \ref{fig:comm-lifecycle}. It is important to notice that there is no time line matching for all of them---some life cycles are shorter than others---the shape of the graph, however, is the same.
    4.90 -
    4.91 -Video messages and voicemail are technologies in the introduction phase. Voice over \NAME{IP} is heavily growing these days. Instant Messaging has reached maturation, but still growing. Email is an example for a technology in the saturation phase. Declining does none of the above mentioned; telefax is an example for a declining technology.
    4.92 -
    4.93 -\begin{figure}
    4.94 -	\begin{center}
    4.95 -		\begin{verbatim}
    4.96 -|            |             |          |    *******  |          |
    4.97 -|            |             |          |*#**       **|  telefax |
    4.98 -|            |             |      ***** email       ***#**     |
    4.99 -|            |             |    **    |             |     *****|
   4.100 -|            |             |*#**      |             |          |
   4.101 -|            |           *** IM       |             |          |
   4.102 -|            |         **  |          |             |          |
   4.103 -|            |      *#*    |          |             |          |
   4.104 -|            |    ** VoIP  |          |             |          |
   4.105 -|            |  **         |          |             |          |
   4.106 -|        voice *           |          |             |          |
   4.107 -| video  mail**            |          |             |          |
   4.108 -| mess.   #**|             |          |             |          |
   4.109 -|    #****   |             |          |             |          |
   4.110 -|****        |             |          |             |          |
   4.111 -----------------------------------------------------------------
   4.112 -|            |             |          |             |          |
   4.113 -| introduct. | growth      | mature   | saturation  | decline  |
   4.114 -		\end{verbatim}
   4.115 -	\end{center}
   4.116 -	\caption{Life cycle of electronic communication technologies}
   4.117 -	\label{fig:comm-lifecycle}
   4.118 -\end{figure}
   4.119 -
   4.120 -Email ranges in the saturation phase, which is defined by a saturated market, no more products are needed, there is no more growth. This means, email is a technology used by everyone who want to use it. It is a standard technology. The current form of email in the current market is on the top of its life cycle. The future is decline, sooner or later.
   4.121 -
   4.122 -But life cycles positions change as the subject or the market changes. An examples is the \name{Flash} animation software. The product's change from a drawing and animation system to a technology for website building, advertising, and movie distribution, and the then changing target market, made it slip back on the life cycle. If the email system would evolve to become the basis for Unified Messaging (see section \ref{sec:unified-messaging}), a similar slip back would be the consequence. An example for a changing market are the \NAME{DVD} standards \NAME{DVD+} and \NAME{DVD-}. With the upcoming next generation formats BlueRay and \NAME{HD-DVD}, a much sooner decline of \NAME{DVD+} and \NAME{DVD-} started, even before reaching their last development steps in storage size. Such can happen to email too, if Unified Messaging is a revolution to the email system instead of an evolution.
   4.123 -
   4.124 -
   4.125 -
   4.126 -
   4.127 -\subsection{Trends}
   4.128 -Following are the trends for electronic communication. The trends are shown from the view point of \mta{}s. Nevertheless are these trends common for all of the communication technology.
   4.129 -
   4.130 -\subsubsection*{Consolidation}
   4.131 -There is a consolidation of communication technologies with similar transport characteristics, nowadays. Email is the most flexible kind of asynchron communication technology already in major use. Hence email is the best choice for transfering messages of any kind today. But in future it probably will be \name{Unified Messaging}, which tries to group all kinds of asynchron messaging into one communication system. It aims to provide a single transport protocol for all content and a flexible access interface for all kinds of clients. Unified messaging seems to have the potential to be the successor of all asynchron communication technologies, including email.
   4.132 -
   4.133 -Today email still is the major asynchron communication technology and it probably will be it for the next years. As Unified Messaging needs similar transfer facilities to email, it may to be an evolution not a revolution. Hence \mta{}s will still have importance in future, maybe in a modified way.
   4.134 -%todo: decentral organization, like the internet -> MTAs are well suited -> further technologies will need something similar
   4.135 -
   4.136 -
   4.137 -\subsubsection*{Integration}
   4.138 -Integration of communication technologies becomes popular. This goes beyond consolidation, because communication technologies of different kinds are bundled together to make communication more convenient for human. User interfaces tend to this direction. The underlying technologies will get grouped, but it seems as if synchron and asynchron communication can not be joined together in a sane way, so they will probably only merge at the surface.
   4.139 -
   4.140 -
   4.141 -
   4.142 -\subsubsection*{Communication hardware}
   4.143 -Hardware needed for communicating comes from two different roots: On the one side, the telephone, now available as mobile phones. This group centers around recorded data and dialog, but messages are supported by the answering machine and \NAME{SMS}. On the other side, mail and its relatives like email, using computers as main hardware. They center around document messages, support dialog communication in Instant Messaging and Voice over \NAME{IP}.
   4.144 -
   4.145 -The last years finally brought the two groups together, with \name{smart phones} being the merging hardware element. Smart phones are computers in the size of mobile phones or mobile phones with the capabilities of computers, however one likes to see it. They provide both functions, being telephones and computers.
   4.146 -
   4.147 -Smart Phones match well the requirements of recorded data, for which they were designed. Writing text is not good to do with the minimal keyboards available for smart phones; speech to text converters may provide help in future. This leaves us with the need for ordinary computers for the field of exchanging documents and as better input hardware for all written information.
   4.148 -
   4.149 -It seems as if a combination of computers and smart phones will be the hardware used for communication in future. Both specialized to the best matching communication technologies, but supporting the others too. Hence facilities for transfering information off and onto the devices will be needed.
   4.150 -
   4.151 -
   4.152 -
   4.153 -\subsubsection*{Unified Communication}
   4.154 -\name{Unified communication} is the technology aiming to consolidate and integrate all electronic communication and providing access for all kinds of hardware clients. Unified communication tries to bring the tree trends here mentioned together. The \name{PC Magazine} has the following definition in its Encyclopedia \citeweb{pcmag:uc}: ``[Unified communications is] The real-time redirection of a voice, text or e-mail message to the device closest to the intended recipient at any given time.'' The main goal is to integrate all kinds of communication (asynchronous and synchronous) into one system, hence this requires real-time delivery of data.
   4.155 -
   4.156 -According to Michael Osterman \citeweb{howto-def-uc}, unified communications is already possible as far as various incoming sources are routed to one storage where messages can be accessed by one or a few clients. But a system with an ``intelligent parser of a single data stream into separate streams that are designed to meet the real-time needs of the user'' is a goal for the future, he says.
   4.157 -
   4.158 -The question is, if the integration of synchronous and asynchronous message transfer does make sense. A communication between one person talking on the phone and the other replying using his instant messenger, certainly does, if the text-to-speech and speech-to-text convertion is fast and the quality good enough. But transfering large video messages and real-time communication data with the same technology, possibly does not.
   4.159 -
   4.160 -
   4.161 -
   4.162 -\subsubsection*{Unified Messaging}
   4.163 -\label{sec:unified-messaging}
   4.164 -\name{Unified messaging}, although often used exchangeable with unified communications, is only a subset of it. It does not require real-time data transmission and is therefor only usable for asynchronous communication \citeweb{wikipedia:uc}. Unified messaging's function is basically: Receiveing incoming messages from various channels, converting it to a common format, and storeing it into a single space. The stored messages can then be accessed from different devices. \citeweb{wikipedia:um}
   4.165 -
   4.166 -The easiest way of unified messaging is to base it on either email and convert all input sources to email messages (as attachments for instance) and store them in the user's mail box. Or use the telephone system as basis and convert text messages to speech. Both is no problem for asynchronous communication.
   4.167 -
   4.168 -Finally a critical voice from Jesse Freund, who voted unified messaging on top of a hype list for \name{Wired.com}, ten years ago \cite{wired:hype}. His description of the technology ended with the humorous sentences: ``Unified messaging is a nice idea, but a tough sell: The reason you bought a cell phone, a pager, and a fax/modem is because each does its job well. No one wants to download voicemail as a series of RealAudio messages or sit through a voicemail bot spelling out email, complete with "semicolon dash end-parenthesis" for ;-).''
   4.169 -
   4.170 -
   4.171 -%todo: have a result here?
   4.172 -
   4.173 -
   4.174 -
   4.175 -
   4.176 -\section{Electronic mail}
   4.177 -
   4.178 -After viewing the whole market of electronic communication, a zoom in to the market of electronic mail follows. Email is an asynchron communication technology that transports textual information primary. This thesis is about a \mta, so the market situation for email is important. Interesting questions are: Is email future-safe? How will electronic mail change? Will it change at all? Which are the critical parts? These questions matter when deciding on the directions for further development of an \MTA. They are discussed in this section.
   4.179 -
   4.180 -
   4.181 -
   4.182 -\subsection{\NAME{SWOT} analysis}
   4.183 -
   4.184 -A \NAME{SWOT} analysis regards the strengths and weaknesses of a subject against the opportunities and threats of its market. The slightly altered form called Dialectical SWOT analysis, which is used here, is described in \cite{powerof2x2}. SWOT analysises should always focus on a specific specific goal to reach with the product. In this case, the main goal is to make email future-safe.
   4.185 -
   4.186 -The market's main threat is \emph{spam}, also named \name{junk mail} or \name{unsolicited commercial email} (\NAME{UCE}). Panda Security and Commtouch state in their \name{Email Threats Trend Report} for the second Quater of 2008: ``Spam levels throughout the second quarter averaged 77\%, ranging from a low of 64\% to a peak of 94\% of all email [...]''\cite[page 4]{panda:email-threats}. The report sees the main reason in the botnets consisting of zombie computers: ``Spam and malware levels remain high for yet another quarter, powered by the brawny yet agile networks of zombie IPs.''\cite[page 1]{panda:email-threats} This is supported by IronPort Systems: ``More than 80 percent of spam now comes from a `zombie'---an infected PC, typically in a consumer broadband network, that has been hijacked by spammers.''\cite{ironport:zombie-computers}. Positiv for MTAs is, that they are not the main source for spam, but it is only a small delight. Spam is a general weakness of the email system, because it can not prevent it.
   4.187 -
   4.188 -Opportunities of the market are large data transfers, coming from multimedia content, which becomes popular. If email is used as basis for unified messaging, lots of voice and video mail will need to be transfered. Email is weak related to that kind of data: the data needs to be encoded to \NAME{ASCII} and and stresses mail servers a lot.
   4.189 -
   4.190 -The use of various hardware to access mail is another opportunity of the market. The software and infrastructure needed to transfer mail within this network might be a weakness of the email system. %fixme: think about that
   4.191 -
   4.192 -An opportunity of the market and at the same time a strength of electronic mail is its standardization. Few other communication technologies are standardized and thus freely available in a similar way. %fixme: ref
   4.193 -Another opportunity and strength is the modular and extendable structure of electronic mail; it can easily evolve to new requirements. %fixme: ref
   4.194 -
   4.195 -The increasing integration of communication channels, is an opportunity for the market. But deciding weather it is a weakness or strength of email is not so easy. It is a weakness because the not possible integration of stream data and the not good integration of large binary data. It is also a strength, because arbitary asynchron communication data already can be integrated. On the other hand, the integration might be a threat too, because it easily leads to complexity of software. Complex software is more error prone and thus less reliable. This could be a strength of electronic mail because of its modular design that decreases complexity, but real integration is harder to do than in monolitic systems.
   4.196 -
   4.197 -Figure \ref{fig:email-swot} displays the \NAME{SWOT} analysis in a handy overview. It is easy to see, that the opportunities outweigh. This indicates a still increasing technology. %fixme: ref
   4.198 -
   4.199 -\begin{figure}
   4.200 -	\begin{center}
   4.201 -		\begin{verbatim}
   4.202 - ---------------------------------------------------
   4.203 -             |                  |                  |
   4.204 - strength    | standard         |                  |
   4.205 - of email    | modular,extendabl|                  |
   4.206 -             |                  |                  |
   4.207 - ---------------------------------------------------
   4.208 -             | big data transfer|                  |
   4.209 - weaknesses  | too big for phone|                  |
   4.210 - of email    |                  | spam             |
   4.211 -             |                  |                  |
   4.212 - ---------------------------------------------------
   4.213 -             |                  |                  |
   4.214 -             | opportunities of | threats of       |
   4.215 -             | market           | market           |
   4.216 -             |                  |                  |
   4.217 -		\end{verbatim}
   4.218 -	\end{center}
   4.219 -	\caption{SWOT analysis for email}
   4.220 -	\label{fig:email-swot}
   4.221 -\end{figure}
   4.222 -
   4.223 -The analysis shows what should be done to achieve the goal (Making email future-safe). Spam mail should be reduced as good as possible. Solutions for large data transfers and infrastructures with more nodes moving within the net should be developed, there is a lot of potential. Standardization, modularity and extendability should be used to go even further, these are the key advantages of email.
   4.224 -%fixme: a bit more concrete, see description of swot analysis
   4.225 -
   4.226 -
   4.227 -
   4.228 -\subsubsection*{Differences in \freesw}
   4.229 -%fixme: where to put this comment ... appears to be relevant
   4.230 -<< what consumers choose >>
   4.231 -%todo: is it _really_ important?
   4.232 -
   4.233 -
   4.234 -
   4.235 -
   4.236 -
   4.237 -\subsection{Trends for electronic mail}
   4.238 -
   4.239 -Trends and possible trend, or just plans to think about, are presented now.
   4.240 -%Emailing in future will not be the same as emailing today. This will mainly affect how email is transfered.
   4.241 -
   4.242 -
   4.243 -\subsubsection*{Provider independence}
   4.244 -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}),
   4.245 -%fixme: check for non-breakable dash
   4.246 -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.
   4.247 -
   4.248 -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.
   4.249 -
   4.250 -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.
   4.251 -
   4.252 -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.
   4.253 -
   4.254 -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.
   4.255 -
   4.256 -
   4.257 -\subsubsection*{Pushing versus polling}
   4.258 -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.
   4.259 -
   4.260 -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.
   4.261 -
   4.262 -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.
   4.263 -%FIXME: add reference to push email
   4.264 -
   4.265 -
   4.266 -\subsubsection*{Internet Mail 2000}
   4.267 -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.
   4.268 -
   4.269 -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.
   4.270 -
   4.271 -\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}.
   4.272 -%FIXME: add references for IM2000
   4.273 -
   4.274 -
   4.275 -
   4.276 -
   4.277 -
   4.278 -\subsection{Future-safety of email}
   4.279 -%fixme: rework
   4.280 -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.
   4.281 -
   4.282 -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.
   4.283 -
   4.284 -
   4.285 -
   4.286 -
   4.287 -
   4.288 -\section{What will be important}
   4.289 -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. Because as the fields and kinds of usage change, the requirement change too.
   4.290 -
   4.291 -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 and water supply systems. Or configuration needs to be easy and fool-prove, to be done by the owner himself. The latter solution depends on standardized parts that fit together seamlessly. The technology must not be a problem itself. Only settings custom to the users environment should be left open for him to set. This of course needs to be doable using a simple configuration interface like a web interface. Non-technical educated users should be able to configure the system.
   4.292 -
   4.293 -\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.
   4.294 -
   4.295 -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
   4.296 -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.\ graphical programs, websites, command line programs; all of them either in a questionaire style or iteractive).
   4.297 -
   4.298 -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 large amounts of mail in short time. Home servers or workstations however, do not see that much mail; they need to handle only tens or hundreds of email messages per hour. Thus performance will probably not be a main requirement for an \MTA\ in future, if they mainly run on private machines.
   4.299 -
   4.300 -\name{postfix} focuses much on performance, this might not be an important point then.
   4.301 -
   4.302 -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 the flexibility of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}).
   4.303 -
   4.304 -Another important requirement for all kinds of software will be security. There is a constant trend coming from completely non-secured software, in 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 be even more important in the next years. As more clients get connected to the Internet and especially more computers are listening for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing of software systems will be done with increasing effort in future.
   4.305 -
   4.306 -``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-\NAME{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.
   4.307 -
   4.308 -Secure and robust software is a pre-requisite for such boxes to make that vision possible.
   4.309 -
   4.310 -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.
   4.311 -
   4.312 -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.
   4.313 -
   4.314 -
   4.315 -

     5.1 --- a/thesis/thesis.tex	Wed Nov 26 22:08:55 2008 +0100
     5.2 +++ b/thesis/thesis.tex	Wed Nov 26 22:11:08 2008 +0100
     5.3 @@ -28,8 +28,8 @@
     5.4  \pagenumbering{arabic}
     5.5  
     5.6  \include{tex/1-Introduction}
     5.7 -\include{tex/3-MarketAnalysis}
     5.8 -\include{tex/2-MailTransferAgents}
     5.9 +\include{tex/2-MarketAnalysis}
    5.10 +\include{tex/3-MailTransferAgents}
    5.11  \include{tex/4-MasqmailsFuture}
    5.12  \include{tex/5-Improvements}
    5.13  \include{tex/6-Release}