1.1 --- a/thesis/tex/1-Introduction.tex	Sun Jan 11 20:20:41 2009 +0100
     1.2 +++ b/thesis/tex/1-Introduction.tex	Sun Jan 11 20:21:35 2009 +0100
     1.3 @@ -7,16 +7,65 @@
     1.4  
     1.5  
     1.6  
     1.7 -\section{What's an MTA?}
     1.8  
     1.9 -The basic job of a \mta\ is to transport mail from senders to recipients. 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}.
    1.10  
    1.11 -An \MTA\ therefore needs at least a mail receiving facility and a mail sending facility.
    1.12 +
    1.13 +\section{Email prerequisites}
    1.14 +
    1.15 +email and everything is defined in RFCs
    1.16 +
    1.17 +
    1.18 +\subsubsection{Mail agents}
    1.19 +
    1.20 +\paragraph{MTA}
    1.21 +\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}.
    1.22 +
    1.23 +
    1.24 +\paragraph{MUA}
    1.25 +\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}.
    1.26 +
    1.27 +
    1.28 +\paragraph{MDA}
    1.29 +\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.
    1.30 +
    1.31 +
    1.32  
    1.33  << structure diagram of an MTA (and of masqmail) >>
    1.34  
    1.35  
    1.36  
    1.37 +\subsubsection{Mail transfer with SMTP}
    1.38 +
    1.39 +Today most of the email is transfered using the \name{Simple Mail Transfer Protocol} (short: \SMTP), which is defined in \RFC821 and the successors \RFC2821 and \RFC5321. A good entry point for further information is \citeweb{wikipedia:smtp}.
    1.40 +
    1.41 +A selection of important concepts of \SMTP\ is explained here.
    1.42 +
    1.43 +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.
    1.44 +
    1.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, 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.
    1.46 +
    1.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.
    1.48 +
    1.49 +
    1.50 +
    1.51 +\subsubsection{Mail messages}
    1.52 +
    1.53 +Mail messages consist of three parts that with defined format. It is defined in \RFC822, and the successors \RFC2822 and \RFC5322.
    1.54 +
    1.55 +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.
    1.56 +
    1.57 +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.
    1.58 +
    1.59 +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.
    1.60 +
    1.61 +Following is a sample mail message.
    1.62 +
    1.63 +\input{input/sample-email.txt}
    1.64 +
    1.65 +
    1.66 +
    1.67 +
    1.68 +
    1.69  
    1.70  
    1.71  \section{The \masqmail\ project}
    1.72 @@ -36,8 +85,11 @@
    1.73  
    1.74  The program's new homepage \citeweb{masqmail:homepage} provides further information about this \MTA.
    1.75  
    1.76 +<< specify the really important external documents here >> %FIXME
    1.77  
    1.78 -\subsubsection*{Target field}
    1.79 +
    1.80 +
    1.81 +\subsection{Target field / When to use \masqmail}
    1.82  
    1.83  Its original author, Oliver \person{Kurth}, sees \masqmail\ so:
    1.84  \begin{quote}
    1.85 @@ -58,34 +110,6 @@
    1.86  
    1.87  
    1.88  
    1.89 -\subsubsection*{Typical usage}
    1.90 -This section describes situations that make senseful use of \masqmail.
    1.91 -
    1.92 -A home network consisting of some workstations without a server. The network is connected to the internet by dial-up or broadband. Going online is initiated by computers inside the local net. \NAME{IP} addresses change at least once every day.
    1.93 -
    1.94 -Every workstation would be equiped with \masqmail. Mail transfer within the same machine or within the local net works straight forward. Outgoing mail to the internet is sent, to the concerning \NAME{ISP} for relaying, whenever the router goes online. Receiving of mail from outside needs to be done by a mail fetch program, like the \masqmail\ internal \NAME{POP3} client or \name{fetchmail} for example. The configuration for \masqmail\ would be the same on every computer, except the hostname.
    1.95 -
    1.96 -For the same network but having a server, one could have \masqmail\ running on the server and using simple forwarders (see \ref{subsec:relay-only}) to the server on the workstations. This setup does only support mail transfer to the server, but not back to a workstation; also sending mail to another user on the same workstation is not possible.
    1.97 -
    1.98 -A better setup is to run \masqmail\ on every machine %FIXME
    1.99 -
   1.100 -
   1.101 -\subsubsection{Online detection and routes}
   1.102 -\label{sec:masqmail-routes}
   1.103 -
   1.104 ----
   1.105 -
   1.106 -As \masqmail\ is focused on non-permanent Internet connections, online state can be queried by three methods: reading from a file, reading the output of a command, or by asking an \name{mserver}. Each method may return a string indicating one of the available routes being online, or returning nothing to indicate offline state.
   1.107 -
   1.108 -Delivery to recipients on the local host or in local nets is done at once; delivery to recipients on the Internet is only done when being online, and queued otherwise. Each online route may have a different mail server to which mail is relayed. Return address headers are modified appropriate if wished.
   1.109 -
   1.110 ----
   1.111 -
   1.112 -\masqmail\ focuses on non-permanent online connections, thus a concept of online routes is used. One may configure any number of routes to send mail. Each route can have criteria, like matching \texttt{From:} or \texttt{To:} headers, to determine if some message is allowed to be sent over it. Mail to destinations outside the local network gets queued until an online connections is available.
   1.113 -
   1.114 -
   1.115 -
   1.116 -
   1.117  
   1.118  \subsubsection*{\masqmail's main goal}
   1.119  
   1.120 @@ -114,12 +138,36 @@
   1.121  
   1.122  
   1.123  
   1.124 +\subsubsection*{Typical usage}
   1.125 +This section describes situations that make senseful use of \masqmail.
   1.126  
   1.127 +A home network consisting of some workstations without a server. The network is connected to the internet by dial-up or broadband. Going online is initiated by computers inside the local net. \NAME{IP} addresses change at least once every day.
   1.128  
   1.129 +Every workstation would be equiped with \masqmail. Mail transfer within the same machine or within the local net works straight forward. Outgoing mail to the internet is sent, to the concerning \NAME{ISP} for relaying, whenever the router goes online. Receiving of mail from outside needs to be done by a mail fetch program, like the \masqmail\ internal \NAME{POP3} client or \name{fetchmail} for example. The configuration for \masqmail\ would be the same on every computer, except the hostname.
   1.130  
   1.131 +For the same network but having a server, one could have \masqmail\ running on the server and using simple forwarders (see \ref{subsec:relay-only}) to the server on the workstations. This setup does only support mail transfer to the server, but not back to a workstation; also sending mail to another user on the same workstation is not possible.
   1.132  
   1.133 +A better setup is to run \masqmail\ on every machine %FIXME
   1.134  
   1.135 -\section{Existing code base}
   1.136 +
   1.137 +
   1.138 +
   1.139 +
   1.140 +
   1.141 +\subsection{When not to use \masqmail}
   1.142 +
   1.143 +...
   1.144 +
   1.145 +
   1.146 +
   1.147 +
   1.148 +
   1.149 +
   1.150 +
   1.151 +
   1.152 +
   1.153 +
   1.154 +\subsection{Features}
   1.155  
   1.156  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.
   1.157  
   1.158 @@ -156,52 +204,64 @@
   1.159  
   1.160  
   1.161  
   1.162 +\subsubsection*{Online detection and routes}
   1.163 +\label{sec:masqmail-routes}
   1.164  
   1.165 +---
   1.166  
   1.167 +As \masqmail\ is focused on non-permanent Internet connections, online state can be queried by three methods: reading from a file, reading the output of a command, or by asking an \name{mserver}. Each method may return a string indicating one of the available routes being online, or returning nothing to indicate offline state.
   1.168  
   1.169 +Delivery to recipients on the local host or in local nets is done at once; delivery to recipients on the Internet is only done when being online, and queued otherwise. Each online route may have a different mail server to which mail is relayed. Return address headers are modified appropriate if wished.
   1.170  
   1.171 +---
   1.172  
   1.173 +\masqmail\ focuses on non-permanent online connections, thus a concept of online routes is used. One may configure any number of routes to send mail. Each route can have criteria, like matching \texttt{From:} or \texttt{To:} headers, to determine if some message is allowed to be sent over it. Mail to destinations outside the local network gets queued until an online connections is available.
   1.174  
   1.175  
   1.176 -\subsubsection*{What makes it special}
   1.177 +
   1.178 +
   1.179 +
   1.180 +
   1.181 +
   1.182 +
   1.183 +
   1.184 +
   1.185 +\section{Why \masqmail?}
   1.186  
   1.187  As main advantage, \masqmail\ makes it easy to set up an \MTA\ on workstations or notebooks without the need to do complex configuration or to be an mail server expert.
   1.188  
   1.189  Workstations use %FIXME
   1.190  
   1.191  \textbf{Alternatives?}
   1.192 -% http://anfi.homeunix.org/sendmail/dialup10.html
   1.193 + http://anfi.homeunix.org/sendmail/dialup10.html
   1.194  
   1.195  
   1.196 -
   1.197 -<< explain why masqmail is old and why it is interesting/important however! >> %FIXME
   1.198 +<< explain why masqmail is old and why it is interesting/important however! >>
   1.199  
   1.200  << why is it worth to revive masqmail? >>
   1.201  
   1.202  
   1.203  
   1.204 +
   1.205 +
   1.206 +
   1.207 +
   1.208  \section{Problems to solve}
   1.209  
   1.210 -<< what problems has masqmail? >>  %FIXME
   1.211 +<< what problems has masqmail? >>
   1.212  
   1.213 -<< what's the intention of this document? >>  %FIXME
   1.214 +<< what's the intention of this document? >>
   1.215  
   1.216 -<< why is it worth the effort? >>  %FIXME
   1.217 +<< why is it worth the effort? >>
   1.218  
   1.219  
   1.220 -\section{What is not covered here}
   1.221 +
   1.222 +
   1.223 +
   1.224 +\section{Delimitation}
   1.225  
   1.226  << limit against stuff not covered here >>
   1.227  
   1.228  
   1.229 -\section{Further reading}
   1.230  
   1.231  
   1.232 -<< specify the really important external documents here >> %FIXME
   1.233 -
   1.234 -<< write about the bundled CD, and tell what's included >> %FIXME
   1.235 -
   1.236 -\NAME{RFC}s, other books, source code, websites
   1.237 -
   1.238 -
   1.239 -