docs/diploma
changeset 373:d51894e48762
started indexing; mta -> MTA (many small changes)
| author | meillo@marmaro.de |
|---|---|
| date | Sat, 31 Jan 2009 21:39:53 +0100 |
| parents | 6477e7827617 |
| children | 3445852ed736 |
| files | thesis/scripts/improve-index.awk 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/thesis.sty |
| diffstat | 7 files changed, 111 insertions(+), 63 deletions(-) [+] |
line diff
1.1 --- a/thesis/scripts/improve-index.awk Sat Jan 31 20:07:58 2009 +0100 1.2 +++ b/thesis/scripts/improve-index.awk Sat Jan 31 21:39:53 2009 +0100 1.3 @@ -3,19 +3,65 @@ 1.4 # improve the index 1.5 1.6 BEGIN{ 1.7 - ie["mta"] = "mail transfer agent (\\MTA)"; 1.8 - ie["mua"] = "mail user agent (\\MUA)"; 1.9 - ie["smtp"] = "simple mail transfer protocol (\\SMTP)"; 1.10 - ie["ietf"] = "Internet Engineering Task Force (\\NAME{IETF})"; 1.11 + e["mta"] = "mail transfer agent (\\NAME{MTA})"; 1.12 + e["mua"] = "mail user agent (\\NAME{MUA})"; 1.13 + e["mda"] = "mail delivery agent (\\NAME{MUA})"; 1.14 + e["smtp"] = "simple mail transfer protocol (\\NAME{SMTP})"; 1.15 + e["ietf"] = "Internet Engineering Task Force (\\NAME{IETF})"; 1.16 + e["debian"] = "Debian"; 1.17 + e["ascii"] = "ascii@\\NAME{ASCII}"; 1.18 + e["gpl"] = "General Public License (\\NAME{GPL})"; 1.19 + 1.20 + e["Oliver Kurth"] = e["Kurth"] = "Kurth@\\textsc{Kurth, Oliver}"; 1.21 + e["Adam Back"] = e["Back"] = "Back@\\textsc{Back, Adam}"; 1.22 + e["Eric Allman"] = e["Allman"] = "Allman@\\textsc{Allman, Eric}"; 1.23 + e["Stas Bekman"] = e["Bekman"] = "Bekman@\\textsc{Bekman, Stas}"; 1.24 + e["Daniel J. Bernstein"] = e["Bernstein"] = "Bernstein@\\textsc{Bernstein, Daniel J.}"; 1.25 + e["Bryan Costales"] = e["Costales"] = "Costales@\\textsc{Costales, Bryan}"; 1.26 + e["George Candea"] = e["Candea"] = "Candea@\\textsc{Candea, George}"; 1.27 + e["Dan Shearer"] = e["Shearer"] = "Shearer@\\textsc{Shearer, Dan}"; 1.28 + e["Dave Sill"] = e["Sill"] = "Sill@\\textsc{Sill, Dave}"; 1.29 + e["David A. Wheeler"] = e["Wheeler"] = "Wheeler@\\textsc{Wheeler, David A.}"; 1.30 + e["Kyle D. Dent"] = e["Dent"] = "Dent@\\textsc{Dent, Kyle D.}"; 1.31 + e["Derek Broughton"] = e["Broughton"] = "Broughton@\\textsc{Broughton, Derek}"; 1.32 + e["Doug McIlroy"] = e["McIlroy"] = "McIlroy@\\textsc{McIlroy, Doug}"; 1.33 + e["Peter Eisentraut"] = e["Eisentraut"] = "Eisentraut@\\textsc{Eisentraut, Peter}"; 1.34 + e["Tony Finch"] = e["Finch"] = "Finch@\\textsc{Finch, Tony}"; 1.35 + e["Armando Fox"] = e["Fox"] = "Fox@\\textsc{Fox, Armando}"; 1.36 + e["Frederik Vermeulen"] = e["Vermeulen"] = "Vermeulen@\\textsc{Vermeulen, Frederik}"; 1.37 + e["Marc G. Graff"] = e["Graff"] = "Graff@\\textsc{Graff, Marc G.}"; 1.38 + e["Munawar Hafiz"] = e["Hafiz"] = "Hafiz@\\textsc{Hafiz, Munawar}"; 1.39 + e["Philip Hazel"] = e["Hazel"] = "Hazel@\\textsc{Hazel, Philip}"; 1.40 + e["Ian R. Justman"] = e["Justman"] = "Justman@\\textsc{Justman, Ian R.}"; 1.41 + e["Jesse Freund"] = e["Freund"] = "Freund@\\textsc{Freund, Jesse}"; 1.42 + e["Jon Postel"] = e["Postel"] = "Postel@\\textsc{Postel, Jon}"; 1.43 + e["Jonathan de Boyne Pollard"] = e["de Boyne Pollard"] = "de Boyne Pollard@\\textsc{de Boyne Pollard, Jonathan}"; 1.44 + e["Stephen H. Kan"] = e["Kan"] = "Kan@\\textsc{Kan, Stephen H.}"; 1.45 + e["Brian W. Kernighan"] = e["Kernighan"] = "Kernighan@\\textsc{Kernighan, Brian W.}"; 1.46 + e["Nils Lenke"] = e["Lenke"] = "Lenke@\\textsc{Lenke, Nils}"; 1.47 + e["Markus Schnalke"] = e["Schnalke"] = "Schnalke@\\textsc{Schnalke, Markus}"; 1.48 + e["Michael Osterman"] = e["Osterman"] = "Osterman@\\textsc{Osterman, Michael}"; 1.49 + e["Rob Pike"] = e["Pike"] = "Pike@\\textsc{Pike, Rob}"; 1.50 + e["Eric S. Raymond"] = e["Raymond"] = "Raymond@\\textsc{Raymond, Eric S.}"; 1.51 + e["Dennis Ritchie"] = e["Ritchie"] = "Ritchie@\\textsc{Ritchie, Dennis}"; 1.52 + e["Peter Schmitz"] = e["Schmitz"] = "Schmitz@\\textsc{Schmitz, Peter}"; 1.53 + e["Ken Simpson"] = e["Simpson"] = "Simpson@\\textsc{Simpson, Ken}"; 1.54 + e["Diomidis Spinellis"] = e["Spinellis"] = "Spinellis@\\textsc{Spinellis, Diomidis}"; 1.55 + e["Andrew S. Tanenbaum"] = e["Tanenbaum"] = "Tanenbaum@\\textsc{Tanenbaum, Andrew S.}"; 1.56 + e["Kenneth R. van Wyk"] = e["van Wyk"] = "van Wyk@\\textsc{van Wyk, Kenneth R.}"; 1.57 + e["Wietse Venema"] = e["Venema"] = "Venema@\\textsc{Venema, Wietse}"; 1.58 } 1.59 1.60 + 1.61 + 1.62 { 1.63 cur = $0 1.64 - sub("[^{]*{", "", cur); 1.65 - sub("[}!].*", "", cur); 1.66 - if (ie[cur]) { 1.67 - #print ie[cur]; 1.68 - sub("{[^}!]*", "{" ie[cur]); 1.69 + gsub(/\\nobreakspace \{\}/, " ", cur); 1.70 + gsub(/\\ /, " ", cur); 1.71 + sub(/[^{]*{/, "", cur); 1.72 + sub(/[}!].*/, "", cur); 1.73 + if (e[cur]) { 1.74 + sub(/{[^}!]*/, "{" e[cur]); 1.75 } 1.76 print; 1.77 }
2.1 --- a/thesis/tex/1-Introduction.tex Sat Jan 31 20:07:58 2009 +0100 2.2 +++ b/thesis/tex/1-Introduction.tex Sat Jan 31 21:39:53 2009 +0100 2.3 @@ -9,24 +9,28 @@ 2.4 2.5 \section{Email prerequisites} 2.6 2.7 -Electronic mail is a service on the Internet and thus, like other Internet services, defined and standardized by \RFC{}s under management of the \name{Internet Engineering Task Force} (short: \NAME{IETF}). \RFC{}s are highly technical documents and it is not required that the readers of this thesis are familiar with them. 2.8 +Electronic mail is a service on the Internet and thus, like other Internet services, defined and standardized by \name{Requests For Comments}\index{rfc} (short: \RFC{}s\index{rfc}) under management of the \name{Internet Engineering Task Force}\index{ietf} (short: \NAME{IETF}). \RFC{}s are highly technical documents and it is not required that the readers of this thesis are familiar with them. 2.9 2.10 This section gives an introduction into the basic internals of the email system in a low-technical language. It is intended to make the reader familiar with the essential concepts of email as they are essential throughout the thesis. 2.11 2.12 2.13 \subsubsection{Mail agents} 2.14 +\index{mail agents} 2.15 2.16 -This thesis will frequently use the three terms: \MTA, \NAME{MUA}, and \NAME{MDA}, naming the three different kinds of nodes of the email infrastructure. Here, they are explained with references to the ``snail mail'' system which is known from everyday life. Figure \ref{fig:mail-agents} shows the relation between those three mail agents and the way an email message takes when passing through the system. 2.17 +This thesis will frequently use the three terms: \MTA, \MUA{}, and \MDA{}, naming the three different kinds of nodes of the email infrastructure. Here, they are explained with references to the ``snail mail'' system which is known from everyday life. Figure \ref{fig:mail-agents} shows the relation between those three mail agents and the way an email message takes when passing through the system. 2.18 2.19 \begin{description} 2.20 \item[\MTA:] 2.21 +\index{mta} 2.22 \name{Mail Transfer Agents} are the post offices for electronic mail. The basic job of an \MTA\ is to transport mail from senders to recipients, or more pedantic: from \MTA\ to \MTA. \sendmail, \exim, \qmail, \postfix, and, of course, \masqmail\ are \MTA{}s. \MTA{}s are explained in more detail in chapter \ref{chap:mail-transfer-agents}. 2.23 2.24 -\item[\NAME{MUA}:] 2.25 -\name{Mail User Agents} are the software users deal with. A user writes and reads email with it. The \NAME{MUA} passes outgoing mail to the nearest \MTA. Also 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.26 +\item[\MUA{}:] 2.27 +\index{mua} 2.28 +\name{Mail User Agents} are the software users deal with. A user writes and reads email with it. The \MUA{} passes outgoing mail to the nearest \MTA. Also the \MUA{} displays the contents of the user's mailbox. Well known \MUA{}s are \name{Mozilla Thunderbird} and \name{mutt} on \unix\ systems, and \name{Microsoft Outlook} on \name{Windows}. 2.29 2.30 -\item[\NAME{MDA}:] 2.31 -\name{Mail Delivery Agents} correspond to postmen in the real world. They receive mail, destined 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 independent ones exist: \name{procmail} and \name{maildrop} are examples. 2.32 +\item[\MDA{}:] 2.33 +\index{mda} 2.34 +\name{Mail Delivery Agents} correspond to postmen in the real world. They receive mail, destined to recipients they are responsible for, from an \MTA, and deliver it to the mailboxes of those recipients. Many \MTA{}s include an own \MDA{}, but independent ones exist: \name{procmail} and \name{maildrop} are examples. 2.35 \end{description} 2.36 2.37 \begin{figure} 2.38 @@ -44,35 +48,35 @@ 2.39 2.40 \subsubsection{Mail transfer with SMTP} 2.41 2.42 -Today most of the email is transferred using the \name{Simple Mail Transfer Protocol} (short: \SMTP), which is defined in \RFC\,821 and the successors \RFC\,2821 and \RFC\,5321. A good entry point for further information is \citeweb{wikipedia:smtp}. 2.43 +Today most of the email is transferred using the \name{Simple Mail Transfer Protocol}\index{smtp} (short: \SMTP), which is defined in \RFC\,821 and the successors \RFC\,2821 and \RFC\,5321. A good entry point for further information is \citeweb{wikipedia:smtp}. 2.44 2.45 -A selection of important concepts of \SMTP\ is explained here. 2.46 +A selection of important concepts of \SMTP\index{smtp!concepts of} is explained here. 2.47 2.48 -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.49 +First the \name{store and forward}\index{smtp!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.50 2.51 -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}. When it is transferred to an \MTA, this \MTA\ takes over the responsibility for the message too. 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 transferred and if the transfer was successful, the responsibility for the message is transferred as well. The responsibility chain ends at a user's mailbox where he himself has control on the message. 2.52 +This leads to the concept of \name{responsibility}\index{smtp!responsibility}. A mail message is always in the responsibility of one system. First it is the \MUA\index{mua}. When it is transferred to an \MTA, this \MTA\ takes over the responsibility for the message too. The \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 \MDA{}---the message gets transferred and if the transfer was successful, the responsibility for the message is transferred as well. The responsibility chain ends at a user's mailbox where he himself has control on the message. 2.53 2.54 -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.55 +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}\index{smtp!rejecting} 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}\index{smtp!bouncing} 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.56 2.57 2.58 2.59 \subsubsection{Mail messages} 2.60 2.61 -Mail messages consist of text in a specific format. This format is specified in \RFC\,822, and the successors \RFC\,2822 and \RFC\,5322. 2.62 +Mail messages\index{mail message} consist of text in a specific format. This format is specified in \RFC\,822, and the successors \RFC\,2822 and \RFC\,5322. 2.63 2.64 -A message has two parts, 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 recipient(s), the date, and possibly further information. Their order is irrelevant. Headers are named like 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.65 +A message has two parts, the \name{header}\index{mail message!header} and the \name{body}\index{mail message!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}\index{mail message!header lines} or simply \name{headers}. They specify the sender, the recipient(s), the date, and possibly further information. Their order is irrelevant. Headers are named like the colon-separated start of those lines, for example the ``\texttt{Date:}'' header. A user may write the header himself but normally the \MUA{} does this job. 2.66 2.67 -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 conversion automatically in \NAME{MUA}s. 2.68 +The body is the payload\index{mail message!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}\index{ascii} text. But arbitrary content can be included by encoding it to 7-bit \NAME{ASCII}. \NAME{MIME}\index{mime} is the common \SMTP\ extension to handle such conversion automatically in \MUA{}s. 2.69 2.70 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.71 2.72 -\codeinput{input/sample-email.txt} 2.73 +\codeinput{input/sample-email.txt}\index{mail message!example} 2.74 2.75 -Email messages are put into \name{envelopes} for transfer. This concept is also derived from the real world so it is easy to understand. The envelope 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 from mail header data. The user has not to deal with them. 2.76 +Email messages are put into \name{envelopes}\index{mail message!envelope} for transfer. This concept is also derived from the real world so it is easy to understand. The envelope 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 from mail header data. The user has not to deal with them. 2.77 2.78 Each \MTA\ on the way reads envelopes it receives and generates new ones. If a message has recipients on different hosts, then the message gets copied and sent within multiple envelopes, one for each host. 2.79 2.80 -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. 2.81 +The sample message would would lead to two envelopes\index{mail message!more 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. 2.82 2.83 2.84 2.85 @@ -82,11 +86,11 @@ 2.86 \section{The \masqmail\ project} 2.87 \label{sec:masqmail} 2.88 2.89 -The \masqmail\ project was initiated by \person{Oliver Kurth} in 1999. His aim was to create a small \MTA\ that is especially focused on computers with dial-up Internet connections. Throughout the next four years he worked steadily on it, releasing new versions every few weeks. During the active phase of development 53 version have been released. In average, this is a new version every 20 days. 2.90 +The \masqmail\ project\index{masqmail!the project} was initiated by \person{Oliver Kurth} in 1999. His aim was to create a small \MTA\ that is especially focused on computers with dial-up Internet connections\index{dial-up}. Throughout the next four years he worked steadily on it, releasing new versions every few weeks. During the active phase of development 53 version have been released. In average, this is a new version every 20 days. 2.91 2.92 -This thesis is based on the latest release of \masqmail---version 0.2.21, dated November 2005. It was released after a 28 month gap of inactivity. The source code of 0.2.21 is the same as of 0.2.20, with only build documents modified. The homepage of \masqmail\ \citeweb{masqmail:homepage2} does not include this latest release, but it can be retrieved from the \debian\ package pool\footnote{The \NAME{URL} is:\\\url{http://ftp.de.debian.org/debian/pool/main/m/masqmail/masqmail_0.2.21.orig.tar.gz}} \citeweb{packages.debian}. 2.93 +This thesis is based on the latest release of \masqmail---version 0.2.21, dated November 2005\index{masqmail!latest release}. It was released after a 28 month gap of inactivity. The source code of 0.2.21 is the same as of 0.2.20, with only build documents modified. The homepage of \masqmail\ \citeweb{masqmail:homepage2}\index{masqmail!homepage} does not include this latest release, but it can be retrieved from the \debian\ package pool\index{debian!package pool}\footnote{The \NAME{URL} is:\\\url{http://ftp.de.debian.org/debian/pool/main/m/masqmail/masqmail_0.2.21.orig.tar.gz}} \citeweb{packages.debian}. 2.94 2.95 -\masqmail\ is covered by the \name{General Public License} (short: \NAME{GPL}) \cite{fsf:gpl} which qualifies it as Free Software \cite{fsf:freesw-definition}. 2.96 +\masqmail\ is covered by the \name{General Public License}\index{gpl} (short: \NAME{GPL}) \cite{fsf:gpl} which qualifies it as Free Software\index{free software} \cite{fsf:freesw-definition}. 2.97 2.98 \person{Kurth} abandoned \masqmail\ after 2005 and no one adopted the project since then. Thus, the author of this thesis decided to take over responsibility for \masqmail\ now. He received \person{Kurth}'s permission to do so in private telephone conversation with \person{Kurth} on September 4, 2008. 2.99 2.100 @@ -212,7 +216,7 @@ 2.101 2.102 \begin{enumerate} 2.103 \item Direct delivery to local mailboxes (in \name{mbox} or \name{maildir} format) 2.104 -\item Local pipes to pass mail to a program (e.g.\ to \NAME{MDA}s or to gateways to \NAME{UUCP} or fax) 2.105 +\item Local pipes to pass mail to a program (e.g.\ to \MDA{}s or to gateways to \NAME{UUCP} or fax) 2.106 \item \NAME{TCP} sockets to transfer mail to other \MTA{}s using the \SMTP\ protocol 2.107 \end{enumerate} 2.108 2.109 @@ -234,7 +238,7 @@ 2.110 %masqmail: mailq, mailrm, runq, rmail, smtpd/in.smtpd 2.111 %sendmail: hoststat, mailq, newaliases, purgestat, smtpd 2.112 2.113 -Additional to the \mta\ job, \masqmail\ also offers mail retrieval services by acting as a \NAME{POP3} client. It can fetch mail from different remote locations, also dependent on the active online connection. Such functionality is especially useful in a setup like \name{Scenario 2} on page \pageref{scenario2}. 2.114 +Additional to the \MTA\ job, \masqmail\ also offers mail retrieval services by acting as a \NAME{POP3} client. It can fetch mail from different remote locations, also dependent on the active online connection. Such functionality is especially useful in a setup like \name{Scenario 2} on page \pageref{scenario2}. 2.115 2.116 2.117
3.1 --- a/thesis/tex/2-MarketAnalysis.tex Sat Jan 31 20:07:58 2009 +0100 3.2 +++ b/thesis/tex/2-MarketAnalysis.tex Sat Jan 31 21:39:53 2009 +0100 3.3 @@ -65,12 +65,12 @@ 3.4 3.5 3.6 \subsection{Trends} 3.7 -Following are the trends for electronic communication. The trends are shown from the view point of \mta{}s. Nevertheless are these trends common for all of the communication technology. 3.8 +Following are the trends for electronic communication. The trends are shown from the view point of \MTA{}s. Nevertheless are these trends common for all of the communication technology. 3.9 3.10 \subsubsection*{Consolidation} 3.11 There is a consolidation of communication technologies with similar transport characteristics, nowadays. Email is the most flexible kind of asynchronous communication technology in major use. Hence email is the best choice for transferring messages of any kind today. But in future it probably will be \name{Unified Messaging}, which tries to group all kinds of asynchronous messaging into one communication system. It aims to provide transparent transport for all kinds of content and flexible access interfaces for all kinds of clients. Unified messaging seems to have the potential to be the successor of all asynchronous communication technologies, including email. 3.12 3.13 -Today email still is the major asynchronous communication technology and it probably will be it for the next years. As Unified Messaging needs similar transfer facilities to email, it may to be an evolution not a revolution. Hence \mta{}s will still have importance in future, maybe in a modified way. 3.14 +Today email still is the major asynchronous communication technology and it probably will be it for the next years. As Unified Messaging needs similar transfer facilities to email, it may to be an evolution not a revolution. Hence \MTA{}s will still have importance in future, maybe in a modified way. 3.15 3.16 3.17 \subsubsection*{Integration} 3.18 @@ -119,7 +119,7 @@ 3.19 3.20 %fixme: add short summery: where exactly is masqmail's position within e-comm? 3.21 3.22 -After viewing the whole market of electronic communication, a zoom into the market of electronic mail follows. Email is an asynchronous communication technology that transports textual information primary. This thesis is about a \mta, so the market situation for email is important. Interesting questions are: Is email future-safe? How will electronic mail change? Will it change at all? Which are the critical parts? These questions matter when deciding on the directions for further development of an \MTA. They are discussed in this section. 3.23 +After viewing the whole market of electronic communication, a zoom into the market of electronic mail follows. Email is an asynchronous communication technology that transports textual information primary. This thesis is about an \MTA, so the market situation for email is important. Interesting questions are: Is email future-safe? How will electronic mail change? Will it change at all? Which are the critical parts? These questions matter when deciding on the directions for further development of an \MTA. They are discussed in this section. 3.24 3.25 3.26 3.27 @@ -196,7 +196,7 @@ 3.28 3.29 Home servers become popular for central data storage and multimedia services, these days. Being assembled of energy efficient elements, power consumption is no big problem anymore. These home servers will replace video recorders and \NAME{CD} music collections in the near future. It is also realistic that they will manage heating systems and intercoms too. Given the future leads to this direction, it will be a logical step to have email and other communication provided by the own home server as well. 3.30 3.31 -After \mta{}s have not been popular for users in the past years, the next years might bring the \MTA{}s back to the users. Maybe in a few years nearly everyone will have one running at home. 3.32 +After \MTA{}s have not been popular for users in the past years, the next years might bring the \MTA{}s back to the users. Maybe in a few years nearly everyone will have one running at home. 3.33 3.34 3.35 \subsubsection*{Pushing versus polling} 3.36 @@ -239,16 +239,16 @@ 3.37 It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. \sendmail\ took this approach with the \name{m4} macros. %fixme: add ref 3.38 Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ graphical programs, websites, command line programs; all of them either in a questionnaire style or interactive). 3.39 3.40 -When \MTA{}s become popular on home servers and maybe even on workstations and smart phones, then performance will be less important. Providers need \mta{}s that process large amounts of mail in short time. However, there is no need for home servers and workstations to handle that much mail; they need to process far less email messages per time unit. Thus performance will probably not be a main requirement for an \MTA\ in future, if they mainly run on private machines. 3.41 +When \MTA{}s become popular on home servers and maybe even on workstations and smart phones, then performance will be less important. Providers need \MTA{}s that process large amounts of mail in short time. However, there is no need for home servers and workstations to handle that much mail; they need to process far less email messages per time unit. Thus performance will probably not be a main requirement for an \MTA\ in future, if they mainly run on private machines. 3.42 3.43 -New mailing concepts and architectures like push email or \name{Internet Mail 2000} will, if they succeed, require \mta{}s to adopt the new technology. \MTA{}s that are not able to change are going to be sorted out by evolution. Thus it is important not to focus too much on one use case, but to stay flexible. \person{Allman} saw the flexibility of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}). 3.44 +New mailing concepts and architectures like push email or \name{Internet Mail 2000} will, if they succeed, require \MTA{}s to adopt the new technology. \MTA{}s that are not able to change are going to be sorted out by evolution. Thus it is important not to focus too much on one use case, but to stay flexible. \person{Allman} saw the flexibility of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}). 3.45 3.46 Another important requirement for all kinds of software will be security. There is a constant trend coming from completely non-secured software, in the 70s and 80s, over growing security awareness, in the 90s, to security being a primary goal, now. This leads to the conclusion that software security will be even more important within the next years. As more clients get connected to the Internet and especially more computers are listening for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing of software systems will be done with increasing effort in future. 3.47 3.48 ``Plug-and-play''-able hardware with preconfigured software running can be expected to become popular. Like someone buys a set-top box to watch Pay-\NAME{TV} today, he might be buying a box acting as mail server in a few years. He plugs the power cable in, inserts his email address in a web interface and selects the clients (workstation computers or smart phones) to which mail should be send and from which mail is accepted to receive. That's all. It would just work then, like everyone expects it from a set-top box today. Secure and robust software is a pre-requisite for such boxes to make that vision possible. 3.49 3.50 3.51 -In summary: Easy configuration, as well as the somehow opposed flexibility will be important for future \mta{}s. Also will it be security, but not performance. \MTA{}s might become more commodity software, like web servers already are today, with the purpose to include it in many systems and the need of minimal configuration. 3.52 +In summary: Easy configuration, as well as the somehow opposed flexibility will be important for future \MTA{}s. Also will it be security, but not performance. \MTA{}s might become more commodity software, like web servers already are today, with the purpose to include it in many systems and the need of minimal configuration. 3.53 3.54 3.55
4.1 --- a/thesis/tex/3-MailTransferAgents.tex Sat Jan 31 20:07:58 2009 +0100 4.2 +++ b/thesis/tex/3-MailTransferAgents.tex Sat Jan 31 21:39:53 2009 +0100 4.3 @@ -1,7 +1,7 @@ 4.4 \chapter{Mail transfer agents} 4.5 \label{chap:mail-transfer-agents} 4.6 4.7 -After having analyzed the market for electronic mail and identified upcoming trends, in the last chapter; this chapter takes a look at \mta{}s---the intelligent nodes and thus the most important parts of the email infrastructure. The \MTA{}s will be grouped by similarities first. Then the four most popular \freesw\ \mta{}s, will be presented to the reader in a short overview and with the most important facts. At the end of this chapter these programs will be compared. 4.8 +After having analyzed the market for electronic mail and identified upcoming trends, in the last chapter; this chapter takes a look at \MTA{}s---the intelligent nodes and thus the most important parts of the email infrastructure. The \MTA{}s will be grouped by similarities first. Then the four most popular Free Software \MTA{}s, will be presented to the reader in a short overview and with the most important facts. At the end of this chapter these programs will be compared. 4.9 4.10 4.11 4.12 @@ -9,7 +9,7 @@ 4.13 \section{Types of MTAs} 4.14 ``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. 4.15 4.16 -This is how \person{Bryan Costales} defines a \mta: 4.17 +This is how \person{Bryan Costales} defines an \MTA: 4.18 \begin{quote} 4.19 A mail transfer agent (\MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office. 4.20 \hfill\cite{costales97} 4.21 @@ -24,7 +24,7 @@ 4.22 4.23 Common to all \MTA{}s is the transport of mail; 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. 4.24 4.25 -Following is a classification of \mta{}s into groups of similar programs, regarding what is viewable from the outside. 4.26 +Following is a classification of \MTA{}s into groups of similar programs, regarding what is viewable from the outside. 4.27 4.28 4.29 \subsubsection*{Relay-only MTAs} 4.30 @@ -47,7 +47,7 @@ 4.31 4.32 4.33 \subsubsection*{``Real'' MTAs} 4.34 -There is a third type of \mta{}s in between the minimalistic \name{relay-only} \MTA{}s and the feature loaded \name{groupware}. Those programs may be named ``real \MTA{}s'', or ``proper \MTA{}s'', though there is no common name. They are what is meant with the term ``\mta''---programs that transfer mail between hosts. 4.35 +There is a third type of \MTA{}s in between the minimalistic \name{relay-only} \MTA{}s and the feature loaded \name{groupware}. Those programs may be named ``real \MTA{}s'', or ``proper \MTA{}s'', though there is no common name. They are what is meant with the term ``mail transfer agent''---programs that transfer mail between hosts. 4.36 4.37 Common to them is their focus on transferring email, while being able to act as \name{smart host}s. Their variety ranges from ones mostly restricted to mail transfer (e.g.\ \qmail) to others having interfaces for adding further mail processing modules (e.g.\ \postfix). This group covers everything in between the other two groups. 4.38 4.39 @@ -57,7 +57,7 @@ 4.40 \subsubsection*{Other segmenting} 4.41 \name{Mail transfer agents} can also be split in other ways. 4.42 4.43 -Due to \sendmail's significance in the early times of email, compatibility interfaces for \sendmail\ are important for \unix\ \MTA{}s. The reason is that many mail applications simply the \sendmail\ \MTA\ to be installed on the system. Being not \emph{sendmail-compatible} may not matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on \unix\ systems. Hence being sendmail-compatible is a major property of a \mta. \MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility add-on, will not be covered here. One example for such a program is \name{Apache James}. %FIXME: check if correct 4.44 +Due to \sendmail's significance in the early times of email, compatibility interfaces for \sendmail\ are important for \unix\ \MTA{}s. The reason is that many mail applications simply the \sendmail\ \MTA\ to be installed on the system. Being not \emph{sendmail-compatible} may not matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on \unix\ systems. Hence being sendmail-compatible is a major property of an \MTA. \MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility add-on, will not be covered here. One example for such a program is \name{Apache James}. %FIXME: check if correct 4.45 4.46 Another separation can be done between \freesw\ \MTA{}s and proprietary ones. Many of the \MTA{}s for \unix\ systems are \freesw. Only these are regarded in the following sections, because comparing \freesw\ with proprietary or commercial software is not what typical users of programs like \masqmail\ do. Comparison with non-free programs may be a point for large \freesw\ projects, trying to step into the business world. Small projects, mostly used by individuals at home, need to be compared against other projects of similar shape. The document is seen from \masqmail's point of view---an \MTA\ for \unix\ systems on home servers and workstations---so non-free software is out of the way. 4.47 4.48 @@ -103,13 +103,13 @@ 4.49 \label{tab:mta-market-share} 4.50 \end{table} 4.51 4.52 -All surveys show high market shares for the four \MTA{}s: \sendmail, \exim, \qmail, and \postfix. Only the \name{Microsoft} mail server software and \name{IMail} have comparable large shares. Other \freesw\ \mta{}s (\name{smail}, \name{zmailer}, \NAME{MMDF}, \name{courier-mta}) are less important and seldom used. 4.53 +All surveys show high market shares for the four \MTA{}s: \sendmail, \exim, \qmail, and \postfix. Only the \name{Microsoft} mail server software and \name{IMail} have comparable large shares. Other Free Software \MTA{}s (\name{smail}, \name{zmailer}, \NAME{MMDF}, \name{courier-mta}) are less important and seldom used. 4.54 4.55 The three surveys base on different data. \person{Bernstein} took 1\,000\,000 randomly chosen \NAME{IP} addresses, containing 39\,206 valid hosts; 958 of them accepted \NAME{SMTP} connections. The \person{Simpson} and \person{Bekman} survey used only domains owned by companies; in total 400\,000 hosts. \name{MailRadar} scanned 2\,818\,895 servers, leading to 59\,209 accepted connections. 4.56 4.57 All surveys show \sendmail\ to be the most popular \MTA. \postfix, \qmail, and \exim\ are among the best seven in each. \exim\ has slightly smaller shares than the other two. The four together share more than half of the market according to \person{Bernstein} and the \name{MailRadar} statistics. \person{Simpson} and \person{Bekman} have their share to be somewhere between a third and the half. This uncertainty comes from the large amount of unidentifiable \MTA{}s. 4.58 4.59 -The 22 percent of \name{mail security layers} in the \name{O'Reilly} survey is remarkable. Mail security layers are software guards between the network and the \mta\ that filter unwanted mail before it reaches the \MTA. This increases security by filtering malicious content and by blocking attacks against the \MTA. This large share may be a result of only regarding business mail servers. The problem concerning the survey is the disguise of the \mta\ working behind the security layer. It seems wrong to assume equal shares for the \MTA{}s behind the guards as for the unguarded \MTA{}s, because mail security layers will be more often used to guard weak \MTA{}s, as strong ones do not need them so much. This needs to be kept in mind when using the \name{O'Reilly} survey. 4.60 +The 22 percent of \name{mail security layers} in the \name{O'Reilly} survey is remarkable. Mail security layers are software guards between the network and the \MTA\ that filter unwanted mail before it reaches the \MTA. This increases security by filtering malicious content and by blocking attacks against the \MTA. This large share may be a result of only regarding business mail servers. The problem concerning the survey is the disguise of the \MTA\ working behind the security layer. It seems wrong to assume equal shares for the \MTA{}s behind the guards as for the unguarded \MTA{}s, because mail security layers will be more often used to guard weak \MTA{}s, as strong ones do not need them so much. This needs to be kept in mind when using the \name{O'Reilly} survey. 4.61 4.62 The date of the \name{Mailradar} statistics is not mentioned with it; a mail to \name{Mailradar} asking for information was not replied, unfortunately. However, it seems quite sure that the statistics were published after 2001, caused by the \sendmail\ and \postfix\ shares. But to decide whether before or after the one from \name{O'Reilly} would be just guessing. 4.63 4.64 @@ -122,7 +122,7 @@ 4.65 4.66 \subsubsection*{sendmail} 4.67 \label{sec:sendmail} 4.68 -\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 \citeweb{wikipedia:sendmail}. 4.69 +\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 \citeweb{wikipedia:sendmail}. 4.70 4.71 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 \cite[page~5]{vixie01}. 4.72 4.73 @@ -155,7 +155,7 @@ 4.74 \label{sec:qmail} 4.75 \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. His own words are: ``This is why I started writing qmail: I was sick of the security holes in sendmail and other \MTA{}s.'' \citeweb{qmail:homepage1}. 4.76 4.77 -\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\ \citeweb{wikipedia:qmail}. 4.78 +\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\ \citeweb{wikipedia:qmail}. 4.79 4.80 The latest release of \qmail\ is version 1.03 from July 1998. In November 2007, afterwards, \qmail's source was put into the \name{public domain}. This makes it Free Software. 4.81 4.82 @@ -200,7 +200,7 @@ 4.83 4.84 Architecture is most important when comparing \MTA{}s. Many other properties of a program depend on its architecture. \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. 4.85 4.86 -Two different architecture types show off: monolithic and modular \mta{}s. 4.87 +Two different architecture types show off: monolithic and modular \MTA{}s. 4.88 4.89 Monolithic \MTA{}s are \sendmail, \name{smail}, \exim, and \masqmail. They all consist of one single \emph{setuid root}\footnote{\emph{setuid root} lets a program run with the rights of its owner, here root. This is considered to be a security risk. Thus it it should be avoided if possible.} binary which does all the work. 4.90 4.91 @@ -210,7 +210,7 @@ 4.92 4.93 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. 4.94 4.95 -Today modular \mta\ architectures are the state-of-the-art. 4.96 +Today modular \MTA\ architectures are the state-of-the-art. 4.97 4.98 4.99 \subsubsection*{Spam checking and content processing} 4.100 @@ -228,11 +228,11 @@ 4.101 4.102 \subsubsection*{Performance} 4.103 4.104 -As second trend, the decreasing necessity for high performance was identified. This goes along with the move of \MTA{}s from service providers to home servers. \postfix\ focuses much on performance, this might not be an important point in the future. Of course there still will be the need for high performance \MTA{}s, but a growing share of the market will not require high performance. Energy and space efficiency is related to performance; it is a similar goal in a different direction. Optimization, be it for performance or other efficiencies, is often in contrast to simplicity and clarity, which effect security. Optimizing does in most times decrease the simplicity and clarity. Simple \mta{}s not aiming for high performance are what is needed in future. The simple design of \qmail (\qmail\ is still fast) seems to be a good example. 4.105 +As second trend, the decreasing necessity for high performance was identified. This goes along with the move of \MTA{}s from service providers to home servers. \postfix\ focuses much on performance, this might not be an important point in the future. Of course there still will be the need for high performance \MTA{}s, but a growing share of the market will not require high performance. Energy and space efficiency is related to performance; it is a similar goal in a different direction. Optimization, be it for performance or other efficiencies, is often in contrast to simplicity and clarity, which effect security. Optimizing does in most times decrease the simplicity and clarity. Simple \MTA{}s not aiming for high performance are what is needed in future. The simple design of \qmail (\qmail\ is still fast) seems to be a good example. 4.106 4.107 \subsubsection*{Security} 4.108 4.109 -The third trend---even more security awareness---is addressed by each of the four programs. It seems as if all widely used \mta{}s provide good security nowadays. Even \sendmail\ can be configured to be secure today. But the modular architecture, used by \qmail\ and \postfix, is generally seen to be conceptually more secure, however. \sendmail's creators have started \name{MeTA1}, a modular \MTA\ merging the best of \qmail\ and \postfix, to replace the old \sendmail. It will be interesting to watch \exim's future---will it become modular too? 4.110 +The third trend---even more security awareness---is addressed by each of the four programs. It seems as if all widely used \MTA{}s provide good security nowadays. Even \sendmail\ can be configured to be secure today. But the modular architecture, used by \qmail\ and \postfix, is generally seen to be conceptually more secure, however. \sendmail's creators have started \name{MeTA1}, a modular \MTA\ merging the best of \qmail\ and \postfix, to replace the old \sendmail. It will be interesting to watch \exim's future---will it become modular too? 4.111 4.112 4.113
5.1 --- a/thesis/tex/4-MasqmailsFuture.tex Sat Jan 31 20:07:58 2009 +0100 5.2 +++ b/thesis/tex/4-MasqmailsFuture.tex Sat Jan 31 21:39:53 2009 +0100 5.3 @@ -40,7 +40,7 @@ 5.4 5.5 \paragraph{\RF1: Incoming and outgoing channels} 5.6 \label{rf1} 5.7 -\sendmail-compatible \mta{}s must support at least two incoming channels: mail submitted using the \sendmail\ command, and mail received on a \NAME{TCP} port. Thus it is common to split the incoming channels into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view \cite{hafiz05}. 5.8 +\sendmail-compatible \MTA{}s must support at least two incoming channels: mail submitted using the \sendmail\ command, and mail received on a \NAME{TCP} port. Thus it is common to split the incoming channels into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view \cite{hafiz05}. 5.9 5.10 \SMTP\ is the primary mail transport protocol today, but with the increasing need for new protocols (see section \ref{sec:what-will-be-important}) in mind, support for more than just \SMTP\ is good to have. New protocols will show up, maybe multiple protocols need to be supported then. This leads to multiple remote channels, one for each supported protocol as it was done in other \MTA{}s. Best would be interfaces to add further protocols as modules. 5.11 5.12 @@ -69,7 +69,7 @@ 5.13 5.14 \paragraph{\RF2: Mail queuing} 5.15 \label{rf2} 5.16 -Mail queuing removes the need to deliver instantly as a message is received. The queue provides fail-safe storage of mails until they are delivered. Mail queues are probably used in all \mta{}s, even in some simple forwarders. The mail queue is essential for \masqmail, as \masqmail\ is used for non-permanent online connections. This means, mail must be queued until a online connection is available to send the message. This may be after a reboot. Hence the mail queue must provide persistence. 5.17 +Mail queuing removes the need to deliver instantly as a message is received. The queue provides fail-safe storage of mails until they are delivered. Mail queues are probably used in all \MTA{}s, even in some simple forwarders. The mail queue is essential for \masqmail, as \masqmail\ is used for non-permanent online connections. This means, mail must be queued until a online connection is available to send the message. This may be after a reboot. Hence the mail queue must provide persistence. 5.18 5.19 The mail queue and the module(s) to manage it are the central part of the whole system. This demands especially for robustness and reliability, as a failure here can lead to loosing mail. An \MTA\ takes over responsibility for mail in accepting it, hence loosing mail messages is absolutely to avoid. This covers any kind of crash situation too. The worst thing acceptable to happen is an already sent mail to be sent again. 5.20 5.21 @@ -151,7 +151,7 @@ 5.22 \label{rf8} 5.23 Spam is a major threat nowadays, but it is a war that is hard to win. The goal is to provide state-of-the-art spam protection, but not more (see section \ref{sec:swot-analysis}). 5.24 5.25 -As spam is, by increasing the amount of mail messages, not just a nuisance for end users, but also for the infrastructure---the \mta{}s---they need to protect themselves. 5.26 +As spam is, by increasing the amount of mail messages, not just a nuisance for end users, but also for the infrastructure---the \MTA{}s---they need to protect themselves. 5.27 5.28 Filtering spam can be done by either refusing spam during the \SMTP\ dialog or by checking for spam after the mail was accepted and queued. Both ways have advantages and disadvantages, so modern \MTA{}s use them in combination. 5.29 5.30 @@ -169,7 +169,7 @@ 5.31 \label{rf9} 5.32 Related to spam is malicious content (short: \name{malware}) like viruses, worms, trojan horses. They, in contrast to spam, do not affect the \MTA\ itself, as they are in the mail's body. \MTA{}s searching for malware is equal to real world's post offices opening letters to check if they contain something that could harm the recipient. This is not a mail transport job. But by many people the \MTA\ which is responsible for the recipient is seen to be at a good position to do this work, so it is often done there. 5.33 5.34 -In any way should malware checking be performed by external programs that may be invoked by the \mta. But \NAME{MDA}s are better points to invoke content scanners. 5.35 +In any way should malware checking be performed by external programs that may be invoked by the \MTA. But \NAME{MDA}s are better points to invoke content scanners. 5.36 5.37 A popular email filter framework is \name{amavis} which integrates various spam and malware scanners. The common setup includes a receiving \MTA\ which sends it to \name{amavis} using \SMTP, \name{amavis} processes the mail and sends it then to a second \MTA\ that does the outgoing transfer. Having interfaces to such scanners is nice to have, though. (This setup with two \MTA\ instances is discussed in more detail in section \ref{sec:current-code-security}). 5.38 5.39 @@ -201,7 +201,7 @@ 5.40 5.41 5.42 \paragraph{\RG2: Reliability} 5.43 -Reliability is the second essential quality property for an \MTA. Mail for which the \MTA\ took responsibility must never get lost while it is within the \MTA{}s responsibility. The \MTA\ must not be \emph{the cause} of any mail loss, no matter what happens. Unreliable \mta{}s are of no value. However, as the mail transport infrastructure are distributed systems, one of the communication partners or the transport medium may crash at any time during mail transfer. Thus reliability is needed for mail transfer communication too. 5.44 +Reliability is the second essential quality property for an \MTA. Mail for which the \MTA\ took responsibility must never get lost while it is within the \MTA{}s responsibility. The \MTA\ must not be \emph{the cause} of any mail loss, no matter what happens. Unreliable \MTA{}s are of no value. However, as the mail transport infrastructure are distributed systems, one of the communication partners or the transport medium may crash at any time during mail transfer. Thus reliability is needed for mail transfer communication too. 5.45 5.46 The goal is to transfer exactly one copy of the message. \person{Tanenbaum} evaluates the situation and comes to the conclusion that ``in general, there is no way to arrange this.'' \cite[pages~377--379]{tanenbaum02}. Only strategies where now mail gets lost are acceptable; he identifies three of them, but one generates more duplicates than the others, so two strategies remain. (1) The client always reissues the transfer; the server first sends an acknowledgment, then handles the transfer. (2) The client reissues the transfer only if no acknowledgment was received; the server first handles the transfer and sends the acknowledgment afterwards. The first strategy does not need acknowledgments at all, however, it will lose mail if the second transfer fails too. 5.47 5.48 @@ -241,7 +241,7 @@ 5.49 5.50 5.51 \paragraph{\RG10: Usability} 5.52 -Usability, not mentioned by \person{Hafiz} (he focuses on architecture) but by \person{Spinellis} and \person{Kan}, is a property 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; and 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 focused must be the most common form of configuration: choosing one of several common setups. 5.53 +Usability, not mentioned by \person{Hafiz} (he focuses on architecture) but by \person{Spinellis} and \person{Kan}, is a property 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; and 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 focused must be the most common form of configuration: choosing one of several common setups. 5.54 5.55 %fixme: << masqmail as portable app? >> 5.56 5.57 @@ -269,7 +269,7 @@ 5.58 \label{fig:masqmail-arch} 5.59 \end{figure} 5.60 5.61 -\sendmail\ improved its old architecture by adding the milter interface, to include further functionality by invoking external programs. \exim\ was designed, and is carefully maintained, with a modular-like code structure in mind. \qmail\ started from scratch with a ``security-first'' approach, \postfix\ improved on it, and \name{sendmail X}/\name{MeTA1} tries to adopt the best of \qmail\ and \postfix\ to completely replace the old \sendmail\ architecture. \person{Hafiz} describes this evolution of \mta\ architecture very well \cite{hafiz05}. 5.62 +\sendmail\ improved its old architecture by adding the milter interface, to include further functionality by invoking external programs. \exim\ was designed, and is carefully maintained, with a modular-like code structure in mind. \qmail\ started from scratch with a ``security-first'' approach, \postfix\ improved on it, and \name{sendmail X}/\name{MeTA1} tries to adopt the best of \qmail\ and \postfix\ to completely replace the old \sendmail\ architecture. \person{Hafiz} describes this evolution of \MTA\ architecture very well \cite{hafiz05}. 5.63 5.64 Every one of these programs is more modular, or became more modular over time, than \masqmail\ is. Modern requirements like spam protection and future requirements like---probably---the use of new mail transport protocols demand for modular designs in order to keep the software simple. Simplicity is a key property for security. ``the essence of security engineering is to build systems that are as simple as possible.'' \cite[page 45]{graff03}. 5.65 5.66 @@ -389,7 +389,7 @@ 5.67 5.68 \section{Work to do} 5.69 5.70 -After the requirements for modern \mta{}s were identified in section \ref{sec:mta-requirements} and \masqmail's features were set against them in section \ref{sec:fulfilled-requirements}, here the work that is left to do is identified. Table \ref{tab:requirements} lists all requirements with importance and the work needed to achieve them. The column ``Focus'' shows the attention a work task should get. The focus depends on the task's importance and the amount of work it includes. 5.71 +After the requirements for modern \MTA{}s were identified in section \ref{sec:mta-requirements} and \masqmail's features were set against them in section \ref{sec:fulfilled-requirements}, here the work that is left to do is identified. Table \ref{tab:requirements} lists all requirements with importance and the work needed to achieve them. The column ``Focus'' shows the attention a work task should get. The focus depends on the task's importance and the amount of work it includes. 5.72 5.73 \begin{table} 5.74 \begin{center}
6.1 --- a/thesis/tex/5-Improvements.tex Sat Jan 31 20:07:58 2009 +0100 6.2 +++ b/thesis/tex/5-Improvements.tex Sat Jan 31 21:39:53 2009 +0100 6.3 @@ -287,7 +287,7 @@ 6.4 \item Checking for spam after the mail was accepted and queued. Here more processing time can be invested, thus more detailed checks can be done. But, as responsibility for messages was taken by accepting them, it is no choice to simply delete spam mail. Checks for spam do not lead to sure results, they just indicate the possibility the message is unwanted mail. \person{Eisentraut} indicates actions to take after a message is recognized as probably spam \cite[pages 18--20]{eisentraut05}. The only acceptable one, for mail the \MTA\ is responsible for, is adding further or rewriting existing header lines. Thus all further work on the message is the same as for non-spam messages. 6.5 \end{enumerate} 6.6 6.7 -Modern \MTA{}s use both techniques in combination. Checks during the \SMTP\ dialog tend to be implemented in the \mta\ to make them fast; checks after the message was queued are often done using external programs (\name{spamassassin} is a well known one). \person{Eisentraut} sees the checks during the \SMTP\ dialog to be essential: ``Ganz ohne Analyse w\"ahrend der \SMTP-Phase kommt sowieso kein \MTA\ aus, und es ist eine Frage der Einsch\"atzung, wie weit man diese Phase belasten m\"ochte.'' \cite[page 25]{eisentraut05} (translated: ``No \MTA\ can go without analysis during the \SMTP\ phase anyway, but the amount of stress one likes to put on this phase is left to his discretion.'') 6.8 +Modern \MTA{}s use both techniques in combination. Checks during the \SMTP\ dialog tend to be implemented in the \MTA\ to make them fast; checks after the message was queued are often done using external programs (\name{spamassassin} is a well known one). \person{Eisentraut} sees the checks during the \SMTP\ dialog to be essential: ``Ganz ohne Analyse w\"ahrend der \SMTP-Phase kommt sowieso kein \MTA\ aus, und es ist eine Frage der Einsch\"atzung, wie weit man diese Phase belasten m\"ochte.'' \cite[page 25]{eisentraut05} (translated: ``No \MTA\ can go without analysis during the \SMTP\ phase anyway, but the amount of stress one likes to put on this phase is left to his discretion.'') 6.9 6.10 Checking before a message is accepted, like \NAME{DNS} blacklists and \name{greylisting}, needs to be invoked from within the receiving modules. Like for authentication and encryption, the implementation of the functionality should be provided by a central source. 6.11
7.1 --- a/thesis/thesis.sty Sat Jan 31 20:07:58 2009 +0100 7.2 +++ b/thesis/thesis.sty Sat Jan 31 21:39:53 2009 +0100 7.3 @@ -31,10 +31,9 @@ 7.4 \renewcommand{\quote}{\OLDquote\small} % blockquotes in smaller size 7.5 7.6 % formating macros 7.7 -%\renewcommand{\path}[1]{\textit{#1}} 7.8 \newcommand{\name}[1]{\emph{#1}} 7.9 \newcommand{\NAME}[1]{{\smaller\textsc{#1}}} 7.10 -\newcommand{\person}[1]{\textsc{#1}} 7.11 +\newcommand{\person}[1]{\textsc{#1}\index{#1}} 7.12 \newcommand{\obsoleted}[1]{\quad{\small(obsoleted by \RFC\,#1)}} 7.13 7.14 % shortcuts 7.15 @@ -44,7 +43,6 @@ 7.16 \newcommand{\exim}{\name{exim}} 7.17 \newcommand{\postfix}{\name{postfix}} 7.18 7.19 -\newcommand{\mta}{mail transfer agent} 7.20 \newcommand{\debian}{\name{Debian}} 7.21 \newcommand{\gnulinux}{\NAME{GNU}/\name{Linux}} 7.22 \newcommand{\MTA}{\NAME{MTA}}