1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Wed Dec 17 18:47:32 2008 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Wed Dec 17 18:48:17 2008 +0100
     1.3 @@ -60,6 +60,10 @@
     1.4  Spam is a major threat. According to the \NAME{SWOT} analysis, the goal is to reduce it to a bearable level. Spam fighting is a war are where the good guys tend to lose. Putting too much effort there will result in few gain. Real success will only be possible with new---better---protocols and abandonning the weak legacy technologies. Hence \masqmail\ should be able to provide state-of-the-art spam protection, but not more.
     1.5  
     1.6  
     1.7 +\subsubsection*{Security}
     1.8 +\MTA{}s are critical points for computer security, as they are accessable from external networks. They must be secured with high effort. Properties like high priviledge level, work load influenced from extern, work on unsafe data, and demand for reliability, increase the security needed. Unsecure and unreliable \mta{}s are of no value. \masqmail\ needs to b e secure enough for its target field of operation.
     1.9 +
    1.10 +
    1.11  \subsubsection*{Easy configuration}
    1.12  Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common setups should be configurable with single actions by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several standard setups.
    1.13  
    1.14 @@ -68,10 +72,67 @@
    1.15  
    1.16  
    1.17  
    1.18 +\section{Discussion on architecture}
    1.19  
    1.20 -\section{Directions to go}
    1.21 +A program's architecture is maybe the most influencing design decision, and has the greatest impact on the program's future capabilities. %fixme: search quote ... check if good
    1.22  
    1.23 -This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
    1.24 +\masqmail's current artitecture is monolitic like \sendmail's and \exim's. But more than the other two, is it one block of interweaved code. \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules. \exim\ has a highly structured code with many internal interfaces, like the one for supported authentication ``modules''. \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
    1.25 +
    1.26 +Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure.
    1.27 +
    1.28 +\begin{figure}
    1.29 +	\begin{center}
    1.30 +		\input{input/masqmail-arch.tex}
    1.31 +	\end{center}
    1.32 +	\caption{Internal architecture of \masqmail}
    1.33 +	\label{fig:masqmail-arch}
    1.34 +\end{figure}
    1.35 +
    1.36 +\sendmail\ improved its old architecture, for example by adding the milter interface. \exim\ was designed and is carefully maintained with a modular-like code structure in mind. \qmail\ started from scratch with a security-first approach, \postfix\ improved on it, and \name{sendmail X}/\name{MeTA1} tries to adopt the best of \qmail\ and \postfix, to completely replace the old \sendmail\ architecture. \person{Hafiz} \cite{hafiz05}. describes this evolution of \mta\ architecture very well.
    1.37 +
    1.38 +Every one of the popular \MTA{}s is more modular, or became more modular, than \masqmail. The logical step is to rewrite \masqmail\ using a modern, modular architecture to get a modern \MTA\ satisfying nowadays needs. But how is the effort of this complete rewrite compared to what is gained afterwards?
    1.39 +
    1.40 +
    1.41 +
    1.42 +
    1.43 +A secure architecture is of need.
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +(ssl)
    1.52 +-> msg-in (local or remote protocol handlers)
    1.53 +-> spam-filter (and more)
    1.54 +-> queue
    1.55 +-> msg-out (local-delivery by MDA, or remote-protocol-handlers)
    1.56 +(ssl)
    1.57 +
    1.58 +A design from scratch?
    1.59 +
    1.60 +<< what would be needed (effort) >>
    1.61 +
    1.62 +<< would one create it at all? >>
    1.63 +
    1.64 +<< should it be done? >>
    1.65 +
    1.66 +
    1.67 +http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command
    1.68 +http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security
    1.69 +http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery
    1.70 +http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format
    1.71 +http://fanf.livejournal.com/65203.html %how not to design an mta - spool file logistics
    1.72 +http://fanf.livejournal.com/65911.html %how not to design an mta -   more about log-structured MTA queues
    1.73 +http://fanf.livejournal.com/67297.html %how not to design an mta -   more log-structured MTA queues
    1.74 +http://fanf.livejournal.com/70432.html %how not to design an mta - address verification
    1.75 +http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning
    1.76 +
    1.77 +
    1.78 +\subsubsection*{local mail delivery}
    1.79 +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.80 +
    1.81  
    1.82  
    1.83  
    1.84 @@ -108,55 +169,6 @@
    1.85  
    1.86  
    1.87  
    1.88 -\subsection{Architecture}
    1.89 -
    1.90 -The programs architecture is maybe the most influencing design decision with the greatest impact on the programs further capabilities. %fixme: search quote ... check if good
    1.91 -
    1.92 -\masqmail's current artitecture is monolitic like \sendmail's and \exim's. But more than the other two, is it one block of interweaved code. \sendmail\ provides, with its \name{milter} interface, standardized connection channels to external modules. \exim\ has a highly structured code with many internal interfaces, like the one for supported authentication ``modules''. \masqmail\ has none of them.
    1.93 -
    1.94 -Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure.
    1.95 -
    1.96 -\begin{figure}
    1.97 -	\begin{center}
    1.98 -		\input{input/masqmail-arch.tex}
    1.99 -	\end{center}
   1.100 -	\caption{Internal architecture of \masqmail}
   1.101 -	\label{fig:masqmail-arch}
   1.102 -\end{figure}
   1.103 -
   1.104 -
   1.105 -
   1.106 -(ssl)
   1.107 --> msg-in (local or remote protocol handlers)
   1.108 --> spam-filter (and more)
   1.109 --> queue
   1.110 --> msg-out (local-delivery by MDA, or remote-protocol-handlers)
   1.111 -(ssl)
   1.112 -
   1.113 -A design from scratch?
   1.114 -
   1.115 -<< what would be needed (effort) >>
   1.116 -
   1.117 -<< would one create it at all? >>
   1.118 -
   1.119 -<< should it be done? >>
   1.120 -
   1.121 -http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command
   1.122 -http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security
   1.123 -http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery
   1.124 -http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format
   1.125 -http://fanf.livejournal.com/65203.html %how not to design an mta - spool file logistics
   1.126 -http://fanf.livejournal.com/65911.html %how not to design an mta -   more about log-structured MTA queues
   1.127 -http://fanf.livejournal.com/67297.html %how not to design an mta -   more log-structured MTA queues
   1.128 -http://fanf.livejournal.com/70432.html %how not to design an mta - address verification
   1.129 -http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning
   1.130 -
   1.131 -
   1.132 -\subsubsection*{local mail delivery}
   1.133 -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.134 -
   1.135 -
   1.136 -
   1.137  
   1.138  
   1.139  
   1.140 @@ -175,6 +187,10 @@
   1.141  
   1.142  
   1.143  
   1.144 +\section{Directions to go}
   1.145 +
   1.146 +This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
   1.147 +
   1.148  
   1.149  
   1.150