Mailserver auf Debian mit Imap, Smarthost und Filter

Aus Gargi.org
Zur Navigation springen Zur Suche springen

Wir wollen uns nun für den Hausgebrauch einen kleinen Mailserver einrichten, der für uns einige Aufgaben erledigt. Was wollen wir eigentlich mit unserem Mailserver? Wir haben nun einige Mailboxen extern bei unseren Internetprovidern, Webdiensten oder eigene Webauftritte extern liegen. Diese Mails rufen wir dann normalerweise mit einem Mailprogramm auf unserem Rechner ab. Haben wir nun mehrere Rechner, so muss dies für jede Maschine mühevoll eingerichtet werden. Hier kommt nun unser kleiner Server ins Spiel, der bei uns daheim steht. Hierzu muss dieser natürlich ständig mit dem Internet verbunden sein, wo hier definitiv nur eine echte Flatrate in Frage kommt. Alles andere wäre auch nicht bezahlbar. Zudem wollen wir von extern mit einem Webmailer unsere Mails einsehen können und auch versenden. Dies setzt voraus, dass auf unserem Webserver ein Apache läuft. Entsprechende Sicherheitsmaßnahmen wie Firewall und einem IP Filter wie Fail2ban sollten natürlich aktiviert sein. Als Basis verwende ich dann zudem ein Linux Debian 9 (Stretch).

Wir werden in diesem Tutorial lernen, wie wir E-Mails von unseren externen Mailboxen in einem kurzen Intervall regelmäßig abrufen, diese auf Viren und Spam überprüfen, dann über ein Verteilsystem in unsere lokalen Mailboxen vorsortieren und schon nach jeweiligen Inhalten (Werbung, Privates etc.) aufteilen können, ohne dass entsprechende Filterregeln von lokalen Mailprogrammen erst bemüht werden müssen. Desweiteren müssen wir unserem Server beibringen, auch Mails über einen externen Mailserver (Smarthost) zu versenden und wir richten uns einen kleinen Webmailer ein.

Den Weg einer Mail auf unserem Server habe ich einmal über ein Schema verdeutlicht, das uns zeigen soll, welche Bausteine wir benötigen, um eine Mail bei uns daheim sauber in die Kiste zu bringen:



Hier also einmal den Ablauf: Eine Mail landet auf dem Server unseres Providers und liegt dort in seiner Mailbox. Sie wartet darauf, dass wir diese zunächst mit getmail abrufen. Hier wird bereits dann die Mail mit Spamassassin geprüft, ob diese eine Spam Mail ist. Die Mail wird dann an den Procmail übergeben, der zum einen entscheidet, in welches Postfach und in welchen Ordner des Postfachs die Mail landen wird. Hierbei wird noch überprüft, ob die Mails frei von Viren sind. Dazu wird das Virenprogramm ClamAV mit Clamassassin verwendet. Herr der Mailboxen und den Verzeichnissen dann ist der IMAP Server Dovecot, der allen Mailprogrammen die Verzeichnisse im Netz intern und extern zur Verfügung stellt. Wer dann von außerhalb über einen Browser auf seine Mails zugreifen möchte, der kann das dann mit einem Webmailer auf dem Apache Webserver bewerkstelligen. Als Webmailer nehmen wir dann den Squirrelmail, der unsere Schnittstelle nach außen darstellt. Es kann natürlich sein, dass Ihr gerade über den Webailer eine Mail wieder versenden wollt. Das übernimmt dann der MTA (Mail Transport Agent) Exim4, der diese Mail dann an einen externen SMTP Server des Providers (Smarthost) weitergibt und dieser dann dafür sorgt, dass die Mail auch seinen Empfänger erreicht.

Ihr seht, wir haben einiges vor, dann legen wir doch gleich einmal los!

Installation von Getmail und die Konfiguration

Wir installieren zuerst getmail mit einem

apt-get install getmail4

Wir legen nun eine neuen User getmail an, der für uns in Zukunft die Sache erledigen wird:

adduser getmail

Vergebt hier das Passwort. Da das kein Standarduser sein soll und falls Ihr einen ftp am Laufen habt, dann schließt bitte diesen User vom ftp- Zugriff aus. Dies erledigt Ihr, indem Ihr den User getmail in die Datei /etc/ftpusers eintragt.

nano /etc/ftpusers

Startet nach einer Änderung den proftp neu:

/etc/init.d/proftpd restart

Gleiches machen wir nun mit einem User postfach1. Ihr könnt den Namen frei auswählen, denn das werden dann die Mailnutzer werden, die dann via IMAP ihre Mails abrufen können. Legt auch diese mit adduser an und schließt diese aus dem ftp-Zugriff aus.

Jetzt wollen wir auch nicht, dass eventuell über ssh auf die Mailboxen zugegriffen werden kann. Wenn Ihr einen ssh Clienten nach außen offen habt, dann ist das sicherlich auch ratsam. Ihr könnt das Anmelden (auch damit lokal am Rechner) unterbinden, indem Ihr in der /etc/passwd für den jeweiligen User hinten das /bin/bash in /bin/false abändert. Dann ist auch das Anmelden nicht mehr möglich.

Um jetzt auch ganz sicher zu sein, dass Ihr das richtig konfiguriert habt versucht Euch jeweils mittels ftp und dann nochmal via ssh an beide User anzumelden. Erst wenn sichergestellt ist, dass beide Verbindungen nicht möglich sind können wir weiter machen.

Um später aber einen Test mit getmail durch zu führen muss die Änderung in der /etc/passwd nochmal rückgängig gemacht werden. Aber auch hier gehe ich dann im Bedarfsfall darauf ein.

Wenn das erledigt ist müssen wir aber immer daran denken, dass wir die als root angelegten Dateien später immer dann den jeweiligen User zuweisen, damit es kein Rechteproblem gibt. Darauf gehe ich dann aber noch ein, wenn es soweit ist.

Nun wechseln wir in das Verzeichnis /home/getmail :

cd /home/getmail

und legen ein neues verstecktes Verzeichnis an:

mkdir .getmail

Dort erstellen wir nun eine Konfigurationsdatei:

