1.1 --- a/thesis/tex/2-MarketAnalysis.tex	Sun Jan 04 22:36:53 2009 +0100
     1.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Sun Jan 04 22:57:49 2009 +0100
     1.3 @@ -127,7 +127,7 @@
     1.4  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:
     1.5  \begin{quote}
     1.6  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.
     1.7 -\cite{wheeler03}
     1.8 +\hfill\cite{wheeler03}
     1.9  \end{quote}
    1.10  The amount of spam is huge. Panda Security and Commtouch state in their \name{Email Threats Trend Report} for the second Quarter of 2008: ``Spam levels throughout the second quarter averaged 77\,\%, ranging from a low of 64\,\% to a peak of 94\,\% of all email [...]''\cite[page 4]{panda:email-threats}. The report sees the main reason in the bot nets consisting of zombie computers: ``Spam and malware levels remain high for yet another quarter, powered by the brawny yet agile networks of zombie \NAME{IP}s.''\cite[page 1]{panda:email-threats} This is supported by IronPort Systems: ``More than 80 percent of spam now comes from a `zombie'---an infected \NAME{PC}, typically in a consumer broadband network, that has been hijacked by spammers.''\cite{ironport:zombie-computers}. Positive for \MTA{}s is, that they are not the main source for spam, but it is only a small delight. Spam is a general weakness of the email system, because it can not prevent it.
    1.11  

     2.1 --- a/thesis/tex/3-MailTransferAgents.tex	Sun Jan 04 22:36:53 2009 +0100
     2.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Sun Jan 04 22:57:49 2009 +0100
     2.3 @@ -11,12 +11,12 @@
     2.4  This is how Bryan \person{Costales} defines a \mta:
     2.5  \begin{quote}
     2.6  A mail transfer agent (\MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office.
     2.7 -\cite{costales97}
     2.8 +\hfill\cite{costales97}
     2.9  \end{quote}
    2.10  \name{The Free Dictionary} is a bit more concrete on the term:
    2.11  \begin{quote}
    2.12  Message Transfer Agent - (\MTA, Mail Transfer Agent): Any program responsible for delivering e-mail messages. Upon receiving a message from a Mail User Agent or another \MTA, [...] it [...] delivers it to any local addressees and/or forwards it to other remote \MTA{}s (routing) for delivery to remote recipients.
    2.13 -\citeweb{website:thefreedictionary}
    2.14 +\hfill\citeweb{website:thefreedictionary}
    2.15  \end{quote}
    2.16  
    2.17  Common to all \MTA{}s is the transport of mail to recipients; this is the actual job. Besides this similarity, \MTA{}s can be very different. Some of them have \NAME{POP3} and/or \NAME{IMAP} servers included. Some can fetch mails through these protocols. Others have have all features you can think of. And maybe there are some that do nothing else but transporting email.

     3.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 04 22:36:53 2009 +0100
     3.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Jan 04 22:57:49 2009 +0100
     3.3 @@ -47,6 +47,8 @@
     3.4  
     3.5  This section identifies the requirements for a modern \masqmail. Most of them will apply to modern \MTA{}s in general.
     3.6  
     3.7 +%Now that it is explained why email will survive (in some changed but related form), it is time to think about the properties required for \mta{}s in the next years. Because as the fields and kinds of usage change, the requirement change too.
     3.8 +
     3.9  
    3.10  
    3.11  \subsection{General requirements}
    3.12 @@ -318,7 +320,8 @@
    3.13  
    3.14  \person{Hafiz} agrees: ``The goal of making software secure can be better achieved by making the design simple and easier to understand and verify.''\cite[page 64]{hafiz05} He identifies the security of \qmail\ to come from it's \name{compartmentalization}, which goes hand in hand with modularity:
    3.15  \begin{quote}
    3.16 -A perfect example is the contrast between the feature envy early \sendmail\ architecture implemented as one process and the simple, modular architecture of \qmail. The security of \qmail\ comes from its compartmentalized simple processes that perform one task only and are therefore testable for security. \cite[page 64]{hafiz05}
    3.17 +A perfect example is the contrast between the feature envy early \sendmail\ architecture implemented as one process and the simple, modular architecture of \qmail. The security of \qmail\ comes from its compartmentalized simple processes that perform one task only and are therefore testable for security.
    3.18 +\hfill\cite[page 64]{hafiz05}
    3.19  \end{quote}
    3.20  As well does \person{Dent} for \postfix: ``The modular architecture of Postfix forms the basis for much of its security.'' \cite[page 7]{dent04}
    3.21  
    3.22 @@ -329,7 +332,7 @@
    3.23  Good design is the sword and shield of the security-conscious developer. Sound design defends your application from subversion or misuse, protecting your network and the information on it from internal and external attacks alike. It also provides a safe foundation for future extensions and maintainance of the software.
    3.24  %
    3.25  %Bad design makes life easier for attackers and harder for the good guys, especially if it contributes to a false sends of security while obscuring pertinent failings.
    3.26 -\cite[page 55]{graff03}
    3.27 +\hfill\cite[page 55]{graff03}
    3.28  \end{quote}
    3.29  
    3.30  

     4.1 --- a/thesis/tex/5-Improvements.tex	Sun Jan 04 22:36:53 2009 +0100
     4.2 +++ b/thesis/tex/5-Improvements.tex	Sun Jan 04 22:57:49 2009 +0100
     4.3 @@ -30,7 +30,7 @@
     4.4  \begin{quote}
     4.5  %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.
     4.6  None of these [authentication methods] 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, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users.
     4.7 -\cite[page 44]{dent04}
     4.8 +\hfill\cite[page 44]{dent04}
     4.9  \end{quote}
    4.10  
    4.11  %either by