1.1 --- a/thesis/bib/thesis.bib	Sat Feb 07 12:06:30 2009 +0100
     1.2 +++ b/thesis/bib/thesis.bib	Sat Feb 07 14:47:27 2009 +0100
     1.3 @@ -499,4 +499,11 @@
     1.4  
     1.5  
     1.6  
     1.7 -
     1.8 +@incollection{johnson79,
     1.9 +	author = "Stephen~C. Johnson",
    1.10 +	title = "\textit{YACC: Yet Another Compiler-Compiler}",
    1.11 +	booktitle = "UNIX Programmer's Manual",
    1.12 +	volume = "2",
    1.13 +	year = "1979",
    1.14 +	note = "Available on the Internet: {\small\url{http://dinosaur.compilertools.net/yacc/yacc.ps} (2009-02-07)}",
    1.15 +}

     2.1 --- a/thesis/bib/websites.bib	Sat Feb 07 12:06:30 2009 +0100
     2.2 +++ b/thesis/bib/websites.bib	Sat Feb 07 14:47:27 2009 +0100
     2.3 @@ -341,3 +341,10 @@
     2.4  	howpublished = "{\small\url{http://en.wikipedia.org/w/index.php?title=HD_DVD&oldid=267253912} (2009-02-02)}",
     2.5  }
     2.6  
     2.7 +
     2.8 +@misc{ietf:homepage,
     2.9 +	author = "Internet Engeneering Task Force, The",
    2.10 +	title = "\textit{Homepage of the IETF}",
    2.11 +	howpublished = "{\small\url{http://ietf.org} (2000-02-07)}",
    2.12 +}
    2.13 +

     3.1 --- a/thesis/img/comm-classification.pic	Sat Feb 07 12:06:30 2009 +0100
     3.2 +++ b/thesis/img/comm-classification.pic	Sat Feb 07 14:47:27 2009 +0100
     3.3 @@ -20,7 +20,7 @@
     3.4  
     3.5  down
     3.6  row("email" "SMS",  "voice mail" "video messages")
     3.7 -row("instant messaging" "chat",  "VoIP" "video conferencing")
     3.8 +row("Instant Messaging" "chat",  "VoIP" "video conferencing")
     3.9  
    3.10  marker_top(1st [].B1, "written")
    3.11  marker_top(1st [].B2, "recorded")

     4.1 --- a/thesis/img/email-swot.pic	Sat Feb 07 12:06:30 2009 +0100
     4.2 +++ b/thesis/img/email-swot.pic	Sat Feb 07 14:47:27 2009 +0100
     4.3 @@ -19,8 +19,8 @@
     4.4  
     4.5  
     4.6  down
     4.7 -row("standard" "modular" "extensible",  "")
     4.8 -row("large data transfer" "too big for phone",  "spam")
     4.9 +row("standard" "modular" "extensible",  "\(em")
    4.10 +row("large data transfers" "complex networks",  "spam")
    4.11  
    4.12  marker_bot(last [].B1, "" "opportunities" "of the market")
    4.13  marker_bot(last [].B2, "" "threats" "of the market")

     5.1 --- a/thesis/img/masqmail-arch-new.pic	Sat Feb 07 12:06:30 2009 +0100
     5.2 +++ b/thesis/img/masqmail-arch-new.pic	Sat Feb 07 14:47:27 2009 +0100
     5.3 @@ -8,9 +8,9 @@
     5.4  
     5.5  I: [
     5.6  down
     5.7 -I1: ellipse "sendmail"
     5.8 +I1: ellipse "smtpd"
     5.9  move 0.2
    5.10 -I2: ellipse "smtpd"
    5.11 +I2: ellipse "sendmail"
    5.12  move 0.2
    5.13  I3: ellipse "..."
    5.14  ]
    5.15 @@ -31,9 +31,9 @@
    5.16  
    5.17  O: [
    5.18  down
    5.19 -O1: ellipse "pipe"
    5.20 +O1: ellipse "smtp"
    5.21  move 0.2
    5.22 -O2: ellipse "smtp"
    5.23 +O2: ellipse "pipe"
    5.24  move 0.2
    5.25  O3: ellipse "..."
    5.26  ]

     6.1 --- a/thesis/img/masqmail-typical-usage.pic	Sat Feb 07 12:06:30 2009 +0100
     6.2 +++ b/thesis/img/masqmail-typical-usage.pic	Sat Feb 07 14:47:27 2009 +0100
     6.3 @@ -39,7 +39,7 @@
     6.4  
     6.5  move to last [].e
     6.6  
     6.7 -move
     6.8 +move 0.5
     6.9  
    6.10  
    6.11  [

     7.1 --- a/thesis/img/proxy-setup.pic	Sat Feb 07 12:06:30 2009 +0100
     7.2 +++ b/thesis/img/proxy-setup.pic	Sat Feb 07 14:47:27 2009 +0100
     7.3 @@ -12,7 +12,7 @@
     7.4  
     7.5  P25: box wid 0.3 ht 0.3 with .e at 0.40<L.nw,L.sw> "25"
     7.6  left
     7.7 -line <- externlen from P25.w "SMTP" "from extern"
     7.8 +line <- externlen from P25.w "SMTP" "from remote "
     7.9  
    7.10  right
    7.11  line -> right from P25.e "SMTP" ""
    7.12 @@ -25,13 +25,13 @@
    7.13  M2: box "masqmail"
    7.14  arrow linewid*1.8 from 0.20<M2.ne,M2.se> "SMTP" ""
    7.15  box wid 0.3 ht 0.3 ""
    7.16 -line -> externlen "SMTP" "to extern"
    7.17 +line -> externlen "SMTP" "to remote"
    7.18  arrow linewid*2/3 from 0.50<M2.ne,M2.se>
    7.19  box "pipe" ht 0.16 wid 0.4
    7.20  arrow right from 0.80<M2.ne,M2.se> then down 0.2
    7.21  "" "mailbox"
    7.22  
    7.23 -line <- down left from 0.75<M2.nw,M2.sw> "stdin"
    7.24 +line <- down left from 0.75<M2.nw,M2.sw> "" "" "   stdin"
    7.25  box invis ht 0.3 "" "sendmail" "command"
    7.26  
    7.27  

     8.1 --- a/thesis/img/stunnel.pic	Sat Feb 07 12:06:30 2009 +0100
     8.2 +++ b/thesis/img/stunnel.pic	Sat Feb 07 14:47:27 2009 +0100
     8.3 @@ -12,7 +12,7 @@
     8.4  line <- 1.0 left from P465.w "SMTP over TLS" "(encrypted)"
     8.5  box dashed "remote" "host"
     8.6  
     8.7 -spline -> from P465.e right 0.4 then to 0.5<P465.s, P25.n> then to P25.w-(0.4,0) then to P25.w "stunnel"
     8.8 +spline -> from P465.e right 0.4 then to 0.5<P465.s, P25.n> then to P25.w-(0.4,0) then to P25.w "" "stunnel                       "
     8.9  
    8.10  right
    8.11  line -> 0.5 right from P25.e "SMTP" "(unencrypted)"

     9.1 --- a/thesis/tbl/mta-market-share.tbl	Sat Feb 07 12:06:30 2009 +0100
     9.2 +++ b/thesis/tbl/mta-market-share.tbl	Sat Feb 07 14:47:27 2009 +0100
     9.3 @@ -1,7 +1,7 @@
     9.4  \begin{tabular}[hbt]{| r || p{0.16\textwidth} r | p{0.16\textwidth} r | p{0.16\textwidth} r |}
     9.5  	\hline
     9.6  	\# &
     9.7 -Bernstein & 2001 &
     9.8 +\person{Bernstein} & 2001 &
     9.9  O'ReillyNet & 2007 &
    9.10  MailRadar & ? \\
    9.11  	\hline \hline

    10.1 --- a/thesis/tex/2-MarketAnalysis.tex	Sat Feb 07 12:06:30 2009 +0100
    10.2 +++ b/thesis/tex/2-MarketAnalysis.tex	Sat Feb 07 14:47:27 2009 +0100
    10.3 @@ -22,19 +22,19 @@
    10.4  Electronic communication technologies can be divided in synchronous and asynchronous communication. Synchronous communication is direct dialog with little delay. Telephone conversation is an example. Asynchronous communication consists of independent messages. Dialogs are possible as well, but not in the same direct fashion. These two groups can also be split by the time which is needed for data delivery. Synchronous communication requires nearly real-time delivery, whereas for asynchronous communication message delivery times of several seconds or minutes are sufficient.
    10.5  \index{electronic communication!classification of}
    10.6  
    10.7 -Another possible separation is to distinguish recorded and written information. Recorded information, like audio or video data, is accessible only in a linear way by spooling and replay. Written information, on the other hand, can be accessed in arbitrary sequence, detail and speed.
    10.8 +Another possible separation is to distinguish recorded and written information. Recorded information, like audio or video data, is accessible only in a linear way by spooling and replay. Written information, on the other hand, can be accessed in arbitrary sequence, detail, and speed.
    10.9  
   10.10  \person{Lenke} and \person{Schmitz} use the same criteria to classify \emph{new media} \cite{lenke95}. They additionally divide into local and remote communication---the latter is presumed here---and by the number of communication participants. A classification by participant structure is omitted here, as communication technologies for many-to-many communication (like chat rooms) are usable for one-to-one (private chat) too, and ones for one-to-one (email) are usable for many-to-many (mailing lists).
   10.11  
   10.12 -Figure~\ref{fig:comm-classification} shows a classification of communication technologies by the properties synchronous/asynchronous and written/recorded. Email and \NAME{SMS} are examples for written and asynchronous communication; \NAME{IM} and chats are ones for written but synchronous communication. Voice mail and video messages stand as examples for recorded asynchronous communication. VoIP represents recorded synchronous communication.
   10.13 +Figure~\ref{fig:comm-classification} shows a classification of communication technologies by the properties synchronous/asynchronous and written/recorded. Email and \NAME{SMS} are examples for written and asynchronous communication; \NAME{IM} and chats are ones for written but synchronous communication. Voice mail and video messages stand as examples for recorded asynchronous communication. \NAME{VoIP} represents recorded synchronous communication.
   10.14  
   10.15  \begin{figure}
   10.16  	\begin{center}
   10.17  		\includegraphics[scale=0.75]{img/comm-classification.eps}
   10.18  	\end{center}
   10.19 -	\caption{Classification of electronic communication}
   10.20 +	\caption{Classification of electronic communication technologies}
   10.21  	\label{fig:comm-classification}
   10.22 -	\index{figure!Classification of electronic communication}
   10.23 +	\index{figure!Classification of electronic communication technologies}
   10.24  \end{figure}
   10.25  
   10.26  One might be surprised to find Instant \emph{Messaging} not in the group of \emph{message} communication. Instant Messaging could be put in both groups because it allows asynchronous communication additional to being a chat system. The reasons why it is classified as dialog communication are its primary use for dialog communication and the very fast---instant---delivery time.
   10.27 @@ -174,9 +174,9 @@
   10.28  
   10.29  \subsubsection*{Opportunities}
   10.30  
   10.31 -Opportunities of the market are large data transfers, originating in multimedia content, which becomes popular. If email is used as basis for Unified Messaging, lots of voice and video mail will be transferred. Email is weak related to this kind of data: The data needs to be encoded to \NAME{ASCII} which stresses mail servers a lot.
   10.32 -%fixme: ref to store-and-forward
   10.33 +Opportunities of the market are large data transfers, originating in multimedia content, which becomes popular. If email is used as basis for Unified Messaging, lots of voice and video mail will be transferred. Email is weak related to this kind of data: The data needs to be encoded to \NAME{ASCII} which stresses mail servers a lot. Additionally a lot of traffic is generated by the \name{store-and-forward} transfer, which \SMTP\ uses.
   10.34  \index{um}
   10.35 +\index{store-and-forward}
   10.36  
   10.37  The use of different hardware to access mail is another opportunity of the market. But as more hardware gets involved, the networks become more complex. Thus the need for more software and infrastructure to transfer mail within the growing network might be a weakness of the email system. %fixme: think about that
   10.38  

    11.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 12:06:30 2009 +0100
    11.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 14:47:27 2009 +0100
    11.3 @@ -73,7 +73,7 @@
    11.4  	\label{fig:mta-channels}
    11.5  \end{figure}
    11.6  
    11.7 -An overview on incoming and outgoing channels which are required for an \MTA, gives figure~\ref{fig:mta-channels}.
    11.8 +An overview on incoming and outgoing channels which are required for an \MTA, gives figure~\ref{fig:mta-channels}. The reader may want to compare this diagram with \masqmail's incoming and outgoing channels, which are depicted in figure~\ref{fig:masqmail-channels} on page~\pageref{fig:masqmail-channels}.
    11.9  
   11.10  %fixme: write about submission (port 587)
   11.11  
   11.12 @@ -128,7 +128,7 @@
   11.13  \index{open relay}
   11.14  \index{spam}
   11.15  
   11.16 -Several ways to restrict access are available. The most simple one is restriction by the \NAME{IP} address. No extra complexity is added this way but the \NAME{IP} addresses need to be static or within known ranges. This approach is often used to allow relaying for local nets. The access check can be done by the \MTA\ or by a guard (e.g.\ \NAME{TCP} \name{Wrappers}) before. The main advantage here is the minimal setup and maintenance work needed. This kind of access restriction is important to be implemented.
   11.17 +Several ways to restrict access are available. The most simple one is restriction by the \NAME{IP} address. No extra complexity is added this way but the \NAME{IP} addresses need to be static or within known ranges. This approach is often used to allow relaying for local nets. The access check can be done by the \MTA\ or by a guard (e.g.\ \NAME{TCP} \name{Wrappers} \cite{venema92}) before. The main advantage here is the minimal setup and maintenance work needed. This kind of access restriction is important to be implemented.
   11.18  \index{access restriction}
   11.19  
   11.20  This authentication based on \NAME{IP} addresses is impossible in situations where hosts with changing \NAME{IP} addresses, that are not part of a known sub net, need access. Then a authentication mechanism based on some \emph{secret} is required. Three common approaches exist:
   11.21 @@ -283,7 +283,7 @@
   11.22  
   11.23  \paragraph{\RG\,6: Testability}
   11.24  \index{testability}
   11.25 -Good testability make maintenance easier too, because functionality is directly verifiable when changes are done, thus removing the uncertainty. Modularized software makes testing easier, because parts can be tested without external influences. \person{Spinellis} sees testability as a sub-quality of maintainability.
   11.26 +Good testability make maintenance easier too, because functionality is directly verifiable when changes are done, thus removing the uncertainty. Modularized software makes testing easier, because parts can be tested without external influences. \person{Spinellis} sees testability as a sub-quality of maintainability \cite{spinellis06}.
   11.27  
   11.28  
   11.29  \paragraph{\RG\,7: Performance}
   11.30 @@ -307,7 +307,7 @@
   11.31  
   11.32  \paragraph{\RG\,10: Usability}
   11.33  \index{usability}
   11.34 -Usability, not mentioned by \person{Hafiz} (he focuses on architecture) but by \person{Spinellis} and \person{Kan}, is a property which is 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; 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 the focus should be on the most common form of configuration: choosing one of several common setups.
   11.35 +Usability, not mentioned by \person{Hafiz} \cite{hafiz05} (he focuses on architecture) but by \person{Spinellis} \cite{spinellis06} and \person{Kan} \cite{kan03}, is a property which is 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; 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 the focus should be on the most common form of configuration: choosing one of several common setups.
   11.36  
   11.37  %fixme: << masqmail as portable app? >>
   11.38  

    12.1 --- a/thesis/tex/5-Improvements.tex	Sat Feb 07 12:06:30 2009 +0100
    12.2 +++ b/thesis/tex/5-Improvements.tex	Sat Feb 07 14:47:27 2009 +0100
    12.3 @@ -23,10 +23,10 @@
    12.4  
    12.5  This work requires changes mainly in three source files: \path{smtp_in.c}, \path{smtp_out.c}, and \path{conf.c}.
    12.6  
    12.7 -The first file includes the functionality for the \SMTP\ server. It needs to offer \NAME{STARTTLS} support to clients and needs to initiate the encryption when the client requests it. Additionally, the server should be able to insist on encryption before it accepts any message, if this is wished by the administrator. %fixme
    12.8 +The first file includes the functionality for the \SMTP\ server. It needs to offer \NAME{STARTTLS} support to clients and needs to initiate the encryption when the client requests it. Additionally, the server should be able to insist on encryption before it accepts any message
    12.9  \index{smtp}
   12.10  
   12.11 -The second file includes the functionality for the \SMTP\ client. It should start the encryption by issuing the \NAME{STARTTLS} keyword if the server supports it. It should be possible to send messages only over encrypted channels, if the administrator wants so. %fixme
   12.12 +The second file includes the functionality for the \SMTP\ client. It should start the encryption by issuing the \NAME{STARTTLS} keyword if the server supports it. It should be possible to send messages over encrypted channels only.
   12.13  
   12.14  The third file controls the configuration files. New configuration options need to be added. The encryption policy for incoming connections needs to be defined. Three choices seem necessary: no encryption, offer encryption, insist on encryption. The encryption policy for outgoing connections should be part of each route setup. The options are the same: never encrypt, encrypt if possible, insist on encryption.
   12.15  
   12.16 @@ -282,7 +282,7 @@
   12.17  \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.
   12.18  \index{qmail}
   12.19  
   12.20 -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} 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.
   12.21 +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.
   12.22  %fixme: ref for parser generator
   12.23  \index{parser generator}
   12.24  

    13.1 --- a/thesis/tex/rfcs.tex	Sat Feb 07 12:06:30 2009 +0100
    13.2 +++ b/thesis/tex/rfcs.tex	Sat Feb 07 14:47:27 2009 +0100
    13.3 @@ -1,6 +1,6 @@
    13.4  \chapter*{Requests for Comments}
    13.5  
    13.6 -\name{Requests for Comments} are the documents that propose or define Internet standards and best practices. They are controlled by the \name{Internet Engeneering Task Force} (short: \NAME{IETF}) and are available on their website: {\small\url{http://ietf.org}}\,.
    13.7 +\name{Requests for Comments} are the documents that propose or define Internet standards and best practices. They are controlled by the \name{Internet Engeneering Task Force} (short: \NAME{IETF}) \citeweb{ietf:homepage}.
    13.8  
    13.9  A particular \RFC\ is located at {\small\url{http://tools.ietf.org/rfc/rfcNNNN.txt}}\,, where ``\texttt{NNNN}'' is the four-digit number of that \RFC. For example is \RFC\,821 located at {\small\url{http://tools.ietf.org/rfc/rfc0821.txt}}\,.
   13.10