1.1 --- a/thesis/pieces/future-communication.tex	Wed Nov 12 18:02:39 2008 +0100
     1.2 +++ b/thesis/pieces/future-communication.tex	Wed Nov 12 18:03:36 2008 +0100
     1.3 @@ -1,8 +1,10 @@
     1.4  \chapter{The future of communication}
     1.5 +\label{chap:future-of-communication}
     1.6  As globalization proceeds, long distance communication becomes more and more important. This chapter tries to locate trends in communication methods and their impact on the future for communication. The insights gathered from the analysis will be applied to \masqmail, afterwards.
     1.7  
     1.8  
     1.9  \section{Communication methods}
    1.10 +\label{sec:communication-methods}
    1.11  Today's long distance communication methods are either written or spoken information. And on the other side, they can be classified by the time between responses.
    1.12  
    1.13  A classification of long distance communication methods is shown in figure %\ref{fig:}.
    1.14 @@ -27,13 +29,11 @@
    1.15  
    1.16  It seems as if in future will be low-cost communication methods available, which will be digitally transmitted.
    1.17  
    1.18 -
    1.19  \subsection{Variety}
    1.20  Regarding the variety of communication methods shows a change, too. Communication systems are more easy to establish today, so more get established. This leads to more methods a person uses. But not only in the amount, also in parallel. For example when two people talk to each other on the phone, one might send a URI\footnote{Uniform Resource Identifier} by email meanwhile, because oral communication is not well suited to exchange such data. Another example for in parallel used communication channels is video chatting. Ony typically sees the other person, talks to it, and additionally has a instant messaging facility for exchanging written information.
    1.21  
    1.22  Parallel usage of different kinds of communication channels will be important in future. The most common combinations are one for spoken and one for written information. But one for dialogs and one for sending documents will be important too.
    1.23  
    1.24 -
    1.25  \subsection{Hardware}
    1.26  Next about the hardware needed for communicating. On the one side stands the telephone, now available as the mobile phone. It provides spoken dialog by calling, spoken messages with the included answering machine and written messages in form of short message service. On the other side stands the letter and its relatives. They need pen and paper, a telefax machine or in most today's cases a computer. They typically send documents, only instant messaging is focused on dialog.
    1.27  
    1.28 @@ -46,6 +46,7 @@
    1.29  
    1.30  
    1.31  \section{Trends for electronic mail}
    1.32 +\label{sec:email-trends}
    1.33  The previous section stated that electronic mail will still be important in future to complete the communication methods provided by phone and instant messaging.
    1.34  
    1.35  But will emailing in future not be the same as emailing now. This will mainly affect how email is transfered.
    1.36 @@ -62,13 +63,11 @@
    1.37  
    1.38  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.
    1.39  
    1.40 -
    1.41  \subsection{Is email future-safe?}
    1.42  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.
    1.43  
    1.44  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.
    1.45  
    1.46 -
    1.47  \subsection{Pushing versus polling}
    1.48  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.
    1.49  
    1.50 @@ -77,7 +76,6 @@
    1.51  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.
    1.52  %FIXME: add reference to push email
    1.53  
    1.54 -
    1.55  \subsection{Internet Mail 2000}
    1.56  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.
    1.57  
    1.58 @@ -85,18 +83,48 @@
    1.59  
    1.60  \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}.
    1.61  
    1.62 -
    1.63 +%FIXME: add references for IM2000
    1.64  
    1.65  
    1.66  \section{What will be important}
    1.67 -%which MTA has a good position
    1.68 +\label{sec:important-for-mtas}
    1.69 +Now that it is explained why email will survive (in some changed but related form), it is time to think about the properties required for \mta{}s in the next years. As the fields and kinds of usage change, the requirement change too.
    1.70 +
    1.71 +Provider independence through running an own mail server at home asks for easy configuration of the \MTA. Providers have specialists to configure the systems, but ordinary people do not. Solutions are either having some home service system for computer configuration established with specialists coming to one's home to set up the systems; like it is already common for problems with the power supply or water supply system. Or configuration needs to be easy and fool-prove, to be done by the owner himself. The latter solution depends on standardized parts that fit together seamlessly. The technology itself must not be a problem itself. Only settings custom to the users environment should be left open for him to set. This of course needs to be doable on a simple configuration interface like a web interface; non-technical educated users should be able to configure the system.
    1.72 +
    1.73 +\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.
    1.74 +
    1.75 +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
    1.76 +It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ a graphical program, a website, a command line program; all of them either in a questionaire style or iteractive).
    1.77 +
    1.78 +When \MTA{}s become popular on home servers and maybe even on workstations and smart phones, then performance will be less important. Providers need \mta{}s that process a large amount of mail in short time. Home servers or workstations however, do not see that much mail; they need to handle tens or hundrets of email messages per hour. Thus performance will probably not be a main requirement for an \MTA\ in the future, if they mainly run on private machines.
    1.79 +
    1.80 +\name{postfix} focuses much on performance, this might not be an important point then.
    1.81 +
    1.82 +New mailing concepts and architectures like push email or \name{Internet Mail 2000} will, if they succeed, require \mta{}s to adopt the new technology. \MTA{}s that are not able to change are going to be sorted out by evolution. Thus it is important to not focus too much on one use case, but to stay flexible. Allman saw this property of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}).
    1.83 +
    1.84 +Another important requirement for all kinds of software will be security. There is a constant trend going from completely non-secured software from the 70s and 80s over growing security awareness in the 90s to security being a primary goal now. This leads to the conclusion that software security will even more important in the next years. As more clients get connected to the internet and especially more computers are waiting for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing software systems will be done with increasing effort in future.
    1.85 +
    1.86 +``Plug-and-play''-able hardware with preconfigured software running can be expected to become popular. Like someone buys a set-top box to watch Pay-TV today, he might be buying a box acting as mail server in a few years. He plugs the power cable in, inserts his email address in a web interface and selects the clients (workstation computers or smart phones) to which mail should be send and from which mail is accepted to receive. That's all. It would just work then, like everyone expects it from a set-top box today.
    1.87 +
    1.88 +Containing secure and robust software is a pre-requisite for such boxes to make that vision possible.
    1.89 +
    1.90 +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.
    1.91 +
    1.92 +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.
    1.93  
    1.94  
    1.95  \section{\masqmail\ in five years}
    1.96 +\label{sec:masqmail-in-5-years}
    1.97 +Now how could \masqmail\ be like in, say, five years?
    1.98  %requirements
    1.99  %which parts to do
   1.100  %how to make masqmail future-safe
   1.101  
   1.102 +%how to advertise masqmail
   1.103 +%difference for free software
   1.104 +%why is it worth to revive masqmail?
   1.105 +
   1.106  
   1.107  \section{How would \masqmail\ be designed now}
   1.108  %what would be needed