1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/thesis/input/masqmail-arch.tex	Tue Dec 16 14:10:07 2008 +0100
     1.3 @@ -0,0 +1,16 @@
     1.4 +\begin{verbatim}
     1.5 + +-------------------------------------------------+
     1.6 + |                                                 |
     1.7 + |                                                 |
     1.8 + |                                                 |
     1.9 + |                                                 |
    1.10 + |            masqmail's architecture              |
    1.11 + |                                                 |
    1.12 + |                                                 |
    1.13 + |                                                 |
    1.14 + |                                                 |
    1.15 + |                                                 |
    1.16 + |                                                 |
    1.17 + |                                                 |
    1.18 + +-------------------------------------------------+
    1.19 +\end{verbatim}

     2.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Tue Dec 16 14:09:23 2008 +0100
     2.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Tue Dec 16 14:10:07 2008 +0100
     2.3 @@ -44,33 +44,23 @@
     2.4  
     2.5  
     2.6  \subsubsection*{Large message handling}
     2.7 -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.
     2.8 -
     2.9 -
    2.10 -\subsubsection*{Integrated communication}
    2.11 -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.
    2.12 +Trends in the market for electronic communication go towards consolidated communication, hence email will be used more to transfer voice and video messages. This leads to larger messages. 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.
    2.13  
    2.14  
    2.15  \subsubsection*{Ressource friendly software}
    2.16 -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.
    2.17 +The merge of communication hardware and the move of email services from providers to homes, demands smaller and more resource-friendly software. 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 past 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.
    2.18  
    2.19  
    2.20  \subsubsection*{New mail transfer protocols}
    2.21 -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.
    2.22 +Large messages demand more efficient transport through the net. As well is a final solution needed to defeat the spam problem. New mail transport protocols may be the only good solutions for both problems. They also can improve reliability, authentication, and verification issues. \masqmail\ should be able to support new protocols as they appear and are used.
    2.23  
    2.24 -As spam is a problem and the need for a final solution grows, \masqmail\ should be ready to support new protocols when they appear.
    2.25  
    2.26 -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}.
    2.27 -
    2.28 -
    2.29 -\subsubsection*{Spam and malicious content handling}
    2.30 -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.
    2.31 -
    2.32 -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.
    2.33 +\subsubsection*{Spam handling}
    2.34 +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.
    2.35  
    2.36  
    2.37  \subsubsection*{Easy configuration}
    2.38 -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.
    2.39 +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.
    2.40  
    2.41  
    2.42  
    2.43 @@ -85,11 +75,55 @@
    2.44  
    2.45  
    2.46  
    2.47 +\subsection{Access and Auth}
    2.48 +
    2.49 +easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
    2.50 +if dynamic remote hosts need access: some auth is needed
    2.51 +- SASL
    2.52 +- POP/IMAP: pop-before-smtp, DRAC, WHOSON
    2.53 +- TLS (certificates)
    2.54 +
    2.55 +``None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of thyour users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.'' (Dent: Postfix, page 44, ch04)
    2.56 +
    2.57 +
    2.58 +
    2.59 +postfix: after-queue-content-filter (smtp communication)
    2.60 +exim: content-scan-feature
    2.61 +sendmail: milter (tcp or unix sockets)
    2.62 +
    2.63 +checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
    2.64 +checks when mail is accepted and queued: external (amavis, spamassassin)
    2.65 +
    2.66 +anti-virus: clamav
    2.67 +
    2.68 +AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
    2.69 +internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient
    2.70 +                |                            |
    2.71 +                +----------------------------+
    2.72 +mail scanner:
    2.73 +incoming queue --> mail scanner --> outgoing queue
    2.74 +
    2.75 +mimedefang: uses milter interface with sendmail
    2.76 +
    2.77  
    2.78  
    2.79  \subsection{Architecture}
    2.80  
    2.81 -<< architecture diagram >>
    2.82 +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
    2.83 +
    2.84 +\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.
    2.85 +
    2.86 +Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure.
    2.87 +
    2.88 +\begin{figure}
    2.89 +	\begin{center}
    2.90 +		\input{input/masqmail-arch.tex}
    2.91 +	\end{center}
    2.92 +	\caption{Internal architecture of \masqmail}
    2.93 +	\label{fig:masqmail-arch}
    2.94 +\end{figure}
    2.95 +
    2.96 +
    2.97  
    2.98  (ssl)
    2.99  -> msg-in (local or remote protocol handlers)
   2.100 @@ -126,6 +160,15 @@
   2.101  
   2.102  
   2.103  
   2.104 +\subsection{spam and malicious content}
   2.105 +
   2.106 +The same for malicious content (\name{malware}) like viruses, worms, trojan horses. They are related to spam, but affect the \MTA less, as they are in the mail body.
   2.107 +
   2.108 +message body <-> envelope, header
   2.109 +
   2.110 +where to filter what
   2.111 +
   2.112 +
   2.113  
   2.114  
   2.115