1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Mon Dec 15 16:59:01 2008 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Mon Dec 15 19:15:46 2008 +0100
     1.3 @@ -37,29 +37,52 @@
     1.4  
     1.5  
     1.6  
     1.7 +
     1.8 +\section{Requirements}
     1.9 +
    1.10 +Following is a list of current and future requirements to make \masqmail\ ready for the future.
    1.11 +
    1.12 +
    1.13 +\subsubsection*{Large message handling}
    1.14 +Trends in the market for electronic communication in general, wants consolidated communication, hence email will be used more and more to transfer voice and video messages, leading to large messages, putting load on \mta{}s.
    1.15 +
    1.16 +
    1.17 +\subsubsection*{Integrated communication}
    1.18 +Integration of asynchonous email with synchronous channels seems not be possible in an evolutionary way. As only a revolutionary change of the whole email concept could enable it, it is best to focus on it. A new designed technology will be supperior to a heavily patched and bent email technology.
    1.19 +
    1.20 +
    1.21 +\subsubsection*{Ressource friendly software}
    1.22 +The merge of communication hardware and the move of email service from providers to homes, demands smaller and more resource-friendly \MTA{}s. The amount of mail will be lower, even if much more mail will be sent. More important will be the energy consumption and heat emission. These topics increased in relevance during the last years and they are expected to become more central. \masqmail\ is not a program to be used on large servers, but to be used on small devices. Thus focusing on energy and heat, not on performance, is the direction to go.
    1.23 +
    1.24 +
    1.25 +\subsubsection*{New mail transfer protocols}
    1.26 +But large data transfers are something to cover. The store-and-forward transport of email is not good suited for large data. Thus new protocols, like \NAME{QMTP} (described in section \ref{}), may become popular. \masqmail\ should be able to operate on them as it becomes neccesary.
    1.27 +
    1.28 +As spam is a problem and the need for a final solution grows, \masqmail\ should be ready to support new protocols when they appear.
    1.29 +
    1.30 +protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transferred. \sendmail's initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.
    1.31 +
    1.32 +
    1.33 +\subsubsection*{Spam and malicious content handling}
    1.34 +Spam handling is a major threat to handle. According to the \NAME{SWOT} analysis, the goal is to reduce it to a bearable amount. Spam is a field where the the good guys tend to lose. Putting too much effort in spam handling will result in few gain. Real success will only be possible with new---better---protocols, abandonning the weak legacy technologies.
    1.35 +
    1.36 +Hence \masqmail\ should be able to provide state-of-the-art spam and virus protection, but not more. This is commonly and best done using external, specialized programs that are invoked.
    1.37 +
    1.38 +
    1.39 +\subsubsection*{Easy configuration}
    1.40 +Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common situations sould be to set with a single action from the user. Complex configuration should be possible, but easiest should be the most common form of configuration; this will be one of several standard setups.
    1.41 +
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48  \section{Directions to go}
    1.49  
    1.50 -<<  plans to get masqmail more popular again (if that is the goal) >>
    1.51 +This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
    1.52  
    1.53  
    1.54 -\subsection{\masqmail\ in five years}
    1.55 -
    1.56 -Now how could \masqmail\ be like in, say, five years?
    1.57 -
    1.58 -<< requirements >>
    1.59 -
    1.60 -<< which parts to do >>
    1.61 -
    1.62 -<< how to make masqmail future-safe >>
    1.63 -
    1.64 -<< how to advertise masqmail >>
    1.65 -
    1.66 -<< why is it worth to revive masqmail? >>
    1.67 -
    1.68 -
    1.69 -<< short term goals --- long term goals >>
    1.70 -
    1.71 -<<  concrete decisions based on results of the last 2 chapters >>
    1.72  
    1.73  
    1.74  
    1.75 @@ -68,7 +91,12 @@
    1.76  
    1.77  << architecture diagram >>
    1.78  
    1.79 -(ssl) -> msg-in (local or remote protocol handlers) -> spam-filter (and more) -> queue -> msg-out (local-delivery by MDA, or remote-protocol-handlers) -> (ssl)
    1.80 +(ssl)
    1.81 +-> msg-in (local or remote protocol handlers)
    1.82 +-> spam-filter (and more)
    1.83 +-> queue
    1.84 +-> msg-out (local-delivery by MDA, or remote-protocol-handlers)
    1.85 +(ssl)
    1.86  
    1.87  A design from scratch?
    1.88  
    1.89 @@ -78,21 +106,6 @@
    1.90  
    1.91  << should it be done? >>
    1.92  
    1.93 -
    1.94 -
    1.95 -\subsection{local mail delivery}
    1.96 -But for example delivery of mail to local users is \emph{not} what \mta{}s should care about, although most \MTA\ are able to deliver mail, and many do. (\name{mail delivery agents}, like \name{procmail} and \name{maildrop}, are the right programs for this job.)
    1.97 -
    1.98 -
    1.99 -
   1.100 -\subsection{various protocols}
   1.101 -protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transferred.\footnote{\sendmail{}'s initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.}
   1.102 -
   1.103 -
   1.104 -
   1.105 -
   1.106 -
   1.107 -
   1.108  http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command
   1.109  http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security
   1.110  http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery
   1.111 @@ -104,6 +117,8 @@
   1.112  http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning
   1.113  
   1.114  
   1.115 +\subsubsection*{local mail delivery}
   1.116 +But for example delivery of mail to local users is \emph{not} what \mta{}s should care about, although most \MTA\ are able to deliver mail, and many do. (\name{mail delivery agents}, like \name{procmail} and \name{maildrop}, are the right programs for this job.)
   1.117  
   1.118  
   1.119  
   1.120 @@ -117,8 +132,23 @@
   1.121  
   1.122  
   1.123  
   1.124 +
   1.125 +
   1.126 +
   1.127 +\subsubsection*{\masqmail\ in five years}
   1.128 +
   1.129 +Now how could \masqmail\ be like in, say, five years?
   1.130 +
   1.131 +<< plans to get masqmail more popular again (if that is the goal) >>
   1.132 +
   1.133 +<< More users >>
   1.134 +
   1.135 +
   1.136 +
   1.137 +
   1.138  \section{Work to do}
   1.139  
   1.140 +<< short term goals --- long term goals >>
   1.141 +
   1.142  << which parts to take out and do within the thesis >>
   1.143  
   1.144 -