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

comparison thesis/tex/4-MasqmailsFuture.tex @ 318:426ad56236ce

small fixes and todo -> fixme

author	meillo@marmaro.de
date	Wed, 21 Jan 2009 20:35:26 +0100
parents	3b7680af0ebe
children	82496704f747

comparison

equal deleted inserted replaced

-:3b7680af0ebe
+:426ad56236ce
 \SMTP\ is the primary mail transport protocol today, but with the increasing need for new protocols (see section \ref{sec:what-will-be-important}) in mind, support for more than just \SMTP\ is good to have. New protocols will show up, maybe multiple protocols need to be supported then. This leads to multiple remote channels, one for each supported protocol as it was done in other \MTA{}s. Best would be interfaces to add further protocols as modules.
 Outgoing mail is commonly either sent using \SMTP, piped into local commands (for example \path{uucp}), or delivered locally by appending to a mailbox. Outgoing channels are similar for \qmail, \postfix, and \name{sendmail X}: All of them have a module to send mail using \SMTP, and one for writing into a local mailbox.
-%todo: is the def of MTA: transfer between machines, or transfer between users?
+%fixme: is the def of MTA: transfer between machines, or transfer between users?
 Local mail delivery is a job that uses root privilege to be able to switch to any user in order to write to his mailbox. It is possible to deliver without being root privilege, but delivery to user's home folders is not generally possible then. Thus even the modular \MTA{}s \qmail\ and \postfix\ use root privilege for it. As mail delivery to local users is \emph{not} included in the basic job of an \MTA{} and introduces a lot of new complexity, why should the \MTA\ bother? In order to keep the system simple, reduce privilege, and to have programs that do one job well, the local delivery job should be handed over to a specialist: the \NAME{MDA}. \NAME{MDA}s know about the various mailbox formats and are aware of the problems of concurrent write access and the like. Hence passing the message, and the responsibility for it, over to an \NAME{MDA} seems to be best.
 This means an outgoing connection that pipes mail into local commands is required. To other outgoing channels applies what was already said about incoming channels.
 \begin{figure}
 \subsection{Architecture}
 \label{sec:discussion-mta-arch}
-%todo: what's this section to do with requirements?
+%fixme: what's this section to do with requirements?
 \masqmail's current architecture is monolithic like \sendmail's and \exim's. But more than the other two, is it one block of interweaved code. \exim\ has a highly structured code with many internal interfaces, a good example is the one for authentication ``modules''. %fixme: add ref
 \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules.
 \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
 In summary: Current reliability needs to be improved.
 %fixme: state machine
 \paragraph{\RG3: Robustness}
 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.
-%todo: rule of robustness, rule of repair
+%fixme: rule of robustness, rule of repair
 \paragraph{\RG4: Extendability}
 \masqmail's extendability is very poor. This is a general problem of monolithic software, but can thus be provided with high effort. \exim\ is an example for good extendability in a monolithic program.
 \paragraph{\RG5: Maintainability}
 \subsubsection*{A guard against dead ends}
 A new design does protect against such dead ends.
-Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail, which had an almost monopoly for a long time. But when security became important \sendmail\ was only repaired instead of removing the problem sources---its insecure design. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. %fixme: declined ??
+Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail, which had an almost monopoly for a long time. But when security became important \sendmail\ was only repaired instead of removing the problem sources---its insecure design. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. \sendmail's reaction to the new requirements, in form of \name{sendmail X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s. Redesigning a software as requirements change helps keeping it alive. % fixme: add quote: ``one thing surely remains: change'' (something like that)
-\sendmail's reaction to the new requirements, in form of \name{sendmail X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s. Redesigning a software as requirements change helps keeping it alive. % add quote: ``one thing surely remains: change'' (something like that)
 Another danger is the dead end of complexity which is likely to appear by constantly working on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. %fixme: proof
 Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} for example advertises such a philosophy of small and simple software by following the thoughts of the \unix\ inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code avoids complexity and is thus also a strong prerequisite for security.
 Remarkable is the distribution of functional and non-functional requirements to the strategies. The strategies for current code (\St1+2) have a functional to non-functional ratio of 10 to 3. The new design strategy (\St3) has a ratio of 5 to 12.
 This leaves current code to be better suited for adding functionality, and a new design to be better suited for quality improvements. Both strategies need to improve function as well as quality, but the difference determines the focus of the strategy.
-Easier work is likely to be done earlier in Free Software projects than hard work. Thus by choosing \St1+2 volunteer developers tend to implement function first and delay quality improvements, no matter what the suggested order is. \St3 in contrast would support %fixme: beguenstigen
+Easier work is likely to be done earlier in Free Software projects than hard work. Thus by choosing \St1+2 volunteer developers tend to implement function first and delay quality improvements, no matter what the suggested order is. \St3 in contrast would benefit early quality improvements and later function improvements. This is real-life experience in Free Software development.
-early quality improvements and later function improvements. This is real-life experience in Free Software development.
 In the short-time view, the effort for improving the existing code is much smaller than the effort for a new design plus improvements. But to have similar quality properties at the end of the short-time frame, a \masqmail\ that is based on current code will probably require nearly as much effort as a new designed \masqmail\ will take. For all further development afterwards, the new design will scale well while the old code will require exponential more work.
 In the long-time view, a restructuring for modularity is necessary anyway. The question is, when to do it: Right at the start in a new design, or later in some restructuring.
-%fixme: define exactly, be clear: what does break even here mean
+%fixme: define exactly, be clear: what does ``break even'' here mean
 \subsubsection*{The problem with ``good enough''}
 \begin{enumerate}
 \item The short-time plan: Add the most needed features, being encryption, authentication, and security wrappers, to the current code base.
 \item The long-time plan: Design a new architecture that satisfies the modern requirements especially the quality requirements.
 \end{enumerate}
-The background thought is to first do the most needed stuff on the existing code to keep %fixme: erhalten
+The background thought is to first do the most needed stuff on the existing code to keep it usable. This satisfies the urgent needs and removes the time pressure from the development of the new design. After this is done, a new designed \masqmail\ should be developed from scratch. This is the work for the future. It shall, after it is usable and throughout tested, supersede the old \masqmail.
-it usable. This satisfies the urgent needs and removes the time pressure from the development of the new design. After this is done, a new designed \masqmail\ should be developed from scratch. This is the work for the future. It shall, after it is usable and throughout tested, supersede the old \masqmail.
+The basic idea is, regularly developing a new design from scratch while the current version is still in use and gets repaired. Hence a modern design will inherit an old one in regular intervals. This is a very future-proof concept that combines the best of both worlds. The price to pay is only the increased work which gets covered by volunteers that \emph{want} to do it.
-The basic idea is, regularly developing a new design from scratch while the current version is still in use and gets repaired. Hence a modern design will inherit an old one in regular intervals. This is a very future-proof concept that combines the best of both worlds. The price to pay is only the increased work which gets covered %fixme: uebernommen
-by volunteers that \emph{want} to do it.
 %fixme: move that sentence to the beginning of the next chapter?
 The following chapter describes approaches and techniques for the work on the current code base, and it introduces ideas and plans for a new, modern \MTA\ design the next generation of \masqmail.

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 318:426ad56236ce