touch .getmail/mailbox1.conf

Diese befüllen wir nun mit folgenden Inhalt:

[options]
verbose = 0                        
delete = true                           # true= mails werden auf Server gelöscht false= Mails werden nicht gelöscht
read_all = false                        # true= alle Mails werden abgeholt false= nur neue Mails werden abgeholt
message_log = ~/.getmail/mailbox1.log   # Fehler beim Abholen werden in die Logdatei mailbox1 geschrieben

[retriever]
type = SimplePOP3Retriever       
server = mail.euerprovider.de           # Die Adresse des Mailserversers Eures Providers
username = username                     # Der Username des Mailservers
password = euerpasswort                 # Passwort, Achtung, kann gelesen werden, wer auf den Server kommt

[destination]
type = MDA_external                     # Das sagt aus, dass ein externes Programm die Mails übernimmt
path = /usr/bin/procmail                # Procmail nimmt alles in die Hand
arguments = ("-dpostfach1", )           # Der Nutzer postfach1 bekommt die Mails überstellt

(HINWEIS: Bitte entfernt die Kommentare hinten an den Zeilen - alles was mit # losgeht)

Wenn Ihr nun mehrere externe Mailboxen besitzt legt dann für jede Mailbox eine eigene Konfigurationsdatei an. Bennent jede Konfigurationsdatei eindeutig, damit Ihr diese später auseinanderhalten könnt. Zudem legt in jeder Datei fest, welcher Nutzer die Mails dann bekommen soll. Das wird im Bereich

arguments = ("-dxyz", )

festgelegt. xyz = der jeweilige Nutzer, der die Mails bekommen soll.

Damit nur getmail die Datei lesen darf regelt die Zugriffsrechte nun wie folgt: Aus dem Verzeichnis /home/getmail heraus gebt nun folgende Befehle ab:

cd /home/getmail
chown getmail:getmail -R .getmail
chmod 640 .getmail/*

Im Grunde haben wir nun unseren kleinen Dämonen schon fertig, der später regelmäßig all unsere Mailboxen nach neuen E-Mails abklappert. Bedenkt aber, wenn Ihr ein firewall- Skript am Laufen habt, dass Ihr den Port 110 (TCP_OUT) freischaltet, sonst kann Euer Server nicht auf den externen POP3 zugreifen.

Installation von Procmail und die Konfiguration

Procmail bekommt ja nun die Mails alle in einen Topf geschmissen und verteilt die Mails nun nach entsprechenden Schematas in die einzelnen Postfächer der Mailnutzer. Es kann sein, dass procmail bereits schon auf Eurem System vorhanden ist. Um hier sicher zu gehen setzt als root schnell mal ein

apt-get install procmail

ab. Jetzt wechselt in das Verzeichnis des Users postfach1:

cd /home/postfach1

Dort legt nun eine Konfigurationsdatei an:

touch .procmailrc

Zudem zwei neue Verzeichnisse:

mkdir mail
mkdir log

Nun befüllt die .procmailrc mit folgenden Inhalt:

MAILDIR=$HOME/mail               # Hier kommen die Mails rein
LOGFILE=$HOME/log/procmail.log   # Fehlermeldungen werden in der log gespeichert
VERBOSE=on                       

:0                               
* ^TO_.*beispiel.de              # Mails dern Empfänger auf beispiel.de enden 
.test/                           # landen in INBOX.test 

:0
* ^From: .*spammer@domain.com    # Mails von einer bestimmten Adresse werden gelöscht 
/dev/null

:0                              
* ^TO_.*test2@beispiel.de        # alle Mails an eine bestimmte Adresse werden in
.test2/                          # in die INBOX.test2 einsortiert

:0                               
./                               # Alles andere an direkten Posteingang

Folgendes ist hier wichtig: Hinten müssen die Kommentare wieder entfernt werden, sonst werden diese in die Suchkriterien mit eingezogen und es gibt entsprechende Missmatches. Den Ordner ./ auf jeden Fall anlegen! Alternativ vielleicht auch .INBOX.missmatches/ benennen. Denn wenn mal was nicht in den Regeln zutreffen sollte, dann landet die Mail immer erst hier. Dann kann man in der Logfile nachsehen, warum die Mail nicht zugeordnet wurde und entsprechend die Regeln in der .procmailrc anpassen.

Das ^ am Anfang einer Regel bedeutet, dass das Wort am Zeilenanfang gesucht wird. Ein TO oder From im Header steht immer vorne. Mit einem .* vor einem Suchbegriff kann man mögliche zusätzliche Leerzeichen mit einschließen und vermeidet Missmatches bei zusätzlichen Leerzeichen.

Damit zum Schluss alle Zugriffsrechte passen, führen wir dann ein

chown -R postfach1:postfach1 /home/postfach1/

aus. Prüft mit einem ls -la innerhalb des Verzeichnisses dann nach, ob die Dateien und Verzeichnisse dem User postfach1 gehören.

Erster Test

Um nun zu überprüfen, ob die ersten Regeln funktionieren und auch von der Mailbox abgerufen werden kann müsst Ihr Euch als User getmail einloggen. Hierfür müssen wir unsere Sperre in der /etc/passwd rückgängig machen. In der Zeile des Users getmail ändert dort wieder das /bin/false auf /bin/bash ab. Jetzt funktioniert die Anmeldung:

su getmail

Ändert zum Testen auch in Eurer Getmail Config das

delete = true

auf

delete = false

ab, da Ihr garantiert das öfters testen müsst, bis es passt!

Führt nun den Abruf aus:

getmail -v --rcfile ~/.getmail/mailbox1.conf

Wenn Ihr mehrere Boxen abruft, dann einfach diese zusätzlich anhängen:

getmail -v --rcfile ~/.getmail/mailbox1.conf --rcfile ~/.getmail/mailbox2.conf

Wenn alles gut läuft bekommt Ihr eine entsprechende Meldung:

getmail -v --rcfile ~/.getmail/mailbox1.conf
getmail version 4.7.8
Copyright (C) 1998-2007 Charles Cazabon.  Licensed under the GNU GPL version 2.
SimplePOP3Retriever:blah@mail.beispiel.de:110:
  msg  1/14 (2428090 bytes) delivered
  msg  2/14 (3415 bytes) delivered
  msg  3/14 (3253 bytes) delivered
  msg  4/14 (2940 bytes) delivered
  msg  5/14 (4124 bytes) delivered
  msg  6/14 (3687 bytes) delivered
  msg  7/14 (4498 bytes) delivered
  msg  8/14 (5705 bytes) delivered
  msg  9/14 (5377 bytes) delivered
  msg 10/14 (3863 bytes) delivered
  msg 11/14 (4275 bytes) delivered
  msg 12/14 (5422 bytes) delivered
  msg 13/14 (3715 bytes) delivered
  msg 14/14 (4015 bytes) delivered
  14 messages (2482379 bytes) retrieved, 0 skipped

Loggt Euch wieder aus:

exit

Nun geht in das Homverzeichnis des Postfach1 und seht unter /mail nach, ob Ihr Mails dort unter new liegen habt. Wenn diese im Spam Ordner gelandet sind, dann stimmt was mit der procmail Regel nicht und müsst diese anpassen. Zum erneuten Test löscht dann unter /mail alle Verzeichnisse und wiederholt das so lange, bis die Mails korrekt einsortiert werden. Es wird sicherlich hin und wieder Mails geben, die nicht sauber einsortiert werden. Für diese Gelegenheiten müsst Ihr dann Eure Regeln entsprechend anpassen. Die procmailrc wird Euch somit noch lange begleiten bis alles wie gewünscht funktioniert.

Nun werden wir den Mailabruf automatisieren. Dazu öffnet nochmals als user getmail angemeldet die crontab mit

crontab -e

Dort fügt nun Euren Getmail-Aufruf ein und ergänzt die Zeile wie folgt:

*/5 * * * * /usr/bin/getmail -v --rcfile ~/.getmail/mailbox1.conf --rcfile ~/.getmail/mailbox2.conf > /dev/null 2>&1

Das ruft den Prozess nun alle 5 Minuten ab. D.h. alle 5 Minuten werden Eure externen Mailboxen auf neue E-Mails überprüft und dem procmail übergeben, der Weiteres für Euch erledigt, indem er filtert und in Mailboxen verteilt.

Wenn alles glatt läuft, dann meldet Euch als getmail ab und sperrt wieder den Zugriff auf den getmail in der /etc/passwd und setzt dort den User wieder auf /bin/false.

Getmail mit SSL Verbindung

Die Übertragung der Dateien sollte natürlich auch verschlüsselt erfolgen. Die meisten Provider sollten das auch zur Verfügung stellen. Wenn unser Test erfolgreich war, dann stellen wir noch die Konfiguration entsprechend um. Editiert dazu die entsprechende Getmail Konfigurationsdatei:

nano /home/getmail/.getmail/mailbox1.conf

Die Zeile

type = SimplePOP3Retriever

tauscht in

type = SimplePOP3SSLRetriever

aus. Solltet Ihr ein Firewallscript verwenden, dann müsst Ihr als TCP_OUT den Port 995 eintragen.
Führt dann nochmal einen Test wie oben beschrieben durch und prüft damit, ob der Abruf klappt.

Imap mit Dovecot

Beim Imap Server möchte ich es Euch recht einfach machen. Ihr benötigt hierfür einen Installationsbefehl und ein paar Kleinigkeiten zum Editieren.

Editiert zunächst die /etc/hosts

nano /etc/hosts

Die ersten zwei Zeilen sehen ungefähr so aus:

127.0.0.1    localhost
127.0.0.1   meinserver.example.org   meinserver

Damit es später keinen Huddel gibt beim Erstellen der Sicherheitszertifikate ändert diese auf

127.0.0.1    localhost
192.168.1.77 192.168.1.77  meinserver

ab. Die Änderung speichert Ihr ab. Jetzt könnt Ihr die benötigten Programme installieren:

apt-get install dovecot-core dovecot-imapd

Wenn Ihr dann bei der Installation in dem Moment, in dem der Dovecot gestartet wird, eine Meldung

Fatal: Failed to start listeners
failed!

erhaltet, dann kracht es an einer Stelle mit dem IPv6, d.h. wird von Eurem Server nicht unterstützt.
Editiert deshalb die dovecot.conf:

nano /etc/dovecot/dovecot.conf

Schreibt unter die Zeile

#listen = *, ::

folgende Zeile:

listen = *

Startet dann nochmal den Dovecot:

/etc/init.d/dovecot restart

Der Fehler sollte jetzt weg sein und der Dovecot laufen.

Während er Installation werden die Zertifikate

/etc/dovecot/dovecot.pem
/etc/dovecot/private/dovecot.pem

seit neueren Versionen nicht mehr automatisch angelegt, die Ihr für einen gesicherten Abruf benötigt. Falls Ihr keine "offiziellen" Zertifikate bnötigt (z.B. über Letsencrypt), weil Ihr Euren Server ausschließlich intern benutzt, dann könnt Ihr ein Zertifikat mittels des mitgelieferten Scripts erstellen. Dieses installiert ein allgemeines Zertifikat, das für 1 Jahr gültig ist. Als root:

cd /usr/share/dovcot
./mkcert.sh

Ihr wollt das Zertifikat für eine längere Zeit erstellen? Editiert die mkcert.sh und sucht die Zeile

$OPENSSL req -new -x509 -nodes -config $OPENSSLCONFIG -out $CERTFILE -keyout $KEYFILE -days 365 || exit 2

Gebt hinter dem Parameter -days die gewünschte Anzahl von Tagen an.

In der Datei /usr/share/dovecot/dovecot-openssl.cnf könnt Ihr noch individuelle Angaben für das Zertifikat hinterlegen. In folgenden Abschnitt:

[ req_distinguished_name ]
organizationName = Mein Server
organizationalUnitName = Mein Server
commonName = Meine Domäne
emailAddress = Meine E-Mail Adresse

Wenn Ihr hier Äanderungen vornehmt, dann erstellt das Zertifikat erneut mit einem

cd /usr/share/dovcot
./mkcert.sh

Wir editieren noch drei Dovecot Konfigurationsdateien:

nano /etc/dovecot/conf.d/10-mail.conf

Hier muss das Standardverzeichnis /var/mail für die reinkommenden E-Mails von /var/mail auf das Homeverzeichnis umgestellt werden. Ändert deswegen die Mail Location wie folgt ab:


mail_location = maildir:~/mail

nano /etc/dovecot/conf.d/10-auth.conf

Sollte man Plaintext Auth verhindern wollen:


#disable_plaintext_auth = yes

in

disable_plaintext_auth = yes

nano /etc/dovecot/conf.d/10-ssl.conf


#ssl = yes

in

ssl = yes

Zudem die Zeilen auskommentieren:

#ssl_cert = </etc/dovecot/dovecot.pem
#ssl_key = </etc/dovecot/private/dovecot.pem

in

ssl_cert = </etc/dovecot/dovecot.pem
ssl_key = </etc/dovecot/private/dovecot.pem

Das war es dann auch schon. Speichert die Änderung und startet Euren Imap Server neu.

/etc/init.d/dovecot restart

An der stelle könnt Ihr Euch schon an den IMAP Server mittels Euren Mail Clienten wie den Thunderbird einloggen. Alternativ installieren wir jetzt noch den Webmailer Squirrelmail:

Squirrelmail Webmailer

Auf einem Debian Webserver (Apache2, php, MySQL) ist Squirrelmail recht schnell installiert.

Zunächst installieren wir Squirrelmail an der Konsole:

apt-get install squirrelmail

Solltet Ihr noch das Shared Kalender Plugin verwenden wollen, müssen noch zwei zusätzliche Pakete installiert werden:

apt-get install php-db php-pear

Squirrel verteilt sich entsprechend im Dateisystem. Die Files selbst liegen im Verzeichnis /usr/share/squirrelmail . Damit der Apache diese auch findet, richten wir einfach einen virtuellen Host ein. Editiert dazu die /etc/apache2/sites-enabled/000-default und fügt unter dem ersten Alias Abschnitt folgenden Abschnitt mit ein (bitte INNERHALB des virtual host Abschnitts!!!):

    Alias /squirrelmail /usr/share/squirrelmail
      <Directory /usr/share/squirrelmail>
       Options Indexes
       AllowOverride All
       DirectoryIndex index.php
       Order allow,deny
       allow from all
    </Directory>

Damit wird wenn Ihr an Eure URL /squirrelmail mit anfügt der Webmailer aufgerufen, da er über die Alias dann in das Verzeichnis /usr/share/squirrelmail geroutet werdet.

Konfiguriert nun Euren Webmailer mit

squirrelmail-configure

Ihr seht nun das Hauptmenü:

SquirrelMail Configuration : Read: config_default.php (1.4.0)
---------------------------------------------------------
Main Menu --
1.  Organization Preferences
2.  Server Settings
3.  Folder Defaults
4.  General Options
5.  Themes
6.  Address Books
7.  Message of the Day (MOTD)
8.  Plugins
9.  Database
10. Languages

D.  Set pre-defined settings for specific IMAP servers

C   Turn color on
S   Save data
Q   Quit

Command >>

Wählt hier D aus. Danach seht Ihr folgendes Menü:

Please select your IMAP server:
    bincimap    = Binc IMAP server
    courier     = Courier IMAP server
    cyrus       = Cyrus IMAP server
    dovecot     = Dovecot Secure IMAP server
    exchange    = Microsoft Exchange IMAP server
    hmailserver = hMailServer
    macosx      = Mac OS X Mailserver
    mercury32   = Mercury/32
    uw          = University of Washington's IMAP server

    quit        = Do not change anything
Command >>

Wir nehmen hier natürlich den dovecot.

Danach müssen die Serversettings eingestellt werden (Im Hauptmenü Punkt 2):

Server Settings

General
-------
1.  Domain                 : example.com
2.  Invert Time            : false
3.  Sendmail or SMTP       : SMTP

A.  Update IMAP Settings   : localhost:143 (dovecot)
B.  Update SMTP Settings   : localhost:25

R   Return to Main Menu
C   Turn color on
S   Save data
Q   Quit

Command >>

Stellt hier unter 1.) Euren Domain Namen ein. Dann geht in den Unterpunkt A.):

