1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Jan 24 14:26:59 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Jan 24 17:01:34 2009 +0100
     1.3 @@ -100,12 +100,20 @@
     1.4  Several ways to restrict access are available. The most simple one is restriction by the \NAME{IP} address. No extra complexity is added this way but the \NAME{IP} addresses need to be static or within known ranges. This approach is often used to allow relaying for local nets. The access check can be done by the \MTA\ or by a guard (e.g.\ \NAME{TCP} \name{Wrappers}) before. The main advantage here is the minimal setup and maintenance work needed. This kind of access restriction is important to be implemented.
     1.5  
     1.6  This authentication based on \NAME{IP} addresses is impossible in situations where hosts with changing \NAME{IP} addresses, that are not part of a known sub net, need access. Then a authentication mechanism based on some \emph{secret} is required. Three common approaches exist:
     1.7 +
     1.8  \begin{enumerate}
     1.9  	\item \SMTP-after-\NAME{POP}: Uses authentication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards. The variant \SMTP-after-\NAME{IMAP} exists too.
    1.10  	\item \SMTP\ authentication: An extension to \SMTP. It allows to request authentication before mail is accepted. Here no helper protocols are needed.
    1.11  	\item Certificates: The identity of a user or a host is confirmed by certificates that are signed by trusted authorities. Certificates are closely related to encryption, they do normally satisfy both needs---encrypt the data transmission and allow to identify the remote user/host by his certificate.
    1.12  \end{enumerate}
    1.13 -At least one of the secret-based mechanisms should be supported.
    1.14 +
    1.15 +Static authentication is the preferred type of authenticating clients. It should be chosen if possible. This means if the \MTA\ resides within a trusted network, or it is possible to define trusted network segments on basis of \NAME{IP} addresses, then static authentication is the best choice.
    1.16 +
    1.17 +If the \MTA\ does its job in an untrusted network, if it can be expected that forged \NAME{IP} addresses will appear, if mobile clients should have access, then dynamic authentication should be used.
    1.18 +
    1.19 +Any combination is possible too. For example is it preferred to allow relay access only to authenticated users. Either clients in local networks which are authenticated by their \NAME{IP} addresses or remote clients that authenticate by a secret-based method.
    1.20 +
    1.21 +Static authentication is simpler and requires less administration work but is has limitations---dynamic authentication should be used if static authentication reaches a limit. At least one of the secret-based mechanisms should be supported.
    1.22  
    1.23  
    1.24  
    1.25 @@ -153,12 +161,15 @@
    1.26  
    1.27  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.
    1.28  
    1.29 -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:double-mta-setup}).
    1.30 +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}).
    1.31  
    1.32  
    1.33  
    1.34  \paragraph{\RF10: Archiving}
    1.35 -Mail archiving and auditability become more important as email establishes as technology for serious business communication. It is also a must for companies in many countries. << SOX >> %fixme: cite SOX
    1.36 +Mail archiving and auditability become more important as email establishes as technology for serious business communication. It is also a must for companies in many countries.
    1.37 +
    1.38 +<< \textbf{SOX} >> %fixme: cite SOX
    1.39 +
    1.40  The ability to archive verbatim copies of every mail coming into and every mail going out of the system, with relation between them, appears to be a goal to achieve.
    1.41  
    1.42  \postfix\ for example has a \texttt{always\_bcc} feature, to send a copy of every outgoing mail to a definable recipient. At least this functionality should be given, although a more complete approach, like \qmail\ provides, is preferable. \qmail\ is able to save copies of all sent and received messages and additionally complete \SMTP\ dialogs \cite[page~12]{sill02}.