Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 385:2a2f51551081

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
corrected ch06; and small changes in ch05
author meillo@marmaro.de
date Fri, 06 Feb 2009 13:00:32 +0100
parents f180f38d4ca9
children 16d8eacf60e1
comparison
equal deleted inserted replaced
384:acbdd61c4f61 385:2a2f51551081
13 13
14 The three most important work tasks are implementable by improving the current code or by adding wrappers or interposition filters. The following sections describe solution approaches to do that work. 14 The three most important work tasks are implementable by improving the current code or by adding wrappers or interposition filters. The following sections describe solution approaches to do that work.
15 15
16 16
17 17
18 \subsection{Encryption (\TODO\,1)} 18 \subsection{Encryption}
19 19
20 Encryption should be the first functionality to be added to the current code. The requirement was already discussed on page~\pageref{requirement-encryption}. As explained there, \NAME{STARTTLS} encryption---defined in \RFC\,2487---should be added to \masqmail. 20 Encryption (\TODO\,1) should be the first functionality to be added to the current code. The requirement was already discussed on page~\pageref{requirement-encryption}. As explained there, \NAME{STARTTLS} encryption---defined in \RFC\,2487---should be added to \masqmail.
21 21
22 This work requires changes mainly in three source files: \path{smtp_in.c}, \path{smtp_out.c}, and \path{conf.c}. 22 This work requires changes mainly in three source files: \path{smtp_in.c}, \path{smtp_out.c}, and \path{conf.c}.
23 23
24 The first file includes the functionality for the \SMTP\ server. It needs to offer \NAME{STARTTLS} support to clients and needs to initiate the encryption when the client requests it. Additionally, the server should be able to insist on encryption before it accepts any message, if this is wished by the administrator. %fixme 24 The first file includes the functionality for the \SMTP\ server. It needs to offer \NAME{STARTTLS} support to clients and needs to initiate the encryption when the client requests it. Additionally, the server should be able to insist on encryption before it accepts any message, if this is wished by the administrator. %fixme
25 25
42 42
43 43
44 44
45 45
46 46
47 \subsection{Authentication (\TODO\,2)} 47 \subsection{Authentication}
48 48
49 Authentication is the second function to be added. It is important to restrict the access to \masqmail, especially for mail relay. The requirements for authentication where identified on page~\pageref{requirement-authentication}. 49 Authentication (\TODO\,2) is the second function to be added. It is important to restrict the access to \masqmail, especially for mail relay. The requirements for authentication where identified on page~\pageref{requirement-authentication}.
50 50
51 Static access restriction, based on the \NAME{IP} address is already possible by using \NAME{TCP} \name{Wrappers}. This makes it easy to refuse all connections from outside the local network for example, which is a good prevention against being an open relay. More detailed static restrictions, like splitting between mail for users on the system and mail for relay, should \emph{not} be added to the current code. This is a concern for the new design. 51 Static access restriction, based on the \NAME{IP} address is already possible by using \NAME{TCP} \name{Wrappers}. This makes it easy to refuse all connections from outside the local network for example, which is a good prevention against being an open relay. More detailed static restrictions, like splitting between mail for users on the system and mail for relay, should \emph{not} be added to the current code. This is a concern for the new design.
52 52
53 \subsubsection*{One of the dynamic methods} 53 \subsubsection*{One of the dynamic methods}
54 54
91 91
92 92
93 \subsection{Security} 93 \subsection{Security}
94 \label{sec:current-code-security} 94 \label{sec:current-code-security}
95 95
96 Improvements to \masqmail's security are an important requirement and are the third task to be worked on. Retrofitting security \emph{into} \masqmail\ is not or hardly possible as it was explained in section~\ref{sec:discussion-further-devel}. But adding wrappers and interposition filters can be a large step towards security. 96 Improvements to \masqmail's security (\TODO\,3) are an important requirement and are the third task to be worked on. Retrofitting security \emph{into} \masqmail\ is not or hardly possible as it was explained in section~\ref{sec:discussion-further-devel}. But adding wrappers and interposition filters can be a large step towards security.
97 97
98 \subsubsection*{Mail security layers} 98 \subsubsection*{Mail security layers}
99 99
100 At first mail security layers like \name{smap} come to mind. The market share analysis in section~\ref{sec:market-share} identified such software. Mail security layers are interposition filters that are located between the untrusted network and the \MTA. They accept mail in replacement for the \MTA\ in order to separate the \MTA\ from the untrusted network. Thus they are \name{proxies}. 100 At first mail security layers like \name{smap} come to mind. The market share analysis in section~\ref{sec:market-share} identified such software. Mail security layers are interposition filters that are located between the untrusted network and the \MTA. They accept mail in replacement for the \MTA\ in order to separate the \MTA\ from the untrusted network. Thus they are \name{proxies}.
101 101