docs/diploma

changeset 248:724cc6057105

complete names are now in small caps
author meillo@marmaro.de
date Sun, 11 Jan 2009 20:49:50 +0100
parents 50240b753a46
children 32e14e98cd91
files thesis/cover.tex thesis/tex/0-preface.tex thesis/tex/1-Introduction.tex thesis/tex/2-MarketAnalysis.tex thesis/tex/3-MailTransferAgents.tex thesis/tex/4-MasqmailsFuture.tex thesis/tex/5-Improvements.tex thesis/tex/official.tex thesis/tex/titlepage.tex
diffstat 9 files changed, 29 insertions(+), 29 deletions(-) [+]
line diff
     1.1 --- a/thesis/cover.tex	Sun Jan 11 20:26:33 2009 +0100
     1.2 +++ b/thesis/cover.tex	Sun Jan 11 20:49:50 2009 +0100
     1.3 @@ -13,11 +13,11 @@
     1.4  \end{center}
     1.5  
     1.6  \vspace*{12ex}
     1.7 -\centerline{Markus \textsc{Schnalke}}
     1.8 +\centerline{\textsc{Markus Schnalke}}
     1.9  \vfill
    1.10  
    1.11  \textbf{Diploma Thesis}
    1.12  
    1.13 -\makebox[\textwidth][s]{Course \emph{Business Information Systems}, University of Applied Sciences Ulm, 2009}
    1.14 +\makebox[\textwidth][s]{Course Business Information Systems, University of Applied Sciences Ulm, 2009}
    1.15  
    1.16  \end{document}
     2.1 --- a/thesis/tex/0-preface.tex	Sun Jan 11 20:26:33 2009 +0100
     2.2 +++ b/thesis/tex/0-preface.tex	Sun Jan 11 20:49:50 2009 +0100
     2.3 @@ -62,7 +62,7 @@
     2.4  is used for source code, contents of files and output from programs.
     2.5  \\ &\\
     2.6  
     2.7 -\textsc{Small Caps} &
     2.8 +\person{Small Caps} &
     2.9  are used to indicate names of persons.
    2.10  \\ &\\
    2.11  
     3.1 --- a/thesis/tex/1-Introduction.tex	Sun Jan 11 20:26:33 2009 +0100
     3.2 +++ b/thesis/tex/1-Introduction.tex	Sun Jan 11 20:49:50 2009 +0100
     3.3 @@ -75,7 +75,7 @@
     3.4  
     3.5  (include history of email, definition of MTA and sendmail-compatibility in text)
     3.6  
     3.7 -The \masqmail\ program was written by Oliver \person{Kurth}, starting in 1999. His aim was to create a small \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ is easy configurable for situations which are rarely solveable with the common \MTA{}s.
     3.8 +The \masqmail\ program was written by \person{Oliver Kurth}, starting in 1999. His aim was to create a small \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ is easy configurable for situations which are rarely solveable with the common \MTA{}s.
     3.9  
    3.10  \masqmail\ queues mail for destinations outside the local network if no connection to the internet is online. If the machine goes online, this mail is sent. Mail to local machines is sent immediately.
    3.11  
    3.12 @@ -91,7 +91,7 @@
    3.13  
    3.14  \subsection{Target field / When to use \masqmail}
    3.15  
    3.16 -Its original author, Oliver \person{Kurth}, sees \masqmail\ so:
    3.17 +Its original author, \person{Oliver Kurth}, sees \masqmail\ so:
    3.18  \begin{quote}
    3.19  MasqMail is a mail server designed for hosts that do not have a permanent internet connection eg. a home network or a single host at home. It has special support for connections to different ISPs. It replaces sendmail or other MTAs such as qmail or exim.
    3.20  \end{quote}
    3.21 @@ -169,7 +169,7 @@
    3.22  
    3.23  \subsection{Features}
    3.24  
    3.25 -Here regarded is version 0.2.21 of \masqmail. This is the last version released by Oliver \person{Kurth}, and the basis for my thesis.
    3.26 +Here regarded is version 0.2.21 of \masqmail. This is the last version released by \person{Oliver Kurth}, and the basis for my thesis.
    3.27  
    3.28  
    3.29  \subsubsection*{The source code}
     4.1 --- a/thesis/tex/2-MarketAnalysis.tex	Sun Jan 11 20:26:33 2009 +0100
     4.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Sun Jan 11 20:49:50 2009 +0100
     4.3 @@ -93,7 +93,7 @@
     4.4  \subsubsection*{Unified Communication}
     4.5  \name{Unified communication} is the technology aiming to consolidate and integrate all electronic communication and providing access for all kinds of hardware clients. Unified communication tries to bring the three trends here mentioned together. The \name{{\smaller PC} Magazine} has the following definition in its Encyclopedia: ``[Unified communications is t]he real-time redirection of a voice, text or e-mail message to the device closest to the intended recipient at any given time.'' \citeweb{pcmag:uc}. The main goal is to integrate all kinds of communication (asynchronous and synchronous) into one system, hence this requires real-time delivery of data.
     4.6  
     4.7 -According to Michael \person{Osterman}, unified communications is already possible as far as various incoming sources are routed to one storage where messages can be accessed by one or a few clients \cite{osterman08}. But a system with an ``intelligent parser of a single data stream into separate streams that are designed to meet the real-time needs of the user'' is a goal for the future, he says.
     4.8 +According to \person{Michael Osterman}, unified communications is already possible as far as various incoming sources are routed to one storage where messages can be accessed by one or a few clients \cite{osterman08}. But a system with an ``intelligent parser of a single data stream into separate streams that are designed to meet the real-time needs of the user'' is a goal for the future, he says.
     4.9  
    4.10  The question is, whether the integration of synchronous and asynchronous communication does make sense. A communication between one person talking on the phone and the other replying using his instant messenger, certainly does (assumed the text-to-speech and speech-to-text converting is fast and the quality good enough). But transferring large video messages and real-time communication data with the same technology, possibly does not.
    4.11  
    4.12 @@ -105,7 +105,7 @@
    4.13  
    4.14  The easiest way of Unified Messaging is to base it on either email and convert all input sources to email messages (as attachments for instance) and store them in the user's mail box, or use the telephone system as basis and convert text messages to speech. Both is technically possible for asynchronous communication.
    4.15  
    4.16 -Finally, a critical voice from Jesse \person{Freund}, who voted Unified Messaging on top of a hype list, published by \name{Wired.com} ten years ago. His description of the technology ended with the humorous sentences:
    4.17 +Finally, a critical voice from \person{Jesse Freund}, who voted Unified Messaging on top of a hype list, published by \name{Wired.com} ten years ago. His description of the technology ended with the humorous sentences:
    4.18  \begin{quote}
    4.19  Unified messaging is a nice idea, but a tough sell: The reason you bought a cell phone, a pager, and a fax/modem is because each does its job well. No one wants to download voice mail as a series of RealAudio messages or sit through a voice mail bot spelling out email, complete with `semicolon dash end-parenthesis' for ;-).
    4.20  \hfill\cite{wired:hype}
    4.21 @@ -130,7 +130,7 @@
    4.22  The two dimension---a subject and the market---are regarded in relation to each other by the analysis. Here the analysis shall be driven by the market's dimension. Thus first opportunities of the market are identified and split into being strengths or weaknesses of email. Then the same is done for threats of the market.
    4.23  
    4.24  \subsubsection*{Threats}
    4.25 -The market's main threat is \emph{spam}, also named \name{junk mail} or \name{unsolicited commercial email} (\NAME{UCE}). David~A.\ \person{Wheeler} is clear about it:
    4.26 +The market's main threat is \emph{spam}, also named \name{junk mail} or \name{unsolicited commercial email} (\NAME{UCE}). \person{David~A.\ Wheeler} is clear about it:
    4.27  \begin{quote}
    4.28  Since \emph{receivers} pay the bulk of the costs for spam (including most obviously their time to delete all that incoming spam), spam use will continue to rise until effective technical and legal countermeasures are deployed, \emph{or} until people can no longer use email.
    4.29  \hfill\cite{wheeler03}
    4.30 @@ -210,16 +210,16 @@
    4.31  
    4.32  \subsubsection*{New email concepts}
    4.33  
    4.34 -Changing requirements for email communication lead to the need for new concepts and new protocols that cover these requirements. One of these concepts to redesign the electronic mail system is named ``Internet Mail 2000''. It was proposed by Daniel~J.\ \person{Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others too.
    4.35 +Changing requirements for email communication lead to the need for new concepts and new protocols that cover these requirements. One of these concepts to redesign the electronic mail system is named ``Internet Mail 2000''. It was proposed by \person{Daniel~J.\ Bernstein}, the creator of \qmail. Similar approaches were independently introduced by others too.
    4.36  %FIXME: add references for IM2000
    4.37  
    4.38  As main change, the sender has the responsibility for mail storage; only a notification about a mail message gets send to the recipient. He can fetch the message then from the sender's server. This is in contrast to the \NAME{SMTP} mail architecture, where mail and the responsibility for it is transferred from the sender to the receiver (called \name{store-and-forward}).
    4.39  
    4.40  \name{Mail transfer agent}s are still important in this new email architecture, but in a slightly different way. They do not transferring mail itself anymore, but they transport the notifications about new mail to the destinations. This is a quite similar job as they do in the \NAME{SMTP} model. The real transfer of the mail can be done in an arbitrary way, for example via \NAME{FTP} or \NAME{SCP}.
    4.41  
    4.42 -A second concept, this one primary to arm against spam, is David~A.\ \person{Wheeler}'s \name{Guarded Email}, described in \cite{wheeler03}. It requires messages to be recognized as Ham (non-spam) to be accepted, otherwise a challenge-response authentication will be initiated.
    4.43 +A second concept, this one primary to arm against spam, is \person{David~A.\ Wheeler}'s \name{Guarded Email}, described in \cite{wheeler03}. It requires messages to be recognized as Ham (non-spam) to be accepted, otherwise a challenge-response authentication will be initiated.
    4.44  
    4.45 -\name{Hashcash} by Adam \person{Back}---a third concept---tries to limit spam and denial of service attacks \cite{back02}. It requests payment for mail to get accepted. The costs are computing time for generating hash values. Thus sending spam becomes expensive. More information can be found on \citeweb{hashcash:homepage}.
    4.46 +\name{Hashcash} by \person{Adam Back}---a third concept---tries to limit spam and denial of service attacks \cite{back02}. It requests payment for mail to get accepted. The costs are computing time for generating hash values. Thus sending spam becomes expensive. More information can be found on \citeweb{hashcash:homepage}.
    4.47  
    4.48  New concepts, like the ones presented here, are invented to remove problems of the email technology. Internet Mail 2000, for instance, removes the spam and large message transfer problems.
    4.49  
     5.1 --- a/thesis/tex/3-MailTransferAgents.tex	Sun Jan 11 20:26:33 2009 +0100
     5.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Sun Jan 11 20:49:50 2009 +0100
     5.3 @@ -8,7 +8,7 @@
     5.4  \section{Types of MTAs}
     5.5  ``Mail transfer agent'' is a term covering a variety of programs. One thing is common to them: they transfer email from one senders to recipients.
     5.6  
     5.7 -This is how Bryan \person{Costales} defines a \mta:
     5.8 +This is how \person{Bryan Costales} defines a \mta:
     5.9  \begin{quote}
    5.10  A mail transfer agent (\MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office.
    5.11  \hfill\cite{costales97}
    5.12 @@ -74,7 +74,7 @@
    5.13  
    5.14  \MTA\ statistics are rare, differ, and good data is hard to collect. These points are bad if one wants good statistics. Thus it is obvious there are only few available.
    5.15  
    5.16 -Table \ref{tab:mta-market-share} shows the most used \MTA{}s determined by three different statistics. The first was done by Daniel~J.\ \person{Bernstein} (the author of \qmail) in 2001 \cite{bernstein01}. The second is by \person{Simpson} and \person{Bekman} in 2007 and was published on \name{O'ReillyNet} \cite{simpson07}. And the third is from \name{MailRadar.com} with unknown date\footnote{The footer of the website shows ``Copyright 2007'' but more likely does this refer to the whole website.} \citeweb{mailradar:mta-stats}.
    5.17 +Table \ref{tab:mta-market-share} shows the most used \MTA{}s determined by three different statistics. The first was done by \person{Daniel~J.\ Bernstein} (the author of \qmail) in 2001 \cite{bernstein01}. The second is by \person{Simpson} and \person{Bekman} in 2007 and was published on \name{O'ReillyNet} \cite{simpson07}. And the third is from \name{MailRadar.com} with unknown date\footnote{The footer of the website shows ``Copyright 2007'' but more likely does this refer to the whole website.} \citeweb{mailradar:mta-stats}.
    5.18  
    5.19  \begin{table}
    5.20  	\begin{center}
    5.21 @@ -97,7 +97,7 @@
    5.22  
    5.23  \subsection{The four major Free Software MTAs}
    5.24  
    5.25 -Now follows a small introduction to the four programs chosen for comparison. \masqmail\ is not presented here, as it was already introduced in chapter \ref{chap:introduction}. Longer introductions, including analysis and comparison, were written by Jonathan \person{de Boyne Pollard} \cite{jdebp}.
    5.26 +Now follows a small introduction to the four programs chosen for comparison. \masqmail\ is not presented here, as it was already introduced in chapter \ref{chap:introduction}. Longer introductions, including analysis and comparison, were written by \person{Jonathan de Boyne Pollard} \cite{jdebp}.
    5.27  
    5.28  
    5.29  
    5.30 @@ -105,7 +105,7 @@
    5.31  \label{sec:sendmail}
    5.32  \sendmail\ is the best known \mta, since it was one of the first and surely the one that made \MTA{}s popular. It also was shipped as default \MTA{}s by many vendors of \unix\ systems. %fixme: ref
    5.33  
    5.34 -The program was written by Eric \person{Allman} as the successor of his program \name{delivermail}. \person{Allman} was not the only one working on the program. Other people developed own versions of it and a variety of flavors came up, especially in the late eighties when Allman was inactive. %fixme: ref
    5.35 +The program was written by \person{Eric Allman} as the successor of his program \name{delivermail}. \person{Allman} was not the only one working on the program. Other people developed own versions of it and a variety of flavors came up, especially in the late eighties when Allman was inactive. %fixme: ref
    5.36  
    5.37  \sendmail\ designed to transfer mails between different protocols and networks, this lead to a very flexible, though complex, configuration.
    5.38  
    5.39 @@ -119,7 +119,7 @@
    5.40  
    5.41  \subsubsection*{exim}
    5.42  \label{sec:exim}
    5.43 -\exim\ was started in 1995 by Philip \person{Hazel} at the \name{University of Cambridge}. It is a fork of \name{smail-3}, and inherited a monolithic architecture similar to \sendmail's. But having no separation of the individual components of the system did not hurt. Its security is quite good. %fixme: ref
    5.44 +\exim\ was started in 1995 by \person{Philip Hazel} at the \name{University of Cambridge}. It is a fork of \name{smail-3}, and inherited a monolithic architecture similar to \sendmail's. But having no separation of the individual components of the system did not hurt. Its security is quite good. %fixme: ref
    5.45  
    5.46  \exim\ is highly configurable, especially in the field of mail policies. This makes it easy to specify how mail is routed through the system and who is allowed to send email to whom. Also interfaces for integration of virus and spam checkers are provided by design. %fixme: ref
    5.47  
    5.48 @@ -131,7 +131,7 @@
    5.49  
    5.50  \subsubsection*{qmail}
    5.51  \label{sec:qmail}
    5.52 -\qmail\ is seen by its community as ``a modern SMTP server which makes sendmail obsolete'' \citeweb{qmail:homepage2}. It was written by Daniel~J.\ \person{Bernstein} starting in 1995. His primary goal was to create a secure \MTA\ to replace the popular, but vulnerable, \sendmail. %fixme: ref
    5.53 +\qmail\ is seen by its community as ``a modern SMTP server which makes sendmail obsolete'' \citeweb{qmail:homepage2}. It was written by \person{Daniel~J.\ Bernstein} starting in 1995. His primary goal was to create a secure \MTA\ to replace the popular, but vulnerable, \sendmail. %fixme: ref
    5.54  
    5.55  \qmail\ first introduced many innovative concepts in \mta\ design. The most obvious contrast to \sendmail\ and \exim\ is its modular design. But \qmail\ was not the first modular \MTA. \NAME{MMDF}, which predates even \sendmail, was modular too. Regardless of \NAME{MMDF}'s modular architecture, \qmail\ is generally seen as the first security-aware \MTA. %fixme:ref
    5.56  
    5.57 @@ -139,13 +139,13 @@
    5.58  
    5.59  Because of \person{Bernstein}'s inactivity though changing requirements since 1998, ``[a] motley krewe of qmail contributors (see the README) has put together a netqmail-1.06 distribution of qmail. It is derived from Daniel Bernstein's qmail-1.03 plus bug fixes, a few feature enhancements, and some documentation.'' \citeweb{netqmail:homepage}.
    5.60  
    5.61 -\qmail's homepages are \citeweb{qmail:homepage1} and \citeweb{qmail:homepage2}. The best book about \qmail, from \person{Bernstein}'s view, is Dave \person{Sill}'s handbook \cite{sill02}. His free available guide ``Life with qmail'' is another valuable source \cite{lifewithqmail}.
    5.62 +\qmail's homepages are \citeweb{qmail:homepage1} and \citeweb{qmail:homepage2}. The best book about \qmail, from \person{Bernstein}'s view, is \person{Dave Sill}'s handbook \cite{sill02}. His free available guide ``Life with qmail'' is another valuable source \cite{lifewithqmail}.
    5.63  
    5.64  
    5.65  
    5.66  \subsubsection*{postfix}
    5.67  \label{sec:postfix}
    5.68 -The \postfix\ project started in 1999 at \name{IBM research}, then called \name{VMailer} or \name{IBM Secure Mailer}. Wietse \person{Venema}'s program ``attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.''\citeweb{postfix:homepage} In fact, \postfix\ was mainly designed after qmail's architecture to gain security. But in contrast to \qmail\ it aims much more on being fast and full-featured.
    5.69 +The \postfix\ project started in 1999 at \name{IBM research}, then called \name{VMailer} or \name{IBM Secure Mailer}. \person{Wietse Venema}'s program ``attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.''\citeweb{postfix:homepage} In fact, \postfix\ was mainly designed after qmail's architecture to gain security. But in contrast to \qmail\ it aims much more on being fast and full-featured.
    5.70  
    5.71  Today \postfix\ is taken by many \unix\ systems and \gnulinux\ distributions as default \MTA.
    5.72  
    5.73 @@ -160,7 +160,7 @@
    5.74  
    5.75  \section{Comparison of MTAs}
    5.76  
    5.77 -This section does not try to provide an overall \MTA\ comparison, because this is already done by others. Remarkable comparisons are the one by Dan \person{Shearer} \cite{shearer06} and a discussion on the mailing list \name{plug@lists.q-linux.com} \cite{plug:mtas}. Tabular overviews may be found at \citeweb{mailsoftware42}, \citeweb{wikipedia:comparison-of-mail-servers}, and \cite[section 1.9]{lifewithqmail}.
    5.78 +This section does not try to provide an overall \MTA\ comparison, because this is already done by others. Remarkable comparisons are the one by \person{Dan Shearer} \cite{shearer06} and a discussion on the mailing list \name{plug@lists.q-linux.com} \cite{plug:mtas}. Tabular overviews may be found at \citeweb{mailsoftware42}, \citeweb{wikipedia:comparison-of-mail-servers}, and \cite[section 1.9]{lifewithqmail}.
    5.79  
    5.80  Here provided is an overview on important properties of the four previously introduced \MTA{}s. The data comes from the above stated sources and is collected in table \ref{tab:mta-comparison}.
    5.81  
    5.82 @@ -177,7 +177,7 @@
    5.83  \subsubsection*{Architecture}
    5.84  
    5.85  Architecture is most important when comparing \MTA{}s. Many other properties of a program depend on its architecture. %fixme: add ref?
    5.86 -Munawar \person{Hafiz} \cite{hafiz05} discusses in detail on \mta\ architecture, comparing \sendmail, \qmail, \postfix, and \name{sendmail X}. Jonathan \person{de Boyne Pollard}'s \MTA\ review \cite{jdebp} is a source too.
    5.87 +\person{Munawar Hafiz} \cite{hafiz05} discusses in detail on \mta\ architecture, comparing \sendmail, \qmail, \postfix, and \name{sendmail X}. \person{Jonathan de Boyne Pollard}'s \MTA\ review \cite{jdebp} is a source too.
    5.88  
    5.89  Two different architecture types show off: monolithic and modular \mta{}s.
    5.90  
    5.91 @@ -185,7 +185,7 @@
    5.92  
    5.93  Modular \MTA{}s are \NAME{MMDF}, \qmail, \postfix, and \name{MeTA1}. They consist of several programs, each doing a part of the overall job. The different programs run with the least permissions the need, and \emph{setuid root} can be avoided.
    5.94  
    5.95 -The architecture does not directly define the program's security, but ``[t]he goal of making a software secure can be better achieved by making the design simple and easier to understand and verify''\cite[chapter 6]{hafiz05}. \exim, though being monolithic, has a fairly clean security record. But it is very hard to keep the security up, as the program growth. Wietse \person{Venema} (the author of \postfix) says, it was the architecture that enabled \postfix\ to grow without running into security problems. \cite[page 13]{venema:postfix-growth}
    5.96 +The architecture does not directly define the program's security, but ``[t]he goal of making a software secure can be better achieved by making the design simple and easier to understand and verify''\cite[chapter 6]{hafiz05}. \exim, though being monolithic, has a fairly clean security record. But it is very hard to keep the security up, as the program growth. \person{Wietse Venema} (the author of \postfix) says, it was the architecture that enabled \postfix\ to grow without running into security problems. \cite[page 13]{venema:postfix-growth}
    5.97  
    5.98  The modular design, with each sub-program doing one part of the overall job, conforms to the \name{Unix Philosophy}. The Unix Philosophy \cite{gancarz95} demands ``small is beautiful'' and ``make each program do one thing well''. Monolithic \MTA{}s fail here.
    5.99  
     6.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 11 20:26:33 2009 +0100
     6.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 11 20:49:50 2009 +0100
     6.3 @@ -449,7 +449,7 @@
     6.4  SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
     6.5  \end{verbatim}
     6.6  }
     6.7 -The development cost is not relevant for a \freesw\ project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by Oliver \person{Kurth} within four years, in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer, not as employee with eight work-hours per day.
     6.8 +The development cost is not relevant for a \freesw\ project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by \person{Oliver Kurth} within four years, in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer, not as employee with eight work-hours per day.
     6.9  
    6.10  Given the assumptions that (1) an equal amount of code needs to be produced for a new \masqmail, (2) a third of existing code can be reused plus concepts and knowledge, and (3) development speed is like \person{Kurth}'s. Then it would take between two and three years to have a redesigned new \masqmail\ with the same features that \masqmail\ now has. Less time would be needed if a simpler architecture allows faster development, better testing, and less bugs.
    6.11  
     7.1 --- a/thesis/tex/5-Improvements.tex	Sun Jan 11 20:26:33 2009 +0100
     7.2 +++ b/thesis/tex/5-Improvements.tex	Sun Jan 11 20:49:50 2009 +0100
     7.3 @@ -137,7 +137,7 @@
     7.4  \sendmail-compatible \mta{}s must support at least two incoming channels: mail submitted using the \sendmail\ command, and mail received via the \SMTP\ daemon. It is therefor common to split the incoming channel into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view.
     7.5  
     7.6  In contrast is \name{sendmail X}: Its locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a second door?
     7.7 -\person{fanf} proposes a similar approach. He wants the \texttt{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 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 to put 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.
     7.8 +\person{Finch} proposes a similar approach. He wants the \texttt{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 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 to put 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.
     7.9  
    7.10  But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP\ being the main mail transfer protocol. To \qmail\ and \postfix\ new modules to support other ways of message receival may be added without change of other parts of the system. Also is it better to have more independent modules if each one is simpler then.
    7.11  
     8.1 --- a/thesis/tex/official.tex	Sun Jan 11 20:26:33 2009 +0100
     8.2 +++ b/thesis/tex/official.tex	Sun Jan 11 20:49:50 2009 +0100
     8.3 @@ -17,5 +17,5 @@
     8.4  
     8.5  \vspace{36ex}
     8.6  
     8.7 -Breitingen, YYYY-MM-DD \hfill Markus \person{Schnalke}
     8.8 +Breitingen, YYYY-MM-DD \hfill \person{Markus Schnalke}
     8.9  %FIXME: insert correct date
     9.1 --- a/thesis/tex/titlepage.tex	Sun Jan 11 20:26:33 2009 +0100
     9.2 +++ b/thesis/tex/titlepage.tex	Sun Jan 11 20:49:50 2009 +0100
     9.3 @@ -14,12 +14,12 @@
     9.4  	\begin{flushright}
     9.5  		\textbf{Diploma Thesis}\\
     9.6  		\quad\\
     9.7 -		by Markus \textsc{Schnalke}\\
     9.8 +		by \textsc{Markus Schnalke}\\
     9.9  		Matriculation: \#039131\\
    9.10  		\quad\\
    9.11 -		Course \emph{Business Information Systems}\\
    9.12 +		Course Business Information Systems\\
    9.13  		University of Applied Sciences Ulm\\
    9.14 -		Prof.\ Dr.\ Markus \textsc{Schäffter}, Advisor\\
    9.15 +		Prof.\ Dr.\ \textsc{Markus Schäffter}, Advisor\\
    9.16  		\quad\\
    9.17  		Handed in on January 30, 2009
    9.18  	\end{flushright}