docs/diploma

diff thesis/tex/3-MailTransferAgents.tex @ 374:3445852ed736

applied comments by henry atting and jochen roth
author meillo@marmaro.de
date Mon, 02 Feb 2009 12:04:32 +0100
parents d51894e48762
children 90d5f98e3968
line diff
     1.1 --- a/thesis/tex/3-MailTransferAgents.tex	Sat Jan 31 21:39:53 2009 +0100
     1.2 +++ b/thesis/tex/3-MailTransferAgents.tex	Mon Feb 02 12:04:32 2009 +0100
     1.3 @@ -204,7 +204,7 @@
     1.4  
     1.5  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.6  
     1.7 -Modular \MTA{}s are \NAME{MMDF}, \qmail, \postfix, and \name{MeTA1}. They consist of several programs, each doing a part of the overall job. The different programs run with the least permissions the need, and \emph{setuid root} can be avoided completely.
     1.8 +Modular \MTA{}s are \NAME{MMDF}, \qmail, \postfix, and \name{MeTA1}. They consist of several programs, each doing a part of the overall job. The different programs run with the least permissions they need, and \emph{setuid root} can be avoided completely.
     1.9  
    1.10  The architecture does not directly define the program's security, but ``[t]he goal of making a software secure can be better achieved by making the design simple and easier to understand and verify'' \cite[chapter 6]{hafiz05}. \exim, though being monolithic, has a fairly clean security record. But it is very hard to keep the security up, as the program growth. \person{Wietse Venema} (the author of \postfix) says, it was the architecture that enabled \postfix\ to grow without running into security problems. \cite[page 13]{venema:postfix-growth}
    1.11  
    1.12 @@ -217,7 +217,7 @@
    1.13  
    1.14  Spam and malware increased during the last years. Today it is important for an \MTA\ to be able to provide checking for bad mail. This can be done by implementing functionality into the \MTA, or by invoking external programs to do this job.
    1.15  
    1.16 -\sendmail\ invented \name{milter} which is the common abbreviation for the \name{sendmail mail filter} \NAME{API}. It is used to interface external programs of various kind. \postfix\ adopted the \name{milter} interface, but is also able to easily include scanning modules into its modular structure. \qmail\ is pretty old and did not evolve with the changing market situation. Anyhow, its modular structure enables external scanners to be included into \qmail. \exim\ has the advantage that is was designed with the goal to provide extensive scanning facilities. It is therefore very good suited to scan itself or invoke external scanners.
    1.17 +\sendmail\ invented \name{milter} which is the common abbreviation for the \name{sendmail mail filter} \NAME{API}. It is used to interface external programs of various kind. \postfix\ adopted the \name{milter} interface, but is also able to easily include scanning modules into its modular structure. \qmail\ is pretty old and did not evolve with the changing market situation. Anyhow, its modular structure enables external scanners to be included into \qmail. \exim\ has the advantage that it was designed with the goal to provide extensive scanning facilities. It is therefore very good suited to scan itself or invoke external scanners.
    1.18  
    1.19  
    1.20  \subsubsection*{Provider independence}
    1.21 @@ -228,7 +228,7 @@
    1.22  
    1.23  \subsubsection*{Performance}
    1.24  
    1.25 -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.26 +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; these two improve 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\footnote{\qmail\ is still fast} is a good example.
    1.27  
    1.28  \subsubsection*{Security}
    1.29