1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Mon Dec 22 20:42:33 2008 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Tue Dec 23 13:13:05 2008 +0100
     1.3 @@ -286,112 +286,28 @@
     1.4  
     1.5  \subsubsection*{Spam prevention}
     1.6  
     1.7 +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.
     1.8  
     1.9 -where to filter what
    1.10 +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.
    1.11  
    1.12 +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.
    1.13  
    1.14 -postfix:
    1.15 -content-filter: arbitrary programs that talk smtp, can filter, rewrite or delete mail
    1.16 -- before-queue-c-f: need to be fast, can prevent system load
    1.17 -- after-queue-c-f: need more resources in global, more load
    1.18 +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.
    1.19  
    1.20 -exim:
    1.21 -acls: to filter, what to accept (hook into smtp dialog) (complex)
    1.22 -routers: take recipient address and choose a matching transport
    1.23 -transports: ways to deliver mail (smtp, local)
    1.24 +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.'')
    1.25  
    1.26 +\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.
    1.27  
    1.28 -postfix: after-queue-content-filter (smtp communication)
    1.29 -exim: content-scan-feature (analyses the content: MIME stuff, blacklisted words, virus scanning) (all within smtp dialog)
    1.30 -sendmail: milter (tcp or unix sockets)
    1.31  
    1.32 -checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
    1.33 -checks when mail is accepted and queued: external (amavis, spamassassin)
    1.34 -
    1.35 -
    1.36 -
    1.37 -
    1.38 -
    1.39 -
    1.40 -what do do with recognized mail?
    1.41 -- reject (only possible if recognized during SMTP dialog)
    1.42 -- forward with added header line or changed subject
    1.43 -(eisentraut05: page 18--20)
    1.44 -
    1.45 -check incoming and outgoing mail
    1.46 -(eisentraut05: page 21)
    1.47 -
    1.48 -
    1.49 -milter:
    1.50 -communication with external daemons via a special protocol
    1.51 -at various times in the smtp dialog possible
    1.52 -can reject, delete or alter messages
    1.53 -http://milter.org
    1.54 -(eisentraut05: page 69)
    1.55 -
    1.56 -
    1.57 -use SA with exim:
    1.58 -- with transport: piped into sa
    1.59 -- content-scanning-feature: with ACL during smtp dialog
    1.60 -- plugin: sa-exim
    1.61 -- within amavis
    1.62 -
    1.63 -use SA with sendmail:
    1.64 -- with milter
    1.65 -- within mimedefang or amavis
    1.66 -
    1.67 -use SA with postfix:
    1.68 -- within amavis or mailfilter
    1.69 -
    1.70 -
    1.71 -(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.''
    1.72 -
    1.73 -
    1.74 -DNSBL can contain:
    1.75 -- open relays
    1.76 -- dynamic IP addresses
    1.77 -- verified spam sources
    1.78 -- open multistage relays
    1.79 -- vulnerable CGI scripts
    1.80 -- open proxy servers
    1.81 -example: NJABL (http://njabl.org)
    1.82 -
    1.83 -DNSBL in smpt dialog is aggressive and can lead to problems (eisentraut05: page 126)
    1.84 -
    1.85 -
    1.86 -greylisting:
    1.87 -if first contact from that address: temp failure and add to list
    1.88 -sender will retry, then accept
    1.89 -
    1.90 -``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)
    1.91 -Probleme: load balancing using multiple servers with different IPs.
    1.92 -postfix: with policy server
    1.93 -exim: direct in config
    1.94 -sendmail: with greylist milter
    1.95 -
    1.96 -
    1.97 -
    1.98 -hashcash
    1.99  
   1.100  
   1.101  \subsubsection*{Virus checking}
   1.102  
   1.103 -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.
   1.104 +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.
   1.105  
   1.106 -message body <-> envelope, header
   1.107 +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.
   1.108  
   1.109  
   1.110 -anti-virus: clamav
   1.111 -postfix: via amavis
   1.112 -exim: via content-scanning-feature called from acl
   1.113 -sendmail: with milter
   1.114 -procmail
   1.115 -
   1.116 -
   1.117 -virus scanner work on file level
   1.118 -amavis receives mail via smtp or pipe, splits it in its parts (MIME) and extracks archives, the come the virus scanners
   1.119 -if the mail is okay, it goes via smtp to a second mta
   1.120 -
   1.121  
   1.122  AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
   1.123  \begin{verbatim}
   1.124 @@ -402,22 +318,32 @@
   1.125  
   1.126  postfix and exim can habe both mta servises in the same instance, sendmail needs two instances running.
   1.127  
   1.128 -what amavis recognizes:
   1.129 -- invalid headers
   1.130 -- banned files
   1.131 -- viruses
   1.132 -- spam (using spam assassin)
   1.133 -
   1.134 -
   1.135 -mimedefang: uses milter interface with sendmail
   1.136 -
   1.137 -
   1.138  MailScanner:
   1.139  incoming queue --> MailScanner --> outgoing queue
   1.140  
   1.141  postfix: with one instance possible, exim and sendmail need two instances running
   1.142  
   1.143  
   1.144 +%message body <-> envelope, header
   1.145 +%
   1.146 +%anti-virus: clamav
   1.147 +%postfix: via amavis
   1.148 +%exim: via content-scanning-feature called from acl
   1.149 +%sendmail: with milter
   1.150 +%procmail
   1.151 +%
   1.152 +%virus scanner work on file level
   1.153 +%amavis receives mail via smtp or pipe, splits it in its parts (MIME) and extracks archives, the come the virus scanners
   1.154 +%if the mail is okay, it goes via smtp to a second mta
   1.155 +
   1.156 +%what amavis recognizes:
   1.157 +%- invalid headers
   1.158 +%- banned files
   1.159 +%- viruses
   1.160 +%- spam (using spam assassin)
   1.161 +%
   1.162 +%mimedefang: uses milter interface with sendmail
   1.163 +
   1.164  
   1.165  
   1.166  \subsubsection*{Archiving}