# HG changeset patch
# User meillo@marmaro.de
# Date 1229614902 -3600
# Node ID a7fd6d974d3c5a47f88750860dc15ba0db800b1e
# Parent  0e208e23aac30dae905b3760716e89c9b3e66044
added lots of notes about spam, malware, auth, ...

diff -r 0e208e23aac3 -r a7fd6d974d3c thesis/tex/4-MasqmailsFuture.tex
--- a/thesis/tex/4-MasqmailsFuture.tex	Thu Dec 18 13:47:27 2008 +0100
+++ b/thesis/tex/4-MasqmailsFuture.tex	Thu Dec 18 16:41:42 2008 +0100
@@ -100,6 +100,7 @@
 \begin{quote}
 A perfect example is the contrast between the feature envy early \sendmail\ architecture implemented as one process and the simple, modular architecture of \qmail. The security of \qmail\ comes from its compartmentalized simple processes that perform one task only and are therefor testable for security. \cite[page 64]{hafiz05}
 \end{quote}
+As well does \person{Dent}: ``The modular architecture of Postfix forms the basis for much of its security.''\cite[page 7]{dent04}
 
 Modularity is needed for supporting modern \MTA\ requirements, providing a clear interface to add further functionality without increasing the overall complexity much. Modularity is also an enabler for security. Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
 \begin{quote}
@@ -121,18 +122,13 @@
 This section tries to identify the needed modules for a modern \MTA. They are later the pieces of which the new architecture is built of.
 
 
-\subsubsection*{The simplest MTA}
-This view of the problem is taken from \person{Hafiz} \cite[pages 3-5]{hafiz05}.
+\subsubsection*{The simple view}
 
-The basic job of a \mta\ is to tranport mail from a sender to a recipient. The simplest \MTA\ therefor needs at least a mail receiving facility and a mail sending facility. This basic \MTA---following the definition of an \MTA---is much to abstract. Hence a next step to add some important features is needed, the result is an operational \MTA.
+The basic job of a \mta\ is to tranport mail from a sender to a recipient. This is the definition of such a program and this is how \person{Dent}\cite[page 19]{dent04} and \person{Hafiz} \cite[pages 3-5]{hafiz05} start on the design.
 
+An \MTA\ therefor needs at least a mail receiving facility and a mail sending facility. But both, and probably all \MTA\ developers (excluded the only forwarders), see the need for a mail queue. A mail queue removed the need to deliver at once. They also provide fail-safe storage of mails until they are delivered.
 
 
-\subsubsection*{Mail queue}
-
-\person{Hafif} adds a mail queue to make it possible to not deliver at once.
-
-Mail queues are probably used in all \mta{}s, excluding the simple forwarders. A mail queue is a essential requirement for \masqmail, as it is to be used for non-permanent online connections.
 
 
 \subsubsection*{Incoming channels}
@@ -158,24 +154,134 @@
 This means outgoing connections, piping mails into local commands needs to be implemented.
 
 
-\subsubsection*{Mail queue (again)}
+
+\subsubsection*{Sanitize mail}
+generate valid headers: add, rewrite
+... better before inserting into the queue
+
+(determine the method to send at that position?)
+
+
+
+
+\subsubsection*{Aliasing}
+
+where to expand aliases?
+
+
+
+\subsubsection*{Mail queue}
+
+Mail queues are probably used in all \mta{}s, excluding the simple forwarders. A mail queue is a essential requirement for \masqmail, as it is to be used for non-permanent online connections.
+
+
+
 
 
 
 
 \subsubsection*{Authentication}
 
-easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
-if dynamic remote hosts need access: some auth is needed
-- SASL
-- POP/IMAP: pop-before-smtp, DRAC, WHOSON
-- TLS (certificates)
+either by
+- network/ip address
+	easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
+or
+- some kind of auth (for dynamic remote hosts)
+	adds complexity
+	- SASL
+	- POP/IMAP: pop-before-smtp, DRAC, WHOSON
+	- TLS (certificates)
 
-``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)
+\begin{quote}
+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.
+\cite[page 44]{dent04}
+\end{quote}
 
 
 \subsubsection*{Encryption}
 
+TLS/SSL prevents attackers to listen on the cable
+but it does not prevent man-in-the-middle attacks
+signed certificates help here
+
+
+ch /usr/share/ssl/misc
+
+create new CA:
+\begin{verbatim}
+	CA.pl -newca
+		country: DE
+		state: schwaben
+		city: Ulm
+		company: 
+		section:
+		name:
+		emailaddress:
+\end{verbatim}
+
+generate ssl key:
+\begin{verbatim}
+	CA.pl -newreq
+		... the same questions
+\end{verbatim}
+
+sign request with CA:
+\begin{verbatim}
+	CA.pl -sign
+\end{verbatim}
+
+remove passphrase from private key:
+\begin{verbatim}
+	openssl rsa <newreq.pem >key.pem
+	(to be used by programs automaticly)
+\end{verbatim}
+
+secure:
+\begin{verbatim}
+	chmod 400 *.pem
+	cp newcert.pem /etc/postfix/cert.pem
+	cp key.pem /etc/postfix/key.pem
+	cp demoCA/cacert.pem /etc/postfix/CAcert.pem
+	chmode 400 /etc/postfix/*.pem
+
+	mkdir /etc/stunnel
+	cat newcert.pem key.pem >/etc/stunnel/stunnel.pem
+	chmod 400 /etc/stunnel/stunnel.pem
+	(check /etc/stunnel with `stunnel -V')
+\end{verbatim}
+
+
+set up stunnels for POP, etc:
+\begin{verbatim}
+	nmap localhost
+	stunnel -d pop3s -r localhost:pop3 -p /etc/stunnel/stunnel.pem
+	stunnel -d imaps -r localhost:imap -p /etc/stunnel/stunnel.pem
+	nmap localhost
+		pop3s 995
+		imaps 993
+\end{verbatim}
+
+do not use stunnel wit SMTP:
+because all incoming mail would be from 127.0.0.1 !!
+use STARTTLS instead
+
+postfix: main.cf
+\begin{verbatim}
+	smtpd_use_tls = yes
+	smtpd_tls_received_header = no (does not log in received headers)
+
+	smtpd_tls_key_file = /etc/postfix/key.pem
+	smtpd_tls_cert_file = /etc/postfix/cert.pem
+	smtpd_tls_CA_file = /etc/postfix/CAcert.pem
+
+	smtp_use_tls = yes  (use TLS for sending)
+	smtp_tls_key_file = /etc/postfix/key.pem
+	smtp_tls_cert_file = /etc/postfix/cert.pem
+	smtp_tls_CA_file = /etc/postfix/CAcert.pem
+\end{verbatim}
+
+
+
 
 \subsubsection*{Spam prevention}
 
@@ -183,22 +289,88 @@
 where to filter what
 
 
+postfix:
+content-filter: arbitrary programs that talk smtp, can filter, rewrite or delete mail
+- before-queue-c-f: need to be fast, can prevent system load
+- after-queue-c-f: need more resources in global, more load
+
+exim:
+acls: to filter, what to accept (hook into smtp dialog) (complex)
+routers: take recipient address and choose a matching transport
+transports: ways to deliver mail (smtp, local)
+
+
 postfix: after-queue-content-filter (smtp communication)
-exim: content-scan-feature
+exim: content-scan-feature (analyses the content: MIME stuff, blacklisted words, virus scanning) (all within smtp dialog)
 sendmail: milter (tcp or unix sockets)
 
 checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
 checks when mail is accepted and queued: external (amavis, spamassassin)
 
 
-AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
-internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient
-                |                            |
-                +----------------------------+
-mail scanner:
-incoming queue --> mail scanner --> outgoing queue
 
-mimedefang: uses milter interface with sendmail
+
+
+
+what do do with recognized mail?
+- reject (only possible if recognized during SMTP dialog)
+- forward with added header line or changed subject
+(eisentraut05: page 18--20)
+
+check incoming and outgoing mail
+(eisentraut05: page 21)
+
+
+milter:
+communication with external daemons via a special protocol
+at various times in the smtp dialog possible
+can reject, delete or alter messages
+http://milter.org
+(eisentraut05: page 69)
+
+
+use SA with exim:
+- with transport: piped into sa
+- content-scanning-feature: with ACL during smtp dialog
+- plugin: sa-exim
+- within amavis
+
+use SA with sendmail:
+- with milter
+- within mimedefang or amavis
+
+use SA with postfix:
+- within amavis or mailfilter
+
+
+(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.''
+
+
+DNSBL can contain:
+- open relays
+- dynamic IP addresses
+- verified spam sources
+- open multistage relays
+- vulnerable CGI scripts
+- open proxy servers
+example: NJABL (http://njabl.org)
+
+DNSBL in smpt dialog is aggressive and can lead to problems (eisentraut05: page 126)
+
+
+greylisting:
+if first contact from that address: temp failure and add to list
+sender will retry, then accept
+
+``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)
+Probleme: load balancing using multiple servers with different IPs.
+postfix: with policy server
+exim: direct in config
+sendmail: with greylist milter
+
+
+
+hashcash
 
 
 \subsubsection*{Virus checking}
@@ -209,14 +381,48 @@
 
 
 anti-virus: clamav
+postfix: via amavis
+exim: via content-scanning-feature called from acl
+sendmail: with milter
+procmail
 
 
+virus scanner work on file level
+amavis receives mail via smtp or pipe, splits it in its parts (MIME) and extracks archives, the come the virus scanners
+if the mail is okay, it goes via smtp to a second mta
+
+
+AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
+\begin{verbatim}
+internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient
+                |                            |
+                +----------------------------+
+\end{verbatim}
+
+postfix and exim can habe both mta servises in the same instance, sendmail needs two instances running.
+
+what amavis recognizes:
+- invalid headers
+- banned files
+- viruses
+- spam (using spam assassin)
+
+
+mimedefang: uses milter interface with sendmail
+
+
+MailScanner:
+incoming queue --> MailScanner --> outgoing queue
+
+postfix: with one instance possible, exim and sendmail need two instances running
+
 
 
 
 \subsubsection*{Archiving}
 
 
+\texttt{always\_bcc} feature of postfix