IMAP Settings
--------------
4.  IMAP Server            : localhost
5.  IMAP Port              : 143
6.  Authentication type    : login
7.  Secure IMAP (TLS)      : false
8.  Server software        : dovecot
9.  Delimiter              : detect

B.  Update SMTP Settings   : localhost:25
H.  Hide IMAP Server Settings

R   Return to Main Menu
C   Turn color on
S   Save data
Q   Quit

Command >>

Hier müssen die Settings entsprechend angepasst werden. Euer domain Name wo der Imap zu finden ist (localhost normalerweise). Zudem den Port auf 993 für SSL umstellen und Secure Imap auf True umstellen.

Im Unterpunkt 10 des Hauptmenüs könnt Ihr noch das en_US

Language preferences
1.  Default Language       : en_US
2.  Default Charset        : iso-8859-1
3.  Enable lossy encoding  : false

R   Return to Main Menu
C   Turn color on
S   Save data
Q   Quit

Command >>

... in de_DE umstellen. Speichert die Änderungen mit S ab und beendet das Konfigurationsprogramm mit Q .

Falls auf Lenny der Squirrel nicht auf Deutsch geht, obwohl Ihr das de_DE eingestellt habt, dann fehlt Euch noch "de_DE iso-8859-1" in den locales, da bei einer deutschen Installation standardmäßig nur de_DE UTF-8 ausgewählt wurde. Also führt

