Mercurial > docs > diploma

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

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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
comparison
equal deleted inserted replaced
373:d51894e48762 374:3445852ed736
202 202
203 Two different architecture types show off: monolithic and modular \MTA{}s. 203 Two different architecture types show off: monolithic and modular \MTA{}s.
204 204
205 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. 205 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.
206 206
207 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. 207 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.
208 208
209 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} 209 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}
210 210
211 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. 211 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.
212 212
215 215
216 \subsubsection*{Spam checking and content processing} 216 \subsubsection*{Spam checking and content processing}
217 217
218 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. 218 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.
219 219
220 \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. 220 \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.
221 221
222 222
223 \subsubsection*{Provider independence} 223 \subsubsection*{Provider independence}
224 224
225 In chapter \ref{chap:market-analysis}, it was tried to figure out trends and future requirements for \MTA{}s. The four programs are compared on these (possible) future requirements now. 225 In chapter \ref{chap:market-analysis}, it was tried to figure out trends and future requirements for \MTA{}s. The four programs are compared on these (possible) future requirements now.
226 226
227 The first trend was provider independence, requiring easy configuration. \postfix\ seems to do best here. It used primary two configuration files (\path{master.cf} and \path{main.cf}) which are easy to manage. \sendmail\ appears to have a bad position. Its configuration file \path{sendmail.cf} is cryptic and very complex (it has legendary Turing-completeness) thus it needs simplification wrappers around it to provide easier configuration. They exist in form of the \name{m4} macros that generate a \path{sendmail.cf} file. But adjusting the generated result by hand appears to be necessary for non-trivial configurations. \qmail's configuration files are simple, but the whole system is complex to set up; it requires various system users and is hardly usable without applying several patches to add functionality that is required nowadays. \name{netqmail} is the community effort to help in the latter point. \exim\ has only one single configuration file (\path{exim.conf}), but it suffers most from its flexibility---like \sendmail. Flexibility and easy configuration are almost always contrary goals. 227 The first trend was provider independence, requiring easy configuration. \postfix\ seems to do best here. It used primary two configuration files (\path{master.cf} and \path{main.cf}) which are easy to manage. \sendmail\ appears to have a bad position. Its configuration file \path{sendmail.cf} is cryptic and very complex (it has legendary Turing-completeness) thus it needs simplification wrappers around it to provide easier configuration. They exist in form of the \name{m4} macros that generate a \path{sendmail.cf} file. But adjusting the generated result by hand appears to be necessary for non-trivial configurations. \qmail's configuration files are simple, but the whole system is complex to set up; it requires various system users and is hardly usable without applying several patches to add functionality that is required nowadays. \name{netqmail} is the community effort to help in the latter point. \exim\ has only one single configuration file (\path{exim.conf}), but it suffers most from its flexibility---like \sendmail. Flexibility and easy configuration are almost always contrary goals.
228 228
229 \subsubsection*{Performance} 229 \subsubsection*{Performance}
230 230
231 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. 231 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.
232 232
233 \subsubsection*{Security} 233 \subsubsection*{Security}
234 234
235 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? 235 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?
236 236