docs/diploma: thesis/tex/4-MasqmailsFuture.tex comparison

comparison thesis/tex/4-MasqmailsFuture.tex @ 163:5681a18270b5

new content about architecture; some restructuring

author	meillo@marmaro.de
date	Thu, 18 Dec 2008 13:39:23 +0100
parents	18b7b517e2dd
children	a7fd6d974d3c

comparison

equal deleted inserted replaced

-:df6bfc48859b
+:5681a18270b5
 \section{Discussion on architecture}
-A program's architecture is maybe the most influencing design decision, and has the greatest impact on the program's future capabilities. %fixme: search quote ... check if good
+A program's architecture is probably the most influencing design decision, and has the greatest impact on the program's future capabilities. %fixme: search quote ... check if good
 \masqmail's current artitecture is monolitic like \sendmail's and \exim's. But more than the other two, is it one block of interweaved code. \sendmail\ provides now, with its \name{milter} interface, standardized connection channels to external modules. \exim\ has a highly structured code with many internal interfaces, like the one for supported authentication ``modules''. \masqmail\ has none of them; it is what \sendmail\ was in the beginning: a single large block.
 Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure.
 	\end{center}
 	\caption{Internal architecture of \masqmail}
 	\label{fig:masqmail-arch}
 \end{figure}
-\sendmail\ improved its old architecture, for example by adding the milter interface. \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} \cite{hafiz05}. describes this evolution of \mta\ architecture very well.
+\sendmail\ improved its old architecture, for example by adding the milter interface. \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} \cite{hafiz05}. describes this evolution of \mta\ architecture very well.
-Every one of the popular \MTA{}s is more modular, or became more modular, than \masqmail. The logical step is to rewrite \masqmail\ using a modern, modular architecture to get a modern \MTA\ satisfying nowadays needs. But how is the effort of this complete rewrite compared to what is gained afterwards?
+Every one of the popular \MTA{}s is more modular, or became more modular over time, than \masqmail\ is. Modern requirements like spam protection and future requirements like the use of new mail transport protocols demand modular designs for keeping the software simple. Simplicity is a key property for security.
+\person{Hafiz} agrees:
+\begin{quote}
+The goal of making software secure can be better achieved by making the design simple and easier to understand and verify. \cite[page64]{hafiz05}
-A secure architecture is of need.
+\end{quote}
+He identifies the security of \qmail\ to come from it's \name{compartmentalization}, which goes hand in hand with modularity:
+\begin{quote}
+A perfect example is the contrast between the feature envy early \sendmail\ architecture implemented as one process and the simple, modular architecture of \qmail. The security of \qmail\ comes from its compartmentalized simple processes that perform one task only and are therefor testable for security. \cite[page 64]{hafiz05}
+\end{quote}
+Modularity is needed for supporting modern \MTA\ requirements, providing a clear interface to add further functionality without increasing the overall complexity much. Modularity is also an enabler for security. Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
+\begin{quote}
+Good design is the sword and shield of the security-conscious developer. Sound design defends your application from subversion or misuse, protecting your network and the information on it from internal and external attacks alike. It also provides a safe foundation for future extensions and maintainance of the software.
+%
+%Bad design makes life easier for attackers and harder for the good guys, especially if it contributes to a false sends of security while obscuring pertinent failings.
+\cite[page 55]{graff03}
+\end{quote}
+\person{Hafiz} adds: ``The major idea is that security cannot be retrofitted into an architecture.''\cite[page 64]{hafiz05}
+All this leads to one logical step: The rewrite of \masqmail\ using a modern, modular architecture, to get a modern \MTA\ satisfying nowadays needs.
+\subsection{Modules needed}
+This section tries to identify the needed modules for a modern \MTA. They are later the pieces of which the new architecture is built of.
+\subsubsection*{The simplest MTA}
+This view of the problem is taken from \person{Hafiz} \cite[pages 3-5]{hafiz05}.
+The basic job of a \mta\ is to tranport mail from a sender to a recipient. The simplest \MTA\ therefor needs at least a mail receiving facility and a mail sending facility. This basic \MTA---following the definition of an \MTA---is much to abstract. Hence a next step to add some important features is needed, the result is an operational \MTA.
+\subsubsection*{Mail queue}
+\person{Hafif} adds a mail queue to make it possible to not deliver at once.
+Mail queues are probably used in all \mta{}s, excluding the simple forwarders. A mail queue is a essential requirement for \masqmail, as it is to be used for non-permanent online connections.
+\subsubsection*{Incoming channels}
+The second addition \person{Hafiz} made is the split of incoming and outgoing channels into local and remote. The question is, if this is nessesary. It is the way, it was done for a long time, but is this extra complexity needed?
+The common situation is incoming mail on port 25 using \SMTP\ and via the \texttt{sendmail} command. Outgoing mail is either sent using \SMTP, piped into local commands (for example \texttt{uucp}), or delivered locally by appending to a mailbox.
+The \MTA's architecture would be simpler if some of these channels could be merged. The reason is, if various modules do similar jobs, common things might need to be duplicated. On the other side is it better to have more independent modules if each one is simpler then.
+\qmail\ uses \name{qmail-inject} (local message in) and \name{qmail-smtpd} (remote message in), which both handle messages over to \name{qmail-queue} that puts it into the mail queue. \postfix's approach is similar. \name{sendmail X} %fixme: what about meta1 here?
+used only \NAME{SMTPS}, which is for receiving mail from remote, to communicate with the queue manager \NAME{QMGR}. Mail from local goes over \NAME{SMTPS}.
+The \name{sendmail X} approach seems to be the simpler one, but does heavily rely on \SMTP\ being the main mail transfer protocol. To \qmail\ and \postfix\ new modules may be added to support other ways of message receival, without any change of other parts of the system.
+\subsubsection*{Outgoing channels}
+Outgoing channels are similar for \qmail, \postfix, and \name{sendmail X}: All of them have a module to send mail using \SMTP, and one for writing into a local mailbox. Local mail delivery is a job that requires root priveledge to be able to switch to any user in order to write to his mailbox. Modular \MTA{}s do not need \name{setuid root}, but the local delivery process (or its parent) needs to run as root.
+As mail delivery to local users, is \emph{not} included in the basic job of \MTA{}s, why should they care about it? In order to keep the system simple and to have programs do one job well, the local delivery job should be handed over to \NAME{MDA}s. \name{Mail delivery agents} are the tools that are specialized for local delivery. They know about the various mailbox formats and are aware of the problems of concurrent write access and thelike. Hence handling the message and the responsiblity for it over to a mail delivery agent, like \name{procmail} or \name{maildrop}, seems to be the right way to go.
+This means outgoing connections, piping mails into local commands needs to be implemented.
+\subsubsection*{Mail queue (again)}
+\subsubsection*{Authentication}
+easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
+if dynamic remote hosts need access: some auth is needed
+- SASL
+- POP/IMAP: pop-before-smtp, DRAC, WHOSON
+- TLS (certificates)
+``None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of thyour users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.'' (Dent: Postfix, page 44, ch04)
+\subsubsection*{Encryption}
+\subsubsection*{Spam prevention}
+where to filter what
+postfix: after-queue-content-filter (smtp communication)
+exim: content-scan-feature
+sendmail: milter (tcp or unix sockets)
+checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
+checks when mail is accepted and queued: external (amavis, spamassassin)
+AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
+internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient
+|                            |
++----------------------------+
+mail scanner:
+incoming queue --> mail scanner --> outgoing queue
+mimedefang: uses milter interface with sendmail
+\subsubsection*{Virus checking}
+The same for malicious content (\name{malware}) like viruses, worms, trojan horses. They are related to spam, but affect the \MTA less, as they are in the mail body.
+message body <-> envelope, header
+anti-virus: clamav
+\subsubsection*{Archiving}
+\section{A new architecture}
 (ssl)
 -> msg-in (local or remote protocol handlers)
 -> spam-filter (and more)
 -> queue
 -> msg-out (local-delivery by MDA, or remote-protocol-handlers)
 (ssl)
