Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 161:18b7b517e2dd

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
wrote about discussion on architecture
author meillo@marmaro.de
date Wed, 17 Dec 2008 18:48:17 +0100
parents 0b17f6e5edae
children 5681a18270b5
comparison
equal deleted inserted replaced
160:d8ad54f11e88 161:18b7b517e2dd
58 58
59 \subsubsection*{Spam handling} 59 \subsubsection*{Spam handling}
60 Spam is a major threat. According to the \NAME{SWOT} analysis, the goal is to reduce it to a bearable level. Spam fighting is a war are where the good guys tend to lose. Putting too much effort there will result in few gain. Real success will only be possible with new---better---protocols and abandonning the weak legacy technologies. Hence \masqmail\ should be able to provide state-of-the-art spam protection, but not more. 60 Spam is a major threat. According to the \NAME{SWOT} analysis, the goal is to reduce it to a bearable level. Spam fighting is a war are where the good guys tend to lose. Putting too much effort there will result in few gain. Real success will only be possible with new---better---protocols and abandonning the weak legacy technologies. Hence \masqmail\ should be able to provide state-of-the-art spam protection, but not more.
61 61
62 62
63 \subsubsection*{Security}
64 \MTA{}s are critical points for computer security, as they are accessable from external networks. They must be secured with high effort. Properties like high priviledge level, work load influenced from extern, work on unsafe data, and demand for reliability, increase the security needed. Unsecure and unreliable \mta{}s are of no value. \masqmail\ needs to b e secure enough for its target field of operation.
65
66
63 \subsubsection*{Easy configuration} 67 \subsubsection*{Easy configuration}
64 Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common setups should be configurable with single actions by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several standard setups. 68 Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common setups should be configurable with single actions by the user. Complex configuration should be possible, but focused must be the most common form of configuration: choosing one of several standard setups.
65 69
66 70
67 71
68 72
69 73
70 74
71 75 \section{Discussion on architecture}
72 \section{Directions to go} 76
73 77 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
74 This section discusses about what shapes \masqmail\ could have---which directions the development could go to. 78
75 79 \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.
76
77
78
79 \subsection{Access and Auth}
80
81 easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
82 if dynamic remote hosts need access: some auth is needed
83 - SASL
84 - POP/IMAP: pop-before-smtp, DRAC, WHOSON
85 - TLS (certificates)
86
87 ``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)
88
89
90
91 postfix: after-queue-content-filter (smtp communication)
92 exim: content-scan-feature
93 sendmail: milter (tcp or unix sockets)
94
95 checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
96 checks when mail is accepted and queued: external (amavis, spamassassin)
97
98 anti-virus: clamav
99
100 AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
101 internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient
102 | |
103 +----------------------------+
104 mail scanner:
105 incoming queue --> mail scanner --> outgoing queue
106
107 mimedefang: uses milter interface with sendmail
108
109
110
111 \subsection{Architecture}
112
113 The programs architecture is maybe the most influencing design decision with the greatest impact on the programs further capabilities. %fixme: search quote ... check if good
114
115 \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, 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.
116 80
117 Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure. 81 Figure \ref{fig:masqmail-arch} is an attempt to depict \masqmail's internal structure.
118 82
119 \begin{figure} 83 \begin{figure}
120 \begin{center} 84 \begin{center}
122 \end{center} 86 \end{center}
123 \caption{Internal architecture of \masqmail} 87 \caption{Internal architecture of \masqmail}
124 \label{fig:masqmail-arch} 88 \label{fig:masqmail-arch}
125 \end{figure} 89 \end{figure}
126 90
91 \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.
92
93 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?
94
95
96
97
98 A secure architecture is of need.
99
100
101
102
103
127 104
128 105
129 (ssl) 106 (ssl)
130 -> msg-in (local or remote protocol handlers) 107 -> msg-in (local or remote protocol handlers)
131 -> spam-filter (and more) 108 -> spam-filter (and more)
138 << what would be needed (effort) >> 115 << what would be needed (effort) >>
139 116
140 << would one create it at all? >> 117 << would one create it at all? >>
141 118
142 << should it be done? >> 119 << should it be done? >>
120
143 121
144 http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command 122 http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command
145 http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security 123 http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security
146 http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery 124 http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery
147 http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format 125 http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format
157 135
158 136
159 137
160 138
161 139
140 \subsection{Access and Auth}
141
142 easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
143 if dynamic remote hosts need access: some auth is needed
144 - SASL
145 - POP/IMAP: pop-before-smtp, DRAC, WHOSON
146 - TLS (certificates)
147
148 ``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)
149
150
151
152 postfix: after-queue-content-filter (smtp communication)
153 exim: content-scan-feature
154 sendmail: milter (tcp or unix sockets)
155
156 checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
157 checks when mail is accepted and queued: external (amavis, spamassassin)
158
159 anti-virus: clamav
160
161 AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
162 internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient
163 | |
164 +----------------------------+
165 mail scanner:
166 incoming queue --> mail scanner --> outgoing queue
167
168 mimedefang: uses milter interface with sendmail
169
170
171
172
173
162 174
163 175
164 \subsection{spam and malicious content} 176 \subsection{spam and malicious content}
165 177
166 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. 178 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.
173 185
174 186
175 187
176 188
177 189
190 \section{Directions to go}
191
192 This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
193
178 194
179 195
180 196
181 197
182 \subsubsection*{\masqmail\ in five years} 198 \subsubsection*{\masqmail\ in five years}