1.1 --- a/thesis/tex/5-Improvements.tex	Sat Feb 07 14:47:27 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Sat Feb 07 19:00:25 2009 +0100
     1.3 @@ -75,7 +75,6 @@
     1.4  \index{sasl}
     1.5  
     1.6  \begin{quote}
     1.7 -%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 your 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.
     1.8  None of these [authentication methods] is an ideal solution. They require additional code compiled into your existing daemons that may then require special write access 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 your users' mail pass through your system no matter where they are on the Internet, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users.
     1.9  \hfill\cite[page~44]{dent04}
    1.10  \end{quote}
    1.11 @@ -106,7 +105,6 @@
    1.12  For a small \MTA\ like \masqmail, it seems preferable to store the login data in a text file under \masqmail's control. This is the most simple choice for many usage scenarios. But using a central authentication facility has advantages in larger setups, too. \name{Cyrus} \NAME{SASL} supports both, so there is no problem. If \name{gsasl} is chosen, it seems best to start with an authentication file under \masqmail's control.
    1.13  
    1.14  
    1.15 -%fixme: << how could this be covered by architecture (e.g. smtp submission). >>
    1.16  
    1.17  
    1.18  
    1.19 @@ -204,7 +202,6 @@
    1.20  \end{enumerate}
    1.21  \index{compartmentalization}
    1.22  
    1.23 -%fixme: << conditional compilation >>
    1.24  
    1.25  
    1.26  \subsubsection*{Incoming channels}
    1.27 @@ -213,8 +210,7 @@
    1.28  The functional requirements for incoming channels were already discussed as \RF\,1 on page~\pageref{rf1}. Two required incoming channels were identified: the \path{sendmail} command for local mail submission and the \SMTP\ daemon for remote connections.
    1.29  \index{sendmail!command}
    1.30  
    1.31 -A bit different is the structure of \name{sendmail~X} at that point: Locally submitted messages go also to the \SMTP\ daemon, which is the only connection to the mail queue. %fixme: is it a smtp dialog? or a back door?
    1.32 -\person{Finch} proposes a similar approach \cite{finch-sendmail}: He wants the \path{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA, like it is done by connections from remote. The advantage here is to have one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid}, because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
    1.33 +A bit different is the structure of \name{sendmail~X} at that point: Locally submitted messages go also to the \SMTP\ daemon, which is the only connection to the mail queue. \person{Finch} proposes a similar approach \cite{finch-sendmail}: He wants the \path{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA, like it is done by connections from remote. The advantage here is to have one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid}, because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
    1.34  \index{sendmailx}
    1.35  \index{smtp}
    1.36  \index{setuid}
    1.37 @@ -282,8 +278,7 @@
    1.38  \qmail\ has the principle of ``don't parse'' which propagates the avoidance of parsing as much as possible. The reason is that parsing is a highly complex task which likely makes code exploitable.
    1.39  \index{qmail}
    1.40  
    1.41 -In \masqmail's new design, mail should be stored into the queue without parsing. A scanning module should then parse the message with high care. It seems best to use a \name{parser generator}\footnote{\person{Stephen~C.\ Johnson}'s paper about \name{yacc} is a good introduction into \name{parser generators} \cite{johnson79}.} for this work. The parsed data should then get modified if needed and written into a second queue. This approach has several advantages. First, the receiving parts of the system are independent from content, they simply store it into the queue. Second, one single module does the parsing and generates new messages that contain only valid data. Third, the sending parts of the system will thus only work on messages that consist of valid data. Of course, it must be ensured that each message passes through the \name{scanning} module, but this is already required for spam and malware scanning.
    1.42 -%fixme: ref for parser generator
    1.43 +In \masqmail's new design, mail should be stored into the queue without parsing. A scanning module should then parse the message with high care. \person{Spinellis} proposes reliable approaches to do this work \cite[pages~17--18]{spinellis06}; using a \name{parser generator}\footnote{\person{Stephen~C.\ Johnson}'s paper about \name{yacc} is a good introduction into \name{parser generators} \cite{johnson79}.} is the best solution here. The parsed data should then get modified if needed and written into a second queue. This approach has several advantages. First, the receiving parts of the system are independent from content, they simply store it into the queue. Second, one single module does the parsing and generates new messages that contain only valid data. Third, the sending parts of the system will thus only work on messages that consist of valid data. Of course, it must be ensured that each message passes through the \name{scanning} module, but this is already required for spam and malware scanning.
    1.44  \index{parser generator}
    1.45  
    1.46  The mail body will never get modified, except for removing and adding transfer protocol specific requirements like dot stuffing or special line ending characters. These translations are only done in receiving and sending modules.
    1.47 @@ -310,8 +305,7 @@
    1.48  \subsubsection*{Route management}
    1.49  \index{online routes}
    1.50  
    1.51 -The online state is only important for the sending modules of the system, thus it should be queried in the \name{queue-out} module which selects ready messages from the \name{outgoing} queue and transfers them to the appropriate sending module. Route-based aliasing, which was described in the last section, %fixme: is this still true?
    1.52 -should be done in the same go.
    1.53 +The online state is only important for the sending modules of the system, thus it should be queried in the \name{queue-out} module which selects ready messages from the \name{outgoing} queue and transfers them to the appropriate sending module. Route-based aliasing, which was described in the last section, should be done in the same go.
    1.54  
    1.55  
    1.56  
    1.57 @@ -431,6 +425,7 @@
    1.58  \paragraph{Receiver modules}
    1.59  \index{incoming channels}
    1.60  They are the communication interface between external senders and the \name{queue-in} module. Each protocol needs a corresponding \name{receiver module} to be supported. Most popular is the \name{sendmail} module, which is a command to be called from the local host, and the \name{smtpd} module which usually listens on port 25. Other modules to support other protocols may be added as needed. Receiving modules that need to listen on ports should get invoked by \name{inetd}, or by \person{Bernstein}'s more secure \name{ucspi-tcp}. This makes it possible to run them with least privilege.
    1.61 +\index{least privilege}
    1.62  
    1.63  
    1.64  \paragraph{The \name{queue-in} module}
    1.65 @@ -534,7 +529,7 @@
    1.66  Another possibility is to run a master process as daemon which starts and restarts the system parts. \postfix\ has such a master process, \qmail\ lacks it. The jobs of a master process can be done by other tools of the operating system too, thus making a master process abdicable. \masqmail\ does probably better go without a master process, because it aims to save resources, not to get the best performance.
    1.67  \index{master process}
    1.68  
    1.69 -A sane permission management is very important for secure software in general. The \name{principle of least privilege}, as it is often called, should be respected. If it is possible to use lower privilege then it should be done. An example for doing so is the \name{smtpd} module. It is a server module which listens on a port. One way is to start it as root and let it bind to the port and drop all privilege before it does any other work. But root privilege is avoidable completely if \name{inetd}, or one of its substitutes, listens on the port instead of the \name{smtpd} module. \name{inetd} will then launch the \name{smtpd} module to handle the connection whenever a connection attempt to the port is made. The \name{smtpd} module needs no privilege at all this way.
    1.70 +A sane permission management is very important for secure software in general. The \name{principle of least privilege} \cite[section~I.A.3.f]{saltzer75}, as it is often called, should be respected. If it is possible to use lower privilege then it should be done. An example for doing so is the \name{smtpd} module. It is a server module which listens on a port. One way is to start it as root and let it bind to the port and drop all privilege before it does any other work. But root privilege is avoidable completely if \name{inetd}, or one of its substitutes, listens on the port instead of the \name{smtpd} module. \name{inetd} will then launch the \name{smtpd} module to handle the connection whenever a connection attempt to the port is made. The \name{smtpd} module needs no privilege at all this way.
    1.71  
    1.72  
    1.73