-A design from scratch?
-<< what would be needed (effort) >>
-<< would one create it at all? >>
-<< should it be done? >>
 http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command
 http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security
 http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery
 http://fanf.livejournal.com/67297.html %how not to design an mta -   more log-structured MTA queues
 http://fanf.livejournal.com/70432.html %how not to design an mta - address verification
 http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning
-\subsubsection*{local mail delivery}
-But for example delivery of mail to local users is \emph{not} what \mta{}s should care about, although most \MTA\ are able to deliver mail, and many do. (\name{mail delivery agents}, like \name{procmail} and \name{maildrop}, are the right programs for this job.)
-\subsection{Access and Auth}
-easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
-if dynamic remote hosts need access: some auth is needed
-- SASL
-- POP/IMAP: pop-before-smtp, DRAC, WHOSON
-- TLS (certificates)
-``None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of thyour users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.'' (Dent: Postfix, page 44, ch04)
-postfix: after-queue-content-filter (smtp communication)
-exim: content-scan-feature
-sendmail: milter (tcp or unix sockets)
-checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
-checks when mail is accepted and queued: external (amavis, spamassassin)
-anti-virus: clamav
-AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
-internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient
-|                            |
-+----------------------------+
-mail scanner:
-incoming queue --> mail scanner --> outgoing queue
-mimedefang: uses milter interface with sendmail
-\subsection{spam and malicious content}
-The same for malicious content (\name{malware}) like viruses, worms, trojan horses. They are related to spam, but affect the \MTA less, as they are in the mail body.
-message body <-> envelope, header
-where to filter what
 \subsubsection*{\masqmail\ in five years}
 Now how could \masqmail\ be like in, say, five years?
+---
+A design from scratch?
+<< what would be needed (effort) >>
+But how is the effort of this complete rewrite compared to what is gained afterwards?
+<< would one create it at all? >>
+---
 << plans to get masqmail more popular again (if that is the goal) >>
 << More users >>
 \section{Work to do}
 << short term goals --- long term goals >>
+do it like sendmail: first do the most needed stuff on the old design to make it still usable. Then design a new version from scratch, for the future.
 << which parts to take out and do within the thesis >>

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 163:5681a18270b5