1.1 --- a/thesis/tex/3-MarketAnalysis.tex	Wed Nov 26 09:51:53 2008 +0100
     1.2 +++ b/thesis/tex/3-MarketAnalysis.tex	Wed Nov 26 09:52:24 2008 +0100
     1.3 @@ -270,31 +270,30 @@
     1.4  
     1.5  
     1.6  \section{What will be important}
     1.7 -\label{sec:important-for-mtas}
     1.8 -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.9 +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.
    1.10  
    1.11 -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.12 +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.
    1.13  
    1.14  \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.15  
    1.16  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.17 -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.18 +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).
    1.19  
    1.20 -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.21 +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.
    1.22  
    1.23  \name{postfix} focuses much on performance, this might not be an important point then.
    1.24  
    1.25 -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.26 +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}).
    1.27  
    1.28 -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.29 +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.
    1.30  
    1.31  ``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.
    1.32  
    1.33 -Containing secure and robust software is a pre-requisite for such boxes to make that vision possible.
    1.34 +Secure and robust software is a pre-requisite for such boxes to make that vision possible.
    1.35  
    1.36  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.37  
    1.38 -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.39 +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.40  
    1.41  
    1.42