Mercurial > docs > diploma
comparison thesis/tex/4-MasqmailsFuture.tex @ 173:c51f1be54224
wrote about spam prevention and malware checking
author | meillo@marmaro.de |
---|---|
date | Tue, 23 Dec 2008 13:13:05 +0100 |
parents | 5c873e6478ef |
children | 7781ad0811f7 |
comparison
equal
deleted
inserted
replaced
172:5c873e6478ef | 173:c51f1be54224 |
---|---|
284 | 284 |
285 | 285 |
286 | 286 |
287 \subsubsection*{Spam prevention} | 287 \subsubsection*{Spam prevention} |
288 | 288 |
289 | 289 Spam is a major threat to email, as described in section \ref{sec:swot-analysis}. The two main problems are forgable sender addresses and that it is cheap to send hundreds of thousands of messages. Hence, spam senders can operate in disguise and have minimal cost. |
290 where to filter what | 290 |
291 | 291 As spam is not just a nuisance for end users, but also for the infrastructure---the \mta{}s---by increasing the amount of mail messages, \MTA{}s need to protect themself. Two approaches are used. |
292 | 292 |
293 postfix: | 293 First refusing spam during the \SMTP\ dialog. This is the way it was meant by the designers of the \SMTP\ protocol. They thought checking the sender and reciptient mail addresses would be enough, but as they are forgable it is not. More and more complex checks need to be done. Checking needs time, but \SMTP\ dialogs time out if it takes too long. Thus only limited time can be used, during the \SMTP\ dialog, for checking if a message seems to be spam. The advantage is that acceptance of bad messages can be simply refused---no responsibility for the message is takes and no further system load is added. |
294 content-filter: arbitrary programs that talk smtp, can filter, rewrite or delete mail | 294 |
295 - before-queue-c-f: need to be fast, can prevent system load | 295 Second checking for spam after the mail was accepted and queued. Here more processing time can be invested, so more detailed checks can be done. But, as responsibility for messages was taken by accepting them, it is no choice to simply delete spam mail. Checks for spam do not lead to sure results, they just indicate the possibility the message is unwanted mail. \person{Eisentraut} indicates actions to take after a message is recognized as probably spam \cite[pages 18--20]{eisentraut05}. The only acceptable one, for mail the \MTA\ is responsible for, is adding further or rewriting existent header lines. Thus all further work on the message is the same as for non-spam messages. |
296 - after-queue-c-f: need more resources in global, more load | 296 |
297 | 297 Modern \MTA{}s use both techniques in combination. Checks during the \SMTP\ dialog tend to be implemented in the \mta\ to make it fast; checks after the message was queued are often done using external programs (\name{spamassassin} is a well known one). \person{Eisentraut} sees the checks during the \SMTP\ dialog to be essentiell: ``Ganz ohne Analyse während der SMTP-Phase kommt sowieso kein MTA aus, und es ist eine Frage der Einschätzung, wie weit man diese Phase belasten möchte.''\cite[page 25]{eisentraut05} (translated: ``No \MTA\ can go without analysis during the \SMTP\ dialog, anyway, and it is a question of estimation how much to stress this period.'') |
298 exim: | 298 |
299 acls: to filter, what to accept (hook into smtp dialog) (complex) | 299 \NAME{DNS} blacklists (short: \NAME{DNSBL}) and \name{greylisting} are checks to be done before accepting the message. Invoking \name{spamassassin}, to add headers containing the estimated spam probability, is best to be invoked after the message is queued. |
300 routers: take recipient address and choose a matching transport | 300 |
301 transports: ways to deliver mail (smtp, local) | 301 |
302 | |
303 | |
304 postfix: after-queue-content-filter (smtp communication) | |
305 exim: content-scan-feature (analyses the content: MIME stuff, blacklisted words, virus scanning) (all within smtp dialog) | |
306 sendmail: milter (tcp or unix sockets) | |
307 | |
308 checks while smtp dialog (pre-queue): in MTA implemented (need to be fast) | |
309 checks when mail is accepted and queued: external (amavis, spamassassin) | |
310 | |
311 | |
312 | |
313 | |
314 | |
315 | |
316 what do do with recognized mail? | |
317 - reject (only possible if recognized during SMTP dialog) | |
318 - forward with added header line or changed subject | |
319 (eisentraut05: page 18--20) | |
320 | |
321 check incoming and outgoing mail | |
322 (eisentraut05: page 21) | |
323 | |
324 | |
325 milter: | |
326 communication with external daemons via a special protocol | |
327 at various times in the smtp dialog possible | |
328 can reject, delete or alter messages | |
329 http://milter.org | |
330 (eisentraut05: page 69) | |
331 | |
332 | |
333 use SA with exim: | |
334 - with transport: piped into sa | |
335 - content-scanning-feature: with ACL during smtp dialog | |
336 - plugin: sa-exim | |
337 - within amavis | |
338 | |
339 use SA with sendmail: | |
340 - with milter | |
341 - within mimedefang or amavis | |
342 | |
343 use SA with postfix: | |
344 - within amavis or mailfilter | |
345 | |
346 | |
347 (eisentraut05: page 25) ``Ganz ohne Analyse während der SMTP-Phase kommt sowieso kein MTA aus, und es ist eine Frage der Einschätzung, wie weit man diese Phase belasten möchte.'' | |
348 | |
349 | |
350 DNSBL can contain: | |
351 - open relays | |
352 - dynamic IP addresses | |
353 - verified spam sources | |
354 - open multistage relays | |
355 - vulnerable CGI scripts | |
356 - open proxy servers | |
357 example: NJABL (http://njabl.org) | |
358 | |
359 DNSBL in smpt dialog is aggressive and can lead to problems (eisentraut05: page 126) | |
360 | |
361 | |
362 greylisting: | |
363 if first contact from that address: temp failure and add to list | |
364 sender will retry, then accept | |
365 | |
366 ``Das Greylisting zählt derzeit zu den effektivsten Methoden, um gegen unerwünschte E-Mails vorzugehen. Allein durch Greylisting können derzeit rund 70\% des potenziellen Spam-Aufkommens auf einem Mailserver vollständig geblockt werden. Allerdings ist es auch nur eine Frage der Zeit, bis sich die Gemeinde der Spammer und Virenautoren auf diese Methode der Spam-Bekämpfung eingerichtet und entsprechende Queues in ihre Software eingebaut hat.''(eisentraut05: page 138) | |
367 Probleme: load balancing using multiple servers with different IPs. | |
368 postfix: with policy server | |
369 exim: direct in config | |
370 sendmail: with greylist milter | |
371 | |
372 | |
373 | |
374 hashcash | |
375 | 302 |
376 | 303 |
377 \subsubsection*{Virus checking} | 304 \subsubsection*{Virus checking} |
378 | 305 |
379 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. | 306 Related to spam is malicous content (short: \name{malware}) like viruses, worms, trojan horses. They, in contrast to spam, do not affect the \MTA\ itself, as they are in the mail body. The same situation in the real world is post offices opening letters to check if they contain something that could harm the recipient. This is not a mail transport concern. Apart of not being the right program to do the job, the \MTA\---the one which is responsible for the recipient---is at a good position to do this work. |
380 | 307 |
381 message body <-> envelope, header | 308 In any way should malware checking be done by external programs that may be invoked by the \mta. But using mail deliver and processing agents, like \name{procmail}, appear to be better suited locations to invoke content scanners. |
382 | 309 |
383 | |
384 anti-virus: clamav | |
385 postfix: via amavis | |
386 exim: via content-scanning-feature called from acl | |
387 sendmail: with milter | |
388 procmail | |
389 | |
390 | |
391 virus scanner work on file level | |
392 amavis receives mail via smtp or pipe, splits it in its parts (MIME) and extracks archives, the come the virus scanners | |
393 if the mail is okay, it goes via smtp to a second mta | |
394 | 310 |
395 | 311 |
396 AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner | 312 AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner |
397 \begin{verbatim} | 313 \begin{verbatim} |
398 internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient | 314 internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient |
400 +----------------------------+ | 316 +----------------------------+ |
401 \end{verbatim} | 317 \end{verbatim} |
402 | 318 |
403 postfix and exim can habe both mta servises in the same instance, sendmail needs two instances running. | 319 postfix and exim can habe both mta servises in the same instance, sendmail needs two instances running. |
404 | 320 |
405 what amavis recognizes: | |
406 - invalid headers | |
407 - banned files | |
408 - viruses | |
409 - spam (using spam assassin) | |
410 | |
411 | |
412 mimedefang: uses milter interface with sendmail | |
413 | |
414 | |
415 MailScanner: | 321 MailScanner: |
416 incoming queue --> MailScanner --> outgoing queue | 322 incoming queue --> MailScanner --> outgoing queue |
417 | 323 |
418 postfix: with one instance possible, exim and sendmail need two instances running | 324 postfix: with one instance possible, exim and sendmail need two instances running |
419 | 325 |
326 | |
327 %message body <-> envelope, header | |
328 % | |
329 %anti-virus: clamav | |
330 %postfix: via amavis | |
331 %exim: via content-scanning-feature called from acl | |
332 %sendmail: with milter | |
333 %procmail | |
334 % | |
335 %virus scanner work on file level | |
336 %amavis receives mail via smtp or pipe, splits it in its parts (MIME) and extracks archives, the come the virus scanners | |
337 %if the mail is okay, it goes via smtp to a second mta | |
338 | |
339 %what amavis recognizes: | |
340 %- invalid headers | |
341 %- banned files | |
342 %- viruses | |
343 %- spam (using spam assassin) | |
344 % | |
345 %mimedefang: uses milter interface with sendmail | |
420 | 346 |
421 | 347 |
422 | 348 |
423 \subsubsection*{Archiving} | 349 \subsubsection*{Archiving} |
424 | 350 |