1.1 --- a/thesis/tex/0-preface.tex	Mon Jan 12 12:52:05 2009 +0100
     1.2 +++ b/thesis/tex/0-preface.tex	Mon Jan 12 12:52:36 2009 +0100
     1.3 @@ -79,11 +79,11 @@
     1.4  \\ &\\
     1.5  
     1.6  \citeweb{masqmail:homepage} &
     1.7 -is a reference to a website. Websites differ from documents as they are hardly a text written by some author, but a place where information is gathered.
     1.8 +is a reference to a website. Websites differ from documents as they are less of a text written by some author, but more a place where information is gathered.
     1.9  \\ &\\
    1.10  
    1.11  \RFC821 &
    1.12 -is a reference to the \name{Request For Comments} number 821. \RFC{}s are only referenced in this way. A list of relevant \RFC{}s and how they can be retrieved is available in the Appendix. %fixme: add ref
    1.13 +is a reference to the \name{Request For Comments}, here the one numbered 821. \RFC{}s are only referenced in this way. A list of relevant \RFC{}s and how they can be retrieved is available in the Appendix. %fixme: add ref
    1.14  \\ &\\
    1.15  
    1.16  \end{tabular}

     2.1 --- a/thesis/tex/1-Introduction.tex	Mon Jan 12 12:52:05 2009 +0100
     2.2 +++ b/thesis/tex/1-Introduction.tex	Mon Jan 12 12:52:36 2009 +0100
     2.3 @@ -17,20 +17,29 @@
     2.4  
     2.5  \subsubsection{Mail agents}
     2.6  
     2.7 +This thesis will frequently use the three terms: \MTA, \NAME{MUA}, and \NAME{MDA}. The name the three different kinds of software on which the email system depends. Here they are explained with references to the snail mail system one knows from everyday's life. Figure \ref{fig:mail-agents} shows the relation between them and the way an email message takes trough the system.
     2.8 +
     2.9  \paragraph{MTA}
    2.10 -\name{Mail Tranfer Agents} are for electronic mail what post offices are for snail mail. The basic job is to transport mail from senders to recipients, or more pedantic: from \MTA\ to \MTA. This is the definition of such kind of software, and this is how \MTA{}s are generally seen \cite[page 19]{dent04} \cite[pages 3-5]{hafiz05}. \MTA{}s are explained in more detail in chapter \ref{chap:mail-transfer-agents}.
    2.11 +\name{Mail Tranfer Agents} are for electronic mail what post offices are for snail mail. The basic job of an \MTA\ is to transport mail from senders to recipients, or more pedantic: from \MTA\ to \MTA. This is the definition of such kind of software, and this is how \MTA{}s are generally seen \cite[page 19]{dent04} \cite[pages 3-5]{hafiz05}. \MTA{}s are explained in more detail in chapter \ref{chap:mail-transfer-agents}.
    2.12  
    2.13  
    2.14  \paragraph{MUA}
    2.15 -\name{Mail User Agents} the software the user deals with. It is the program he uses to write and read email. The \NAME{MUA} passes outgoing mail to the next \MTA, and it displays the contents of the user's mailbox. Well known \NAME{MUA}s are \name{Mozilla Thunderbird} and \name{mutt} on \unix\ systems, and \name{Microsoft Outlook} on \name{Windows}.
    2.16 +\name{Mail User Agents} are the software the user deals with. He writes and reads email with it. The \NAME{MUA} passes outgoing mail to the nearest \MTA, and the \NAME{MUA} displays the contents of the user's mailbox. Well known \NAME{MUA}s are \name{Mozilla Thunderbird} and \name{mutt} on \unix\ systems, and \name{Microsoft Outlook} on \name{Windows}.
    2.17  
    2.18  
    2.19  \paragraph{MDA}
    2.20 -\name{Mail Delivery Agents} correspond to postmen in the real world. They receive mail, to recipients they are responsible for, from an \MTA, and deliver it to the mailboxes of the recipients. Many \MTA{}s include an own \NAME{MDA}, but specialized ones exist: \name{procmail} and \name{maildrop} are examples.
    2.21 +\name{Mail Delivery Agents} correspond to postmen in the real world. They receive mail, destinated to recipients they are responsible for, from an \MTA, and deliver it to the mailboxes of those recipients. Many \MTA{}s include an own \NAME{MDA}, but specialized ones exist: \name{procmail} and \name{maildrop} are examples.
    2.22  
    2.23 +\begin{figure}
    2.24 +	\begin{center}
    2.25 +		\includegraphics[scale=0.75]{img/mail-agents.eps}
    2.26 +	\end{center}
    2.27 +	\caption{Mail agents and the way a mail message takes}
    2.28 +	\label{fig:mail-agents}
    2.29 +\end{figure}
    2.30  
    2.31  
    2.32 -<< structure diagram of an MTA (and of masqmail) >>
    2.33 +
    2.34  
    2.35  
    2.36  
    2.37 @@ -40,28 +49,29 @@
    2.38  
    2.39  A selection of important concepts of \SMTP\ is explained here.
    2.40  
    2.41 -First the \name{store and forward} transfer method. This means mail messages are sent from \MTA\ to \MTA\ until the final \MTA\ (the one which is responsible for the recipient) is reached. The message is gets stored for some time on each \MTA, until it is forwarded to the next \MTA.
    2.42 +First the \name{store and forward} transfer concept. This means mail messages are sent from \MTA\ to \MTA, until the final \MTA\ (the one which is responsible for the recipient) is reached. The message is gets stored for some time on each \MTA, until it is forwarded to the next \MTA.
    2.43  
    2.44 -This leads to the concept of \name{responsibility}. A mail message is always in the responsibility of one system. First it is the \NAME{MUA}. After it was transfered to the first \MTA, he takes the responsibility for the message over. The \NAME{MUA} can then delete its copy of the message. This is the same for each transfer, from \MTA\ to \MTA\ and finally from \MTA\ to the \NAME{MDA}, the message gets transfered and if this was successful, the responsibility for the message is transfered as well. The responsibility chain ends at the user's mailbox, where he himself has control on the message again.
    2.45 +This leads to the concept of \name{responsibility}. A mail message is always in the responsibility of one system. First it is the \NAME{MUA}. After it was transfered to the first \MTA, it takes the responsibility for the message over. The \NAME{MUA} can then delete its copy of the message. This is the same for each transfer, from \MTA\ to \MTA\ and finally from \MTA\ to the \NAME{MDA}, the message gets transfered and if the transfer was successful, the responsibility for the message is transfered as well. The responsibility chain ends at a user's mailbox, where he himself has control on the message.
    2.46  
    2.47 -A third concept is about failure handling. At any step on the way, an \MTA\ may get a message he is unable to handle. In such a case, this receiving \MTA\ will \name{reject} the message before it takes responsibility for it. The sending \MTA\ still has responsibility for the message and may try other ways of sending the message. If none succeeds, the \MTA\ will send a \name{bounce message} back to the original sender with information on the type of failure. Bounces are only sent if the failure is expected to be permanent, and if after many tries the transfer still was not successful.
    2.48 +A third concept is about failure handling. At any step on the way, an \MTA\ may receive a message it is unable to handle. In such a case, this receiving \MTA\ will \name{reject} the message before it takes responsibility for it. The sending \MTA\ still has responsibility for the message and may try other ways for sending the message. If none succeeds, the \MTA\ will send a \name{bounce message} back to the original sender with information on the type of failure. Bounces are only sent if the failure is expected to be permanent, or if the transfer still was unsuccessful after many tries.
    2.49  
    2.50  
    2.51  
    2.52  \subsubsection{Mail messages}
    2.53  
    2.54 -Mail messages consist of three parts that with defined format. It is defined in \RFC822, and the successors \RFC2822 and \RFC5322.
    2.55 +Mail messages consist of two parts with defined format. This format is specified in \RFC822, and the successors \RFC2822 and \RFC5322.
    2.56  
    2.57 -A message consists of \name{envelope} and \name{content}. This concept is derived from the real world, so it is easy to understand. The envelope is what is used to route the message from sender to recipient. It contains the sender's address and addresses of one or more recipients. Envelopes are generated (using mail header data) by \MTA{}s, the user has not to deal with them.
    2.58 +The two parts of a message are the \name{header} and the \name{body}. The header of an email message is similar to the header of a (formal) letter. It spans the first lines of the message up to the first empty line. The header consists of several lines, called \name{header lines} or simply \name{headers}. They specify the sender, the address(es) of the recipient(s), the date, and possibly further information. Their order is irrelevant. Headers are named after the colon separated start of those lines, for example the ``\texttt{Date:}'' header. A user may write the header himself, but normally the \NAME{MUA} does this job.
    2.59  
    2.60 -The content of the message is again split into two part: The \name{header} and the \name{body}. The header of an email message is similar to the header of a (formal) letter. It spans the first lines of the content up to the first empty line. The header consists of several lines, called \name{header lines} or simply \name{headers}. They specify the sender, the address(es) of the recipient(s), the date, and possibly further information. Their order is irrelevant. Headers are named after the colon separated start of those lines, for example the \texttt{Date:} header. This header can write the header himself, but normally the \NAME{MUA} does this job.
    2.61 +The body is the payload of the message. It is under full control of the user. From the view point of the \SMTP\ protocol, it must consist of only 7-bit \NAME{ASCII} text. But arbitrary content can be included by encoding it to 7-bit \NAME{ASCII}. \NAME{MIME} is the common \SMTP\ extension to handle such convertion automatically in \NAME{MUA}s.
    2.62  
    2.63 -Finally the body is the payload of the message. It is under full control of the user. From the view point of the \SMTP\ protocol, only 7-bit \NAME{ASCII} is allowed to in it, but arbitrary content can be included by encoding it to 7-bit \NAME{ASCII}. \NAME{MIME} is the common \SMTP\ extension to handle such convertion automatically in \NAME{MUA}s.
    2.64 -
    2.65 -Following is a sample mail message.
    2.66 +Following is a sample mail message with four header lines (\texttt{From:}, \texttt{To:}, \texttt{Date:}, and \texttt{Subject:}) and three lines of message body.
    2.67  
    2.68  \input{input/sample-email.txt}
    2.69  
    2.70 +Email messages are put into envelopes for transfer. This concept is derived from the real world, so it is easy to understand. The envelope is what is used to route the message from sender to recipient. It contains the sender's address and addresses of one or more recipients. Envelopes are generated by \MTA{}s, usually by using mail header data. The user has not to deal with them.
    2.71 +
    2.72 +The sample message would would lead to two envelopes, one from \name{markus@host01} to \name{alice@host02}, the other from \name{markus@host01} to \name{bob@host03}. Both envelopes would contain the same message. There is no difference to how it would be done for snail mail.
    2.73  
    2.74  
    2.75  
    2.76 @@ -180,9 +190,6 @@
    2.77  
    2.78  With \masqmail\ comes the small tool \path{mservdetect}; it helps setting up a configuration that uses the \name{mserver} system to detect the online state. Two other binaries get compiled for testing purposes: \path{readtest} and \path{smtpsend}. All three programs use \masqmail\ source code; they only add a file with a \verb+main()+ function each.
    2.79  
    2.80 -\masqmail\ lacks an interface to plug in modules with additional functionality. There exists no add-on or module system. The code is only separated by function to the various source files. Some functional parts can be included or excluded by defining symbols at compile time. Adding maildir support, means giving the option \verb+--enable-maildir+ to the \path{configure} call. This preserves the concerning code to get removed by the preprocessor. Unfortunately the \verb+#ifdef+s are scattered through all the source, leading to a code that is hard to read.
    2.81 -%fixme: refer to ifdef-considered-harmful ?
    2.82 -
    2.83  
    2.84  
    2.85  \subsubsection*{Features}