dpkg-reconfigure locales

aus und fügt bei den Sprachen de_DE iso 8859-1 mit hinzu. Den Rest lasst ihr einfach wie voreingestellt.

Danach startet den Apachen neu:

/etc/init.d/apache2 restart

Ruft nun Euren Webmailer über

http://EURE_URL/squirrelmail

auf.

Jetzt wollen wir nur noch eine Verbindung über https zulassen. Dazu müssen wir dem Apache https als Erweiterung beibringen. Wechselt dazu in Euer Root Home:

cd /root

Danach legen wir unser Serverzertifikat an:

openssl genrsa -out server.key 4096
openssl req -new -key server.key -out server.csr

Jetzt werdet Ihr einige Angaben abgefragt:

Country Name (Ländercode): = DE
State or Province Name (Bundesland): = zB Bayern
Locality Name, eg. City (Stadt): = zB Nuernberg
Organization Name (Firmenname): = hier irgendwas eingeben wie privat, zuhause etc.
Organizational Unit Name (Abteilung) = bleibt leer
Common Name, eg. YOUR Name: = Euer Servername
Email Adress: = eine E-Mail Adresse
A challenge password: = bleibt leer
An optional company name: = bleibt leer

Jetzt generieren wir das Zertifikat. Ich mache das gleich mal für 10 Jahre, dann ist Ruhe:

openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

Noch ein paar Rechte festlegen:

chmod 400 server.key

Jetzt müssen wir noch ein paar Änderungen in einigen Apache Konfigurationsdateien vornehmen:

nano /etc/apache2/sites-enabled/000-default

Am Ende der Konfigurationsdatei ergänzt folgende neue Sektion:

<VirtualHost *:443>
     DocumentRoot /var/www
     ServerName EUER_SERVERNAME
     SSLEngine on
     SSLCertificateFile /root/server.crt
     SSLCertificateKeyFile /root/server.key

   Alias /squirrelmail /usr/share/squirrelmail
      <Directory /usr/share/squirrelmail>
       Options Indexes
       AllowOverride All
       DirectoryIndex index.php
       Order allow,deny
       allow from all
    </Directory>

</VirtualHost>

EUER_SERVERNAME muss noch entsprechend eingetragen werden. Speichert die Änderung und editiert die ports.conf

nano /etc/apache2/ports.conf

und fügt ganz zum Schluss folgende Zeile ein:

NameVirtualHost *:443

Nun aktivieren wir das SSL Modul:

a2enmod ssl

Der Apache muss jetzt neu gestartet werden:

/etc/init.d/apache2 restart

Beachtet, dass das natürlich kein gekauftes Zertifikat ist. Euer Browser wird hier eine entsprechende Warnmeldung bringen. Aber Ihr wisst damit, warum diese Meldung kommt.

Wenn Ihr generell auf https umleiten wollt, auch wenn die Adresse über http abgerufen wird, müsst Ihr im Apache das Modul Rewrite aktivieren:

a2enmod rewrite
/etc/init.d/apache2 restart

Legt dann eine .htaccess Datei in /usr/share/squirrelmail an:

nano /usr/share/squirrelmail/.htaccess

Füllt diese mit folgenden Zeilen:

Options +FollowSymlinks
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Nun werden sämtliche Anfragen auf das verschlüsselte https Protokoll umgeleitet.

Zu guter Letzt wollen wir generell verhindern, dass man von außen einfach einen Zugriff auf das Login des Squirrelmail bekommt. Wir blockieren das deshalb mit .htaccess und aktivieren eine darüberliegende Passwortabfrage.

Fügt deshalb in der .htaccess noch folgendes ein:

AuthType Basic
AuthName squirrelmail
AuthUserFile /usr/share/squirrelmail/.htpasswd
require valid-user

Ihr seht, dass der Pfad zu dem dann erzeugtem Passwort im Dokumentenroot der Webanwendung liegt. Um das einwenig sicher zu machen, könnt Ihr durchaus dieses in ein anderes Verzeichnis legen, das außerhalb des Dokumentenroot liegt.

Das Passwort legt Ihr dann in diesem Verzeichnis (mittels cd dorthin wechseln!) mit einem

htpasswd -c .htpasswd username

an. Beim Befehl den Usernamen entsprechend Euren Vorstellungen ändern! Jetzt werdet Ihr zusätzlich nach einem Passwort gefragt.

E-Mails via Exim4 verschicken

Jetzt wollen wir noch E-Mails über den Server versenden können. Da wir keinen eigenen smtp Server einrichten wollen nehmen wir einfach den unseres Providers als smarthost (Ihr solltet Euch vergewissern, dass Euer Provider da nichts dagegen hat, allerdings merkt er nicht, ob ein Homeserver oder ein normaler Mail Client versendet. Solltet Euer Rechner als Spamschleuder missbraucht werden wird früher oder später Euer Provider auf den Plan treten ;-)

Installiert den Exim4 mit einem

apt-get install exim4

Um einen Smarthost einzurichten startet die Konfiguration mit einem

dpkg-reconfigure exim4-config

Folgende Konfigurationsschritte:
1.) Versand über Sendezentrale (Smarthost); Empfang mit SMTP oder Fetchmail

2.) Email Name des Systems: Lasst einfach den voreingestellten Domänen Name stehen

3.) IP-Adressen, dan denen eingehende SMTP-Verbindungen erwartet werden: 127.0.0.1

4.) Weitere Ziele, für die die E-Mails angenommen werden sollen: Auch hier den default Domän Namen stehen lassen

5.) Rechner für die die E-Mails weitergeleitet werden sollen (Relay): Leer lassen, wenn nicht ein weiterer Rechner DIESEN Rechner als Smarthost verwendet. Also normal leer lassen.

6.) IP Adresse oder Rechnername der Sendezentrale für ausgehende E-Mails: Hier und genau hier kommt die IP Adresse oder der Rechnername (mail/smtp.xyz) Eures ISP rein!

7.) Lokalen E-Mail Namen in ausgehende Mails verbergen: Ja

8.) DNS Anfrage minimieren: Ja

9.) Versandart bei lokaler Mailzustellung: Mbox Format in /var/mail/

10.) Einstellungen auf kleine Dateien aufteilen: Nein

11.) Empfänger an die Benutzer "root" und "postmaster": leer lassen

Danach startet der MTA neu. Jetzt kann es auch sein, dass Euer Smarthost eine Authentifizierung abverlangt. Diese hinterlegt in der folgenden Datei: /etc/exim4/passwd.client

Hier das Passwort wie folgt hinterlegen:

IP_des_Mailserver_oder_Name:LOGIN:PASSWORT

Die Datei sollte nur lesbar für root sein.

Startet danach den MTA neu:

/etc/init.d/exim4 restart

Solltet Ihr eine Fehlermeldung exim paniclog /var/log/exim4/paniclog has non-zero size erhalten, dann greift Exim4 auf IPv6 zu, ohne dass IPv6 zur Verfügung steht. Entfernt zunächst die paniclog:

rm /var/log/exim4/paniclog

Lasst nochmal die Konfiguration durchlaufen:

dpkg-reconfigure exim4-config

Beim Punkt 3 IP-Adressen, dan denen eingehende SMTP-Verbindungen erwartet werden entfernt hinten das ; ::1 . Übernehmt den Rest und startet exim4 wieder neu:

/etc/init.d/exim4 restart

Jetzt könnt Ihr auch Mails verschicken.

Viren mit ClamAV herausfiltern

Viren haben nichts auf unseren Servern und schon gar nichts in unseren Mailboxen zu suchen. Deswegen installieren wir einen Mailscanner, der damit beauftragt wird, die einströmenden Mails auf Viren zu prüfen. Viren können als normale Datei anhängen oder als gepackte Versionen. Deswegen muss unser Server auch in der Lage sein, gepackte Dateien zu prüfen. Wir benötigen dazu einen ganzen Bündel an neuen Files. Dazu müssen wir erstmal unsere sources.list erweitern:

nano /etc/apt/sources.list

Bei unseren Standard Repositories setzen wir dann noch die Source Reopsitiries dazu:

deb http://ftp.de.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.de.debian.org/debian/ wheezy main contrib non-free

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

Wir frischen nun die Repositories auf:

apt-get update

Jetzt müssen wir uns insgesamt 3 Pakete bauen:

unrar-nonfree
lha
libclamunrar6

Falls noch nicht geschehen müssen noch die build-essentials installiert werden:

apt-get install build-essential

Danach legen wir uns ein Arbeitsverzeichnis an und wechslen dorthin:

mkdir work
cd work

Wir beginnen mit unrar:

mkdir unrar-nonfree
cd unrar-nonfree
apt-get build-dep unrar-nonfree
apt-get source -b unrar-nonfree

Das fertiggestellte Paket seht Ihr als *.deb Paket mit einem ls -la. Installiert das Paket entsprechend seiner Versionsnummer (ggf. anpassen):

dpkg -i unrar_4.1.4-1.deb
cd ..

Danach das Paket lha:

mkdir lha
cd lha
apt-get build-dep lha
apt-get source -b lha

Das fertiggestellte Paket seht Ihr als *.deb Paket mit einem ls -la. Installiert das Paket entsprechend seiner Versionsnummer (ggf. anpassen):

dpkg -i lha_.1.14i-10.deb
cd ..

Wir bleiben im work Verzeichnis und installieren die folgenden Pakete:

apt-get install clamav clamav-base clamav-daemon clamav-freshclam unzip

Fehlermeldungen wegen einer nicht aktuellen Virendatenbank ignorieren wir zunächst.
Danach bauen wir uns noch den libclamunrar6:

mkdir libclamunrar6
cd libclamunrar6
apt-get build-dep libclamunrar6
apt-get source -b libclamunrar6

Das fertiggestellte Paket seht Ihr als *.deb Paket mit einem ls -la. Installiert das Paket entsprechend seiner Versionsnummer (ggf. anpassen):

dpkg -i libclamunrar6_0.98.5.deb

Jetzt aktualisieren wir den ClamAV:

freshclam

Und nun starten wir den ClamAV durch:

/etc/init.d/clamav-daemon start



Variante A) getmail

Fügt nun in jeder getmail Konfig Eures getmail Users noch folgenden Abschnitt mit ein:

[filter-virus]
type = Filter_classifier
path = /usr/bin/clamdscan
arguments = ("--stdout", "--no-summary", "-")
exitcodes_drop = (1, )

Das filtert nun nach dem ClamAV erkannte Virenmails heraus. Viren die in gepackten Dateien enthalten sind werden auch nach aktuellen Stand der Datenbank aussortiert.

Wenn Ihr wollt könnt Ihr Euch von heise Security aus Testviren (harmlos!) zusenden lassen. Diese könnt Ihr unter folgender URL anfordern: http://www.heise.de/security/dienste...e=virendummies Lasst Euch hier eine normale Testmail und eine mit einem zip Paket zuschicken. Wenn alles klappt wird die Testmail Eure Mailbox nie erreichen, da diese kommentarlos gedropped (gelöscht) wird. Ob dies tatsächlich der Fall ist seht Ihr entweder in der .getmail/xyz.log , dort wird ausgegeben, welche Mail mit welchen Absender gedropped wurde. Ebenso seht Ihr unter /var/log/clamav/clamav.log, ob Viren gefunden wurden.

Variante B) procmail

Eine meiner Meinung nach etwas schönere Lösung gibt es über den Procmail mittels clamassassin. Das Script kann in den procmail integriert werden, markiert den Titel einer infizierten Mail mit einer entsprechenden Warnung und schiebt dies dann in einen eigenen Ordner. Auf diesem Weg werden keine Falschmeldungen einfach gelöscht und man hat die Mail nochmal vor Augen. Der User sollte diese dann tunlichst löschen, wenn er diese vielleicht noch mit einem Scanner auf seinem Rechner geprüft hat.

Als erstes installieren wir den clamassassin aus den Repositories:

apt-get install clamassassin

Dieser arbeitet out of the box allerdings anscheinend nur mit dem clamscan und nicht über den deutlich schnelleren Weg des clamdscan Deamons. Von daher müssen wir den clamassassin aus den Quellen nochmal neu kompilieren. Hierzu bitte die build-essentials installieren und ein Arbeitsverzeichnis erstellen, in das wir dann gleich wechseln:

cd /
mkdir work
apt-get install build-essential
cd /work

Jetzt laden wir uns die Quellen herunter

apt-get source clamassassin

und wechseln in das Hauptverzeichnis des Quellcodes:

cd clamassassin-1.2.4

Jetzt muss der Übersetzungsvorgang vorbereitet werden. Hierzu folgendes eingeben

./configure --bindir=/usr/bin --enable-clamdscan --enable-subject-rewrite=***INFECTED***

Damit haben wir Folgendes geregelt:

-Die übersetzte Datei wird nach /usr/bin installiert
-clamassassin wird clamdscan verwenden, wenn dieser läuft
-Die Mailüberschrift wird mit ***INFECTED*** markiert

Jetzt installieren wir das Script:

make install

Das sollte ohne Fehler durchlaufen.

In der ~/.procmailrc schreiben wir dann als erste Regeln (das muss ja auf alle eingehenden Mails angewandt werden) folgende:

0 fw
| /usr/bin/clamassassin

:0:
* ^X-Virus-Status: Yes
.virus/

Danach werden alle Mails, in denen ein Virus entdeckt wurde, in den Ordner virus in Eurer Mailbox erschoben. Prüft nach, ob der Clamassassin auch tatsächlich filtert, indem Ihr Euch eine Testmail schickt. Im Header dieser Mail solltet Ihr dann folgende Zeile relativ weit unten finden:
X-Virus-Checker-Version: clamassassin 1.2.4 with clamdscan...

virentest
Eine entdeckte Virentestmail

Spam tilgen mit Spamassassin

Jetzt widmen wir uns der schlimmsten Mailplage im Netz, dem Spam. Auch hier gibt es einige Möglichkeiten, gegen Spam anzutreten. Unter Linux hat sich derweilen als Filter das Programm Spammassassin etabliert. Wir wollen nun unseren Mailserver so konfigurieren, dass er eingehende Mails auf Spam untersucht und sollte er der Meinung sein, dass es sich um Spam handelt, dieser die Mails als Spam markiert und in einen eigenen Ordner Junk verschiebt. Der User hat dann die Möglichkeit, den Ordner weiterhin auf "Falsepositives" zu untersuchen und löscht einfach den Rest raus. Hier sind zumindest die Mails vorsortiert und man geht dabei nicht das Risiko ein, dass vielleicht irgendwo noch erwünschte Mails einen generellen Löschvorgang zum Opfer fallen.

Zuerst installieren wir den Spamassassin:

apt-get install spamassassin

Dies liefert uns noch wietere zahlreiche Pakete hauptsächlich aus dem Bereich "perl". Wenn die Pakete installiert sind, dann bauen wir erstmal eine einfache Grundkonfiguration auf, die natürlich noch durch viele weitere ausgeklügelte Filtermaßnahmen erweitert werden können. Wir editieren zuerst einmal die Datei

nano /etc/spamassassin/local.cf

Hier bitte bei folgende Zeilen das "#" entfernen um diese zu aktivieren:

rewrite_header Subject *****SPAM*****

required_score 5.0

use_bayes 1

bayes_auto_learn 1

bayes_ignore_header X-Bogosity
bayes_ignore_header X-Spam-Flag
bayes_ignore_header X-Spam-Status

Unter die drei bayes_ignore Zeilen schreibt dann bitte noch folgende Zeilen:

bayes_ignore_header X-getmail-filter-classifier

Das verhindert, dass Headererweiterungen des Getmail irgendwann als Spam ausgewertet und gekennzeichnet werden.

Jetzt editiert bitte die Datei /etc/default/spamassassin

Dort stellt den Eintrag

ENABLED=0

auf

ENABLED=1

Dies stellt sicher, dass der Filter beim Booten des Servers automatisch gestartet wird. Ob der Spamassassin aktiv ist, könnt Ihr im Mailheader erkennen. Ist dies nicht der Fall, bzw. startet Spamd nicht automatisch, dann könnt Ihr das mit folgenden Befehl erledigen:

systemctl enable spamassassin.service

Da dieser eben nach der Installation nicht angefahren wird können wir den Spamfilter auch manuell scharf machen ohne erst dafür unseren Server neu zu starten:

/etc/init.d/spamassassin start

Damit das alles über den Getmail läuft, geht dann noch in Eure jeweilige Getmail Konfiguration unter .getmail und fügt zum Schluss der Konfigurationsdatei folgende Filterregel ein:

[filter]
type = Filter_external
path = /usr/bin/spamc

Über Procmail lassen wir nun noch nach der Headererweiterung *****SPAM***** suchen. Dazu fügen wir folgende Regel (am besten als erste Regel unterhalb der Virenregeln) in der ~/.procmailrc ein:

:0
* ^Subject:.******SPAM*****
.Junk/

Das sollte nun alle vom Spamassassin mit SPAM gekennzeichnete Mails in den Junk - Ordner schieben.

Hinweis: Da der Procmail als Platzhalter ein Sternchen * verwendet, ist es auch ratsam, die Subject Markierung auf ein anderes Symbol zu setzen, beispielsweise +++++SPAM+++++ . Ändert dies dann in der /etc/spamassassin/local.cf ab und in der .procmailrc. Danach natürlich den Spamassassin neu starten:

/etc/init.d/spamassassin restart

Woran sehe ich nun, ob der Spamfilter läuft? Hierzu schickt Euch einfach mal eine Testmail. Als Betreff dann gleich die entsprechende Änderung, die eben der Spamassassin einfügen würdee, wenn Spam erkannt werden würde (also beispielsweise +++++SPAM+++++). Das zeigt uns dann erstmal, ob der Procmail dann auch sauber filtern würde und die Mail in unseren Junk Ordner verschiebt. Wenn Ihr Eure Mail dann im Junk Ordner liegen habt, dann seht Euch den Quelltext an. Im Header der Mail solltet Ihr dann in etwa Folgendes lesen können:

X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on myserver
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,SPF_FAIL autolearn=no
	version=3.2.5

Hier seht Ihr, dass der Spamassassin aktiv war und seinen Score ( 1.5 ) eingetragen hat. Daneben steht der benötigte Score, damit die Mail als Spam markiert wird. Ihr könnt hier jetzt nur abwarten und zusehen, ob die Geschichte auf Dauer Euch in der Form genügt, oder Ihr noch ein paar "Goodies" einbauen wollt.

Spamassassin prüfen

Der Dienst sollte regelmäßig daraufhin geprüft werden, ob er noch am Laufen ist. Wenn ein Mailserver rund um die Uhr aktiv ist, wäre es schlecht, wenn der Scanner im Hintergrund sich verabschieden sollte. Dazu bauen wir uns unter /usr/local/bin ein eigenes Script, das den Dienst spamd prüft, zur Not neu startet und dann eine E-Mail verschickt. Das Script sieht dann so aus:

nano /usr/local/bin/spamdcheck

Füllt den Inhalt wie folgt:

#!/bin/bash

#Spamd checkup for being running
#Skript by Gargi 2015

top -b -n 1 | grep /usr/sbin/spamd
spamd=$?
if [ $spamd = 1 ]; then
  service spamassassin restart
  echo "Spamd restarted cause it was not found active!" > /var/log/spamdcheck.log
  echo "" >> /var/log/spamdcheck.log
  /etc/init.d/spamassassin status >> /var/log/spamdcheck.log
  mail -s "[System] Spamd recovered"  EURE @ MAILADRESSE < /var/log/spamdcheck.log
  exit 1
else
  echo "Spamd alive, nothing to be done"
fi

Speichert die Änderung und macht das Skript ausführbar:

chmod +x /usr/local/bin/spamdcheck

Dies lasst Ihr über den cron alle 5 Minuten beispielsweise laufen:

crontab -e
# Spamdcheck every 5 minutes
*/5  * * * *  /usr/local/bin/spamdcheck > /dev/null



Spamassassin regelmäßig aktualisieren

Um den Spamassassin regelmäßig zu aktualisieren richten wir uns ein kleines Skript ein:

nano /usr/local/bin/sa-updater

Dies füllt mit folgenden Inhalt:

#!/bin/bash

/usr/bin/sa-update
date > /var/log/sa-update.log
echo "updated spamassassin" >> /var/log/sa-update.log

Danach macht das Skript ausführbar:

chmod +x /usr/local/bin/sa-updater

Dies lasst Ihr über den cron ein mal am Tag beispielsweise laufen:

crontab -e
# Spamassassin Update 2 o clock in the morning
1  2  * * *  /usr/local/bin/sa-updater > /dev/null



Scripterweiterungen

An der Stelle werde ich noch ein paar Konfigurationserweiterungen für Spamassassin, procmail und getmail bringen.

a) Razor und Pyzor anwenden
Eine Erweiterung für den Spamassassin stellt razor und pyzor dar. Via einer Checksumme werden Mails dann mit einer Datenbank verglichen. Wurde eine Spammail von mehreren Usern gemeldet, dann wird eine empfangene Spammail als solche auf Basis dieser Meldungen auf dem lokalen Server von Spamassassin erkannt.
Stellt zunächst einmal fest, dass die UDP Ports 24441 (in + out für pyzor) und TCP Port 2703 (out für razor) offen sind und passt gegebenfalls Eure Firewall an.

Jetzt installiert die beiden Pakete;

apt-get install razor pyzor

Die Spamassassin Konfiguration wird automatisch angepasst. Führt nun noch folgende Befehle aus, um den razor zu aktivieren:

razor-admin -d -home=/etc/razor -create
razor-admin -d -home=/etc/razor -register

Testet noch, ob pyzor nach außen funken kann:

pyzor ping
echo "test" | spamassassin -D pyzor 2>&1 | less

Ein public.pyzor.org:24441 (200, 'OK') deutet darauf hin, dass die Kommunikation funktioniert. Ändert dann die /etc/spamassassin/local.cf und fügt unter den Bayes Bereich noch folgendes mit ein:

use_pyzor 1
pyzor_path /usr/bin/pyzor

use_razor2 1
razor_config /etc/razor/razor-agent.conf

Startet Euren Spamassassin neu:

/etc/init.d/spamassassin restart

Schaut Euch dann die gefilterten Spam Mails an. Wenn alles klappt, dann findet Ihr Pyzor und Razor Punkte entsprechend gelistet.
z.B. Razor:

 2.4 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
                            above 50%
                            [cf: 100]
 0.4 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
                            [cf: 100]
 1.7 RAZOR2_CHECK           Listed in Razor2 (http://razor.sf.net/)

z.B. Pyzor:

2.0 PYZOR_CHECK            Listed in Pyzor (http://pyzor.sf.net/)



b) Mails mit speziellen Anhängen filtern
Manche Anhänge einer Mail sind potentielle Risiken. Hier kann man um die Aufmerksamkeit einwenig zu heben solche Mails gleich von Haus aus in einen speziellen Ordner (Bsp.: dangerous) schieben. Der User sieht dann gleich, dass man hier besondere Vorsicht walten lassen sollte im Umgang mit einer derartigen Mail. Der Code für die .procmailrc würde so aussehen:

:0 B:
* name=.*\.(vbs\"|wsf\"|exe\"|vbe\"|src\"|rar\"|dll\*)
.dangerous/

Dies könnt Ihr mit entsprechenden Erweiterungen noch versehen. Die Regel setzt am besten recht weit nach oben unter die Spamregel.

Gargi's Schlusswort

Das soll uns nun für einen Mailserver genügen, der sowohl von außen als auch vom internen Netz zu erreichen ist. Dass man hier noch einiges an Finetuning betreiben kann ist klar. Aber ein Gerüst für ein funktionierenden Mailverteiler ist das allemal und sollte im Homebereich und für kleine Büros sicher genügen. Einen echten SMTP aufzubauen wäre der nächste Schritt. Nur wird man sich nach wie vor schwer tun, einen Server ohne full qualified Domäne im Netz ernsthaft als Mailserver zu betreiben, da die Mails schneller auf den Spamlisten landen als Ihr Spam aussprechen könnt. Aber das ist auch nicht nötig, denn für den Hausgebrauch reicht das dicke!

Viel Spaß!
Euer
Gargi


Quellen
Dovecot
Getmail
Procmail
Spamassassin
Pyzor
ClamAV
ClamAssassin
Squirrelmail
Debian

Literatur
Spam & Viren bekämpfen
Debian Server
Postfix
Linux Server Hacks
100 neue Linux Server Hacks