1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 18 13:08:32 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 18 18:33:30 2009 +0100
     1.3 @@ -220,7 +220,7 @@
     1.4  \paragraph{\RG10: Usability}
     1.5  Usability, not mentioned by \person{Hafiz} (he focuses on architecture) but by \person{Spinellis} and \person{Kan}, is a property very important from the user's point of view. Software with bad usability is rarely used, no matter how good it is. If substitutes with better usability exist, the user will switch to one of them. Here, usability includes setting up and configuring; and the term ``users'' includes administrators. Having \mta{}s on home servers and workstations requires easy and standardized configuration. The common setups should be configurable with little action by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several common setups.
     1.6  
     1.7 -<< masqmail as portable app? >>
     1.8 +%fixme: << masqmail as portable app? >>
     1.9  
    1.10  
    1.11  
    1.12 @@ -281,10 +281,7 @@
    1.13  
    1.14  
    1.15  \paragraph{\RF1: In/out channels}
    1.16 -The incoming and outgoing channels that \masqmail\ already has are the ones required for an \MTA{}s at the moment. They are depicted in figure \ref{fig:masqmail-in-out} on page \pageref{fig:masqmail-in-out}.
    1.17 -Support for other protocols seems not to be necessary at the moment, although new protocols and mailing concepts are likely to appear (see section \ref{sec:electronic-mail}).
    1.18 -Today, other protocols are not needed, so \masqmail\ is regarded to fulfill \RF1.
    1.19 -But as \masqmail\ has no support for adding further protocols, delaying the work to support them until they are widely used, appears to be the best strategy anyway.
    1.20 +The incoming and outgoing channels that \masqmail\ already has (depicted in figure \ref{fig:masqmail-channels} on page \pageref{fig:masqmail-channels}) are the ones required for an \MTA{}s at the moment. Support for other protocols seems not to be necessary at the moment, although new protocols and mailing concepts are likely to appear (see section \ref{sec:email-trends}). Today, other protocols are not needed, so \masqmail\ is regarded to fulfill \RF1. But as \masqmail\ has no support for adding further protocols, delaying the work to support them until they are widely used, appears to be the best strategy anyway.
    1.21  
    1.22  << smtp submission >> %fixme
    1.23  
    1.24 @@ -297,7 +294,7 @@
    1.25  The envelope and mail headers are generated when the mail is put into the queue. The requirements are fulfilled.
    1.26  
    1.27  \paragraph{\RF4: Aliasing}
    1.28 -Aliasing is done on delivery. All common kinds of aliases in the global aliases file are supported. \name{.forward} aliasing is not, but this is less common and seldom used.
    1.29 +Aliasing is done on delivery. All common kinds of aliases in the global aliases file are supported. So called \name{.forward} aliasing is not, but this is less common and seldom used.
    1.30  
    1.31  \paragraph{\RF5: Route management}
    1.32  Setting of the route to use is done on delivery. Headers can get rewritten a second time then. This part does provide all the functionality required.
    1.33 @@ -306,7 +303,7 @@
    1.34  Static authentication, based on \NAME{IP} addresses, can be achieved with \person{Venema}'s \NAME{TCP} \name{Wrapper} \cite{venema92}, by editing the \path{hosts.allow} and \path{hosts.deny} files. This is only relevant to authenticate host that try to submit mail into the system. Dynamic (secret-based) \SMTP\ authentication is already supported in form of \NAME{SMTP-AUTH} and \SMTP-after-\NAME{POP}, but only for outgoing connections. For incoming connections, only address-based authentication is supported.
    1.35  
    1.36  \paragraph{\RF7: Encryption}
    1.37 -Similar is the situation for encryption which is also only available for outgoing channels; here a wrapper application like \name{openssl} is needed. This creates a secure tunnel to send mail trough, but state-of-the-art is using \NAME{STARTTLS}, which is not supported. For incoming channels, no encryption is available. The only possible setup to provide encryption of incoming channels is using an application like \name{stunnel} to translate between the secure connection to the remote host and the \MTA. Unfortunately, this suffers from the problem explained in section \ref{sec:FIXME} and figure \ref{fig:stunnel}. Anyway, this would still be no \NAME{STARTTLS} support.
    1.38 +Similar is the situation for encryption which is also only available for outgoing channels; here a wrapper application like \name{openssl} is needed. This creates a secure tunnel to send mail trough, but state-of-the-art is using \NAME{STARTTLS}, which is not supported. For incoming channels, no encryption is available. The only possible setup to provide encryption of incoming channels is using an application like \name{stunnel} to translate between the secure connection to the remote host and the \MTA. Unfortunately, this suffers from the problem explained on page \pageref{fig:stunnel} in figure \ref{fig:stunnel}. Anyway, this would still be no \NAME{STARTTLS} support.
    1.39  
    1.40  \paragraph{\RF8: Spam handling}
    1.41  \masqmail\ nowadays does not provide special support for spam filtering. Spam prevention by not accepting spam during the \SMTP\ dialog is not possible at all. Spam filtering is only possible by using two \masqmail\ instances with an external spam filter inbetween. The mail flow is from the receiving \MTA\ instance, which accepts mail, to the filter application that processes and possible modifies it, to the second \MTA\ which is responsible for further delivery of the mail. This is a concept that works in general. And it is a good concept in principle to separate work with clear interfaces. But the need of two instances of the same \MTA (each for only half of the job) with doubled setup, is more a work-around. Best is to have this data flow respected in the \MTA\ design, like in \postfix. But the more important part of spam handling, for sure, is done during the \SMTP\ dialog in completely refusing unwanted mail.
    1.42 @@ -334,8 +331,6 @@
    1.43  In summary: Current reliability needs to be improved.
    1.44  %fixme: state machine
    1.45  
    1.46 -\masqmail\ uses the filesytem to store the queue, storing the queue in a databases might improve the reliability through better persistence. %fixme
    1.47 -
    1.48  \paragraph{\RG3: Robustness}
    1.49  The logging behavior of \masqmail\ is good, although it does not cover all problem situations. For example, if the queue directory is world writeable by accident (or as action of an intruder), any user can remove messages from the queue or replace them with own ones. \masqmail\ does not even write a debug message in this case. The origin of this problem, however, is \masqmail's trust in its environment.
    1.50  %todo: rule of robustness, rule of repair
    1.51 @@ -352,6 +347,7 @@
    1.52  The testability suffers from missing modularity. Testing program parts is hard to do. Nevertheless, it is done by compiling parts of the source to special test programs. %fixme: what are the names? what do they test?
    1.53  
    1.54  This kind of testing is only clean-room testing, so .... %fixme
    1.55 + % XXX
    1.56  
    1.57  \paragraph{\RG7: Performance}
    1.58  The performance---efficiency---of \masqmail\ is good enough for its target field of operation, where this is a minor goal.