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