1.1 --- a/thesis/tex/3-MailTransferAgents.tex	Sat Jan 31 20:07:58 2009 +0100
     1.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Sat Jan 31 21:39:53 2009 +0100
     1.3 @@ -1,7 +1,7 @@
     1.4  \chapter{Mail transfer agents}
     1.5  \label{chap:mail-transfer-agents}
     1.6  
     1.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.
     1.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.
     1.9  
    1.10  
    1.11  
    1.12 @@ -9,7 +9,7 @@
    1.13  \section{Types of MTAs}
    1.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.
    1.15  
    1.16 -This is how \person{Bryan Costales} defines a \mta:
    1.17 +This is how \person{Bryan Costales} defines an \MTA:
    1.18  \begin{quote}
    1.19  A mail transfer agent (\MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office.
    1.20  \hfill\cite{costales97}
    1.21 @@ -24,7 +24,7 @@
    1.22  
    1.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.
    1.24  
    1.25 -Following is a classification of \mta{}s into groups of similar programs, regarding what is viewable from the outside.
    1.26 +Following is a classification of \MTA{}s into groups of similar programs, regarding what is viewable from the outside.
    1.27  
    1.28  
    1.29  \subsubsection*{Relay-only MTAs}
    1.30 @@ -47,7 +47,7 @@
    1.31  
    1.32  
    1.33  \subsubsection*{``Real'' MTAs}
    1.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.
    1.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.
    1.36  
    1.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.
    1.38  
    1.39 @@ -57,7 +57,7 @@
    1.40  \subsubsection*{Other segmenting}
    1.41  \name{Mail transfer agents} can also be split in other ways.
    1.42  
    1.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
    1.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
    1.45  
    1.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.
    1.47  
    1.48 @@ -103,13 +103,13 @@
    1.49  	\label{tab:mta-market-share}
    1.50  \end{table}
    1.51  
    1.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.
    1.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.
    1.54  
    1.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.
    1.56  
    1.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.
    1.58  
    1.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.
    1.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.
    1.61  
    1.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.
    1.63  
    1.64 @@ -122,7 +122,7 @@
    1.65  
    1.66  \subsubsection*{sendmail}
    1.67  \label{sec:sendmail}
    1.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}.
    1.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}.
    1.70  
    1.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}.
    1.72  
    1.73 @@ -155,7 +155,7 @@
    1.74  \label{sec:qmail}
    1.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}.
    1.76  
    1.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}.
    1.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}.
    1.79  
    1.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.
    1.81  
    1.82 @@ -200,7 +200,7 @@
    1.83  
    1.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.
    1.85  
    1.86 -Two different architecture types show off: monolithic and modular \mta{}s.
    1.87 +Two different architecture types show off: monolithic and modular \MTA{}s.
    1.88  
    1.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.
    1.90  
    1.91 @@ -210,7 +210,7 @@
    1.92  
    1.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.
    1.94  
    1.95 -Today modular \mta\ architectures are the state-of-the-art.
    1.96 +Today modular \MTA\ architectures are the state-of-the-art.
    1.97  
    1.98  
    1.99  \subsubsection*{Spam checking and content processing}
   1.100 @@ -228,11 +228,11 @@
   1.101  
   1.102  \subsubsection*{Performance}
   1.103  
   1.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.
   1.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.
   1.106  
   1.107  \subsubsection*{Security}
   1.108  
   1.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?
   1.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?
   1.111  
   1.112  
   1.113