docs/diploma: thesis/tex/4-MasqmailsFuture.tex comparison

comparison thesis/tex/4-MasqmailsFuture.tex @ 187:7f4d97584a6f

wrote about work to do

author	meillo@marmaro.de
date	Mon, 29 Dec 2008 20:16:58 +0100
parents	1611abd5443b
children	afb72fb64962

comparison

equal deleted inserted replaced

-:84d27c22517c
+:7f4d97584a6f
 \section{Work to do}
-What exists, what is missing, what needs to be done?
+After \masqmail's features were presented in section \ref{sec:fixme} and the requirements for modern \mta{}s were identified in section \ref{sec:fixme}, here the differences between them are shown.
-auth, enc, archiving
-\masqmail\ is already able to encrypt outgoing connections, but encryption of incoming connections, using \NAME{STARTTLS} should be implemented. This only affects the \SMTP\ server module.
+\subsubsection*{Fulfilled requirements}
+\masqmail's incoming and outgoing channels are the common ones: the \texttt{sendmail} command and \SMTP\ for incoming mail; local delivery, piping to commands, and \SMTP\ for outgoing mail. Support for other protocols is not available. To add it, modifications at many places in the source are needed.
+One single mail queue is used in \masqmail. The envelope and mail headers are generated when the mail is put into the queue. Aliasing is done on delivery, after the route to be used was determined. Headers may be rewritten then. These parts do all provide the functionality required.
+Static authentication, based on \NAME{IP} addresses, can be set up using the \path{hosts.allow} and \path{hosts.deny} files. Dynamic authentication is supported in form of \NAME{SMTP-AUTH} and \SMTP-after-\NAME{POP}, but only for outgoing connections. The same for encryption which is also only available for outgoing \SMTP\ connections; here a wrapper application like \name{openssl} needs to be used. Support for authentication and encryption of incoming connections is completely missing, but a basic requirement for all secure emailing.
+\masqmail\ does not provide special support for spam filter or content checking. But it is possible to invoke external filter applications by running two independent instances of \masqmail, connected by the filter application. The receiving \MTA\ instance accepts mail and pushes it into the filter. The filter application receives mail, processes it, possible modifies it, and pushes it over to a second \MTA\ instance. The second \MTA\ is responsible for further delivery of the mail. Appendix \ref{app:FIXME} shows configuration files to create such a setup. This is a concept that works in general. However, real spam \emph{prevention}---to not accept spam mail at all---or good filter interfaces are not available, but are nessesary for using \masqmail\ in an unsafe environment.
+There is currently no way of archiving every message going through \masqmail.
+%fixme: write about non-functional requirements
+\subsubsection*{Missing parts}
+Support for other protocols than \SMTP\ seems not to be nessesary at the moment. Adding such support will need lots of work in all parts of \masqmail, hence delaying it until the support is needed appears to be the best solution.
+Authentication of incoming \SMTP\ connections is definately needed and should be added soon. The same applies to encryption of incomming connections. These two features are essential for restricting relaying and providing privacy.
+As authentication can be a guard against spam, filter facilities have lower priority. But basic spam filtering and interfaces for external tools should be implemented in future. Content checking, if really nessesary, should be left over to the \NAME{MDA}, to deal with it in local delivery.
+Archiving again is prefered to be implemented soon. It does not require much work, but enables all kinds of statistical analysis. Also it is a requirement for companies to archive their mail communication.
+%fixme: what about non-functional requirements?
 \subsubsection*{Discussion on architecture}
+%fixme: why is there a need for a new arch??
 A program's architecture is probably the most influencing design decision, and has the greatest impact on the program's future capabilities. %fixme: search quote ... check if good
 \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.
 \person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
 All this leads to one logical step: The rewrite of \masqmail\ using a modern, modular architecture, to get a modern \MTA\ satisfying nowadays needs.
-\subsubsection*{A design from scratch?}
 << what would be needed (effort) >>
 The next section is a design
-\section{Directions to go}
+\section{Result}
+Directions to go
 Now how could \masqmail\ be like in, say, five years?
 This section discusses about what shapes \masqmail\ could have---which directions the development could go to.

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 187:7f4d97584a6f