docs/diploma

changeset 213:9f30e6625164

lots of rework in chapter 2
author meillo@marmaro.de
date Sun, 04 Jan 2009 17:55:21 +0100
parents bbbaf7b328f8
children 89967bc9c29e
files thesis/tex/2-MarketAnalysis.tex
diffstat 1 files changed, 67 insertions(+), 53 deletions(-) [+]
line diff
     1.1 --- a/thesis/tex/2-MarketAnalysis.tex	Sun Jan 04 11:22:21 2009 +0100
     1.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Sun Jan 04 17:55:21 2009 +0100
     1.3 @@ -1,7 +1,7 @@
     1.4  \chapter{Market analysis}
     1.5  \label{chap:market-analysis}
     1.6  
     1.7 -This chapter analyzes 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.
     1.8 +This chapter analyzes 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 for email are located and trends are identified. The insights of these analysis result in a summary of things that are important for developing future-prove email software.
     1.9  
    1.10  
    1.11  
    1.12 @@ -21,8 +21,7 @@
    1.13  
    1.14  Another possible separation is to distinguished written and recorded information. Recorded information, like audio or video data, is accessible only in a linear way by spooling and replay. Written information, on the other hand, can be accessed in arbitrary sequence, detail and speed.
    1.15  
    1.16 -\person{Lenke} and \person{Schmitz} \cite{lenke95} use the same criteria to classify \emph{new media}. %fixme: is this term common?
    1.17 -They additionally divide into local and remote communication---the latter is presumed here---and by the number of communication participants. As communication technologies for n:m communication (like chat rooms) are usable for 1:1 too (private chat), and ones for 1:1 (email) are usable for n:m (mailing lists), a classification by participant structures is omitted here.
    1.18 +\person{Lenke} and \person{Schmitz} \cite{lenke95} use the same criteria to classify \emph{new media}. They additionally divide into local and remote communication---the latter is presumed here---and by the number of communication participants. As communication technologies for n:m communication (like chat rooms) are usable for 1:1 too (private chat), and ones for 1:1 (email) are usable for n:m (mailing lists), a classification by participant structures is omitted here.
    1.19  
    1.20  Figure \ref{fig:comm-classification} shows a classification of communication technologies sorted by the properties synchronous/asynchronous and written/recorded. Email and \NAME{SMS} are written and asynchronous communication; \NAME{IM} and chats are written information too, but synchronous. Recorded information are voice mail and video messages as examples for asynchronous communication. VoIP is an example for synchronous communication.
    1.21  
    1.22 @@ -107,7 +106,6 @@
    1.23  Finally a critical voice from Jesse \person{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 voice mail as a series of RealAudio messages or sit through a voice mail bot spelling out email, complete with `semicolon dash end-parenthesis' for ;-).''
    1.24  
    1.25  
    1.26 -%todo: have a result here?
    1.27  
    1.28  
    1.29  
    1.30 @@ -126,8 +124,15 @@
    1.31  The two dimension---a subject and the market---are regarded in relation to each other by the analysis. Here the analysis shall be driven by the market's dimension. Thus first opportunities of the market are identified and split into being stengths or weaknesses of email. Then the same is done for threats of the market.
    1.32  
    1.33  \subsubsection*{Threats}
    1.34 +The market's main threat is \emph{spam}, also named \name{junk mail} or \name{unsolicited commercial email} (\NAME{UCE}). David~A.\ \person{Wheeler} is clear about it:
    1.35 +\begin{quote}
    1.36 +Since \emph{receivers} pay the bulk of the costs for spam (including most obviously their time to delete all that incoming spam), spam use will continue to rise until effective technical and legal countermeasures are deployed, \emph{or} until people can no longer use email.
    1.37 +\cite{wheeler03}
    1.38 +\end{quote}
    1.39 +The amount of spam is huge. Panda Security and Commtouch state in their \name{Email Threats Trend Report} for the second Quarter 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 bot nets consisting of zombie computers: ``Spam and malware levels remain high for yet another quarter, powered by the brawny yet agile networks of zombie \NAME{IP}s.''\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 \NAME{PC}, typically in a consumer broadband network, that has been hijacked by spammers.''\cite{ironport:zombie-computers}. Positive for \MTA{}s 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.
    1.40  
    1.41 -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 Quarter 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 bot nets consisting of zombie computers: ``Spam and malware levels remain high for yet another quarter, powered by the brawny yet agile networks of zombie \NAME{IP}s.''\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 \NAME{PC}, typically in a consumer broadband network, that has been hijacked by spammers.''\cite{ironport:zombie-computers}. Positive for \MTA{}s 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.
    1.42 +
    1.43 +
    1.44  
    1.45  
    1.46  \subsubsection*{Opportunities}
    1.47 @@ -151,11 +156,11 @@
    1.48  	\label{fig:email-swot}
    1.49  \end{figure}
    1.50  
    1.51 -\subsubsection*{Conclusion}
    1.52 +\subsubsection*{Resulting strategies}
    1.53  
    1.54  The result of a \NAME{SWOT} analysis are strategies to react on the identified opportunities and threats, dependent on whether they are strengths or weaknesses of the subject. These strategies are what should be done to achieve the overall goal---here making email future-safe.
    1.55  
    1.56 -Threats of the market that are weaknesses of the subject should be avoided if possible, or one should prepare against them if they are impossible to avoid. As spam is unavoidable, email must prepare against them. The goal is to reduce spam to a bearable level. Spam fighting is a war where the good guys tend to lose. Putting too much effort there will result in few gain. Hence sufficient spam protection should be provided, but not more.
    1.57 +Threats of the market that are weaknesses of the subject should be avoided if possible, or one should prepare against them if they are impossible to avoid. As spam is unavoidable, email must prepare against them. The goal is to reduce spam to a bearable level. Spam fighting, with currently used protocols, is a war where the good guys must lose. Investing high effort will result in few gain. Hence sufficient spam protection should be provided, but not more. New concepts and protocols will change this fight; they must be in use before email has become unusable.
    1.58  
    1.59  Threats that are strengths of the subject should be confronted. Here non were identified.
    1.60  
    1.61 @@ -169,77 +174,56 @@
    1.62  
    1.63  \subsection{Trends for electronic mail}
    1.64  
    1.65 -Trends and possible trend, or just plans to think about, are presented now.
    1.66 -%Emailing in future will not be the same as emailing today. This will mainly affect how email is transfered.
    1.67 +Noting remains the same, so does the email technology not. Emailing in future will probably differ from emailing today. This section tries to identify possible trends affecting the future of electronic mail.
    1.68  
    1.69  
    1.70  \subsubsection*{Provider independence}
    1.71 -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\mbox{-}On\-line}),
    1.72 -%fixme: check for non-breakable dash
    1.73 -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.
    1.74 +Today's email structure is heavily dependent on email providers. This means, most people have email addresses from some provider. These can be providers that offer email accounts in addition to their regular services, for example online connections. \NAME{AOL} and \name{T\mbox{-}On\-line} for instance do so. Or specialized email providers that commonly offer freemail as well as enhanced mail services, one must pay for. Examples for email providers are \NAME{GMX}, \name{Yahoo}, and \name{Hotmail}.  %fixme: check for non-breakable dash
    1.75  
    1.76 -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.
    1.77 +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 using the \name{mail user agent}. This means all mail sending and receiving work is done by the provider.
    1.78  
    1.79 -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.
    1.80 +The reason therefor is originated in the time when people used dial-up connections to the Internet. A mail server needs to be online to receive email. Sending mail is no problem, but receiving it is hardly possible with an \MTA\ being few time online. Internet service providers had servers running all day long connected to the Internet. So they offered email service, and they still do.
    1.81  
    1.82 -Home servers become popular in these days, for central data storage and multimedia 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 as well.
    1.83 +Nowadays, dial-up Internet access became rare; the majority has broadband Internet access paying a flat rate for it. Hence the time being online not affect costs anymore, even traffic is unlimited. Today it is possible to have an own mail server running at home. The technical problem remaining is the changing \NAME{IP} addresses one gets assigned every 24 hours. But this is solvable with one of the dynamic \NAME{DNS} services; they provide the mapping of a fixed domain name to the changing \NAME{IP} addresses.
    1.84  
    1.85 -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.86 +Home servers become popular for central data storage and multimedia services, these days. Being assembled of energy efficient elements, power consumption is no big problem anymore. These home servers will replace video recorders and \NAME{CD} music collections in the near future. It is also realistic that they will manage heating systems and intercoms too. Given the future leads to this direction, it is a logical step to have email and other communication provided by the own home server as well.
    1.87 +
    1.88 +After \mta{}s have not been popular for users in the last years, the next years might bring them back to the users. Maybe in a few years nearly everyone will have one running at home.
    1.89  
    1.90  
    1.91  \subsubsection*{Pushing versus polling}
    1.92 -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.93 +The retrieval of email is a field that is about to change these days. The old way is to fetch email by polling the server that holds the personal mail box. This polling is normally 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 user 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.94  
    1.95 -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 works 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.
    1.96 +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 smart phones; they were able to do emailing, but the traffic caused by polling the server was expensive.
    1.97  
    1.98 -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.99 +The concept works well with mobile phones where the provider knows about the client, but it does not to be a choice for computers since the provider needs to have some kind of login to push data to the user's computer. Push email, 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 own workstations and smart phones. The configuration could be done by the user using some simple interface, like one configures his telephone system to have different telephone numbers ringing on specified phones.
   1.100  %FIXME: add reference to push email
   1.101  
   1.102 +Another problem is multiple clients sharing one mail box. This is only solvable by working directly in the server's mail box, which causes lots of traffic, or by storing at least information about read messages and thelike there.
   1.103  
   1.104 -\subsubsection*{New email protocols}
   1.105  
   1.106 -Another concept to redesign the electronic mail system, but this time focused on mail transfer is named ``Internet Mail 2000''. It was proposed by \person{Daniel~J.\ }{Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others too.
   1.107 +\subsubsection*{New email concepts}
   1.108  
   1.109 -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 transferred from the sender to the receiver.
   1.110 -
   1.111 -\name{Mail transfer agent}s are still important in this mail architecture, but in a slightly different way. Their job is not transferring mail anymore---this makes the name misleading---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.112 +Changing requirements for email communication lead to the need for new concepts and new protocols that cover these requirements. One of these concepts to redesign the electronic mail system is named ``Internet Mail 2000''. It was proposed by Daniel~J.\ \person{Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others too.
   1.113  %FIXME: add references for IM2000
   1.114  
   1.115 +As main change, the sender has the responsibility for mail storage; only a notification about a mail message gets send to the recipient. He 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 transferred from the sender to the receiver (called \name{store-and-forward}).
   1.116  
   1.117 ----
   1.118 +\name{Mail transfer agent}s are still important in this new email architecture, but in a slightly different way. They do not transferring mail itself anymore, but they 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 an arbitrary way, for example via \NAME{FTP} or \NAME{SCP}.
   1.119  
   1.120 +A second concept, this one primary to arm against spam, is David~A.\ \person{Wheeler}'s \name{Guarded Email}, described in \cite{wheeler03}. It requires messages to be recognized as Ham (non-spam) to be accepted, otherwise a challenge-response authentication will be initiated.
   1.121  
   1.122 -%add ``guarded email'' by dwheeler
   1.123 -\begin{quote}
   1.124 -Since receivers pay the bulk of the costs for spam (including most obviously their time to delete all that incoming spam), spam use will continue to rise until effective technical and legal countermeasures are deployed, or until people can no longer use email.
   1.125 -\url{http://www.dwheeler.com/guarded-email/guarded-email.html}
   1.126 -\end{quote}
   1.127 +\name{Hashcash} by Adam \person{Back}---a third concept---tries to limit spam and denial of service attacks \cite{back02}. It requests payment for mail to get accepted. The costs are computing time for generating hash values. Thus sending spam becomes expensive. More information can be found on \citeweb{hashcash:homepage}.
   1.128  
   1.129 +New concepts, like the ones presented here, are invented to remove problems of the email technology. Internet Mail 2000, for instance, removes the spam and large message transfer problems.
   1.130  
   1.131 -%maybe add a third one
   1.132  
   1.133 -<< hashcash >>
   1.134  
   1.135  
   1.136 -\subsection{Future-safety of email}
   1.137 -%fixme: rework
   1.138 -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 applies 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.139  
   1.140 -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.141  
   1.142 -\subsubsection*{Unified Communication}
   1.143 -Integration of asynchonous with synchronous communication channels is what Unified Communication is about. It seems not be possible to merge the two worlds on basis of email in an evolutionary way. As only a revolutionary change of the whole email concept would make it possible, it is best to ignore it. New designed technologies are usually superior to heavily patched and bent old technologies anyway. A general merge of synchronous and asynchronous communication has good chances to be fatal for email.
   1.144 -
   1.145 -Until Unified Communication will become reality---if ever---electronic mail has a good position, also as basis for Unified Messaging.
   1.146 -
   1.147 -
   1.148 -
   1.149 -
   1.150 -\section{Result}
   1.151 +\subsection{Importances in future}
   1.152  \label{sec:what-will-be-important}
   1.153 -%fixme: this is the RESULT! Write it as such.
   1.154 -
   1.155 -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.156  
   1.157  Provider independence through running an own mail server at home asks for easy configuration of the \MTA. Providers have specialists to configure the systems, but ordinary people do not. Solutions are either having some home service system for computer configuration established with specialists coming to ones home to set up the systems; like it is already common for problems with the power and water supply systems. Or configuration needs to be easy and fool-prove, to be done by the owner himself. The latter solution depends on standardized parts that fit together seamlessly. The technology must not be a problem itself. Only settings custom to the users environment should be left open for him to set. This of course needs to be doable using a simple configuration interface like a web interface. Non-technical educated users should be able to configure the system.
   1.158  
   1.159 @@ -253,15 +237,45 @@
   1.160  
   1.161  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.162  
   1.163 -``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.164 +``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. Secure and robust software is a pre-requisite for such boxes to make that vision possible.
   1.165  
   1.166 -Secure and robust software is a pre-requisite for such boxes to make that vision possible.
   1.167 -
   1.168 -It seems as if all widely used \mta{}s provide good security nowadays. The modular architecture is generally seen to be conceptually more secure, however.
   1.169  
   1.170  In summary: Easy configuration, as well 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.171  
   1.172  
   1.173  
   1.174  
   1.175 -% Chapter \ref{chap:market-analysis} dealt with this topic. The trends for the communication market were consolidation, integration and a merge of communication hardware. All this goes along with market's change to Unified Messaging and later Unified Communication. Electronic mail appears to have good chances to stay an important transport technology then: It can transport all kinds of asynchronous messages and email usage from desktop computers and mobile devices is already established. Hence electronic mail is ready for Unified Messaging. Unified Communication, however, requires more, including the integration of synchronous communication channels with asynchronous ones. This is a point where email does bad. The \emph{store-and-forward} transport architecture of email is not suited for synchronous data transfer. Until, if ever, Unified Communications becomes reality, email is a winner.
   1.176 +
   1.177 +
   1.178 +
   1.179 +
   1.180 +\section{Conclusion}
   1.181 +It seems as if electronic mail or a similar technology has good chances to survive the next decades.
   1.182 +
   1.183 +It is assumed that it always will be important to send information messages. Those can be notes from people or notifications from systems. No other, current available, communication technology is as suitable for this kind of information transfer, as email, \NAME{SMS}, voice mail, and other asynchronous communication technologies. Synchronous communication, in contrast, is focused on dialog and normally interrupts people. The here needed kind of messages should not interrupt people, unless urgent, and they do not need two-way information exchange. Although synchronous communication could be used for tansfering messages, it is not the best choice. The best choice is an asynchronous technology. Thus at least one asynchronous communication technology is likely to survive.
   1.184 +
   1.185 +Whether email will be the surviving one, is not possible to know by now. It currently seems likely that \name{unified messaging} will be the future for asynchronous communication. But Unified Messaging is more a concept than a technology itself. This concept will base upon one or many underlying transport technologies, like email, \NAME{SMS}, and the like. Its goal is to integrate the transport technologies in order to hide them from the user's view. Currently, email is the most used asynchronous electronic communication technology. It is matured, flexible, and extendable, as well as standardized. These advantages make email a good base transport technology for Unified Messaging. Anyhow, whether email will be the basis for Unified Messaging or not---\MTA{}s are a software needed for all asynchronous communication methods: programs that transfer messages from senders to destinations. Thus, their future is bright.
   1.186 +
   1.187 +%The trends in the communication market are consolidation, integration, and the merge of communication hardware. All this goes along with market's change to Unified Messaging.
   1.188 +
   1.189 +Unified Communication, as next step after Unified Messaging, is about the integration of asynchonous an synchronous communication channels. It seems impossible to merge the two worlds on basis of email in an evolutionary way. As only a revolutionary change of the whole email concept would make that merge possible, it is best to ignore it. New designed technologies are usually superior to heavily patched and bent old technologies, anyway. A general merge of synchronous and asynchronous communication has good chances to be fatal for email.
   1.190 +
   1.191 +Until Unified Communication will become reality---if ever---electronic mail has a good position, also as basis for Unified Messaging.
   1.192 +
   1.193 +
   1.194 +Not only the market influences email's future safety, but also must the email technology itself do its part in evolving to satisfy upcoming needs. Actions to take were discovered by using the \NAME{SWOT} analysis. These are: Prepare against spam. Search solutions for large data transfers and increasing growth and ramification of networks. Exploit standardization, modularity, and extendability.
   1.195 +
   1.196 +Also needed is awareness for new trends like: Provider independence, new delivery concepts, and completely new emailing concepts, introducing new protocols. Easy configuration will also be important, security will be essentiel.
   1.197 +
   1.198 +
   1.199 +What kinds of \MTA{}s will be needed in future? Probably ones running on home servers and workstations. This is what \masqmail\ was designed for. But the dial-up Internet connections, which are central to \masqmail's design, become rare. But mobile clients that move between differnt networks, do need relaying over different locations, dependent on external influences, too. This makes \masqmail\ still be a good \MTA\ for various situations. \masqmail\ is additionally small and it is much easier to configure for situations that are common to workstations and home servers, than other \MTA{}s. Thus \masqmail\ is generally a good program to have for several setups. These setups were quite common some years ago, but are rare now. The trends expected for the next years will lead to new situations where \masqmail\ will be a valuable \MTA.
   1.200 +
   1.201 +
   1.202 +
   1.203 +
   1.204 +
   1.205 +
   1.206 +% what about dial-up and other masqmail stuff?
   1.207 +% how good is masqmail suited?
   1.208 +% how large is the niche?
   1.209 +% is it growing?