Mercurial > docs > diploma
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
186:84d27c22517c | 187:7f4d97584a6f |
---|---|
204 | 204 |
205 | 205 |
206 | 206 |
207 \section{Work to do} | 207 \section{Work to do} |
208 | 208 |
209 What exists, what is missing, what needs to be done? | 209 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. |
210 | 210 |
211 auth, enc, archiving | 211 |
212 | 212 |
213 \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. | 213 \subsubsection*{Fulfilled requirements} |
214 | |
215 \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. | |
216 | |
217 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. | |
218 | |
219 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. | |
220 | |
221 \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. | |
222 | |
223 There is currently no way of archiving every message going through \masqmail. | |
224 | |
225 | |
226 %fixme: write about non-functional requirements | |
227 | |
228 | |
229 | |
230 \subsubsection*{Missing parts} | |
231 | |
232 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. | |
233 | |
234 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. | |
235 | |
236 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. | |
237 | |
238 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. | |
239 | |
240 %fixme: what about non-functional requirements? | |
214 | 241 |
215 | 242 |
216 | 243 |
217 | 244 |
218 \subsubsection*{Discussion on architecture} | 245 \subsubsection*{Discussion on architecture} |
246 | |
247 %fixme: why is there a need for a new arch?? | |
248 | |
219 | 249 |
220 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 | 250 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 |
221 | 251 |
222 \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. | 252 \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. |
223 | 253 |
256 \person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05} | 286 \person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05} |
257 | 287 |
258 All this leads to one logical step: The rewrite of \masqmail\ using a modern, modular architecture, to get a modern \MTA\ satisfying nowadays needs. | 288 All this leads to one logical step: The rewrite of \masqmail\ using a modern, modular architecture, to get a modern \MTA\ satisfying nowadays needs. |
259 | 289 |
260 | 290 |
261 | |
262 \subsubsection*{A design from scratch?} | |
263 | 291 |
264 << what would be needed (effort) >> | 292 << what would be needed (effort) >> |
265 | 293 |
266 The next section is a design | 294 The next section is a design |
267 | 295 |
718 | 746 |
719 | 747 |
720 | 748 |
721 | 749 |
722 | 750 |
723 \section{Directions to go} | 751 \section{Result} |
752 | |
753 Directions to go | |
724 | 754 |
725 Now how could \masqmail\ be like in, say, five years? | 755 Now how could \masqmail\ be like in, say, five years? |
726 | 756 |
727 This section discusses about what shapes \masqmail\ could have---which directions the development could go to. | 757 This section discusses about what shapes \masqmail\ could have---which directions the development could go to. |
728 | 758 |