Wollmilchsau Server: 4. Mailserver

4.1. MTA - Der Posteingang des Mailservers

Der Mail Transfer Agent (MTA) befasst sich -Nomen est omen- mit dem Hin- und Herübertragen von Mails. Der MTA ist vergleichbar mit der Zulieferer-Einfahrt eines Postamtes. Jede eingehende Mail muss durch dieses Tor. Es spielt keine Rolle, ob die Mail direkt aus dem Internet stammt, per fetchmail vom Provider abgeholt wurde oder ob ein lokaler User sie abgeschickt hat. Der MTA hat unter anderem die Aufgabe, anhand der Adressen, über die Weiterleitung zu entscheiden. Darüber hinaus muss er gegebenenfalls Adressen umsetzen können, da ein lokaler User "john" möglicherweise im Internet unter der Mailadresse "mustermann@gmx.net" zu erreichen ist. Schlussendlich muss der MTA auch Mails an den Provider verschicken können, wenn er anhand der Adresse einen nicht lokalen Adressaten erkennt. Dazu muss der MTA z.B. lokale und entfernte Mailadressen unterscheiden können, muss die Usernamen kennen und anderes mehr.

Der Standard-MTA unter Unix/Linux, der auch bei SuSE standardmäßig installiert wird, ist sendmail. Dieses Programm dürfte wohl der weitverbreitetste Mailer im Internet sein. Das bedeutet keineswegs, dass er ohne Nachteile ist. Die Konfigurationsdatei gehört zu den abschreckendsten Dateien unter Unix; sie ist wirklich sehenswert. Sie hat zu der Äußerung geführt: "Wer Sendmail nie konfiguriert hat, ist kein Unix-Admin. Wer es zweimal konfiguriert hat, ist bescheuert". Aber auch die Struktur als monolithischer Software-"Klotz" ist eigentlich nicht mehr ganz zeitgemäß und führt zu vergleichsweise hohem Ressourcenbedarf und gelegentlichen Sicherheitsproblemen.

Aus diesen Gründen wurde als MTA für den Testserver Postfix von Wietse Venema ausgewählt. Postfix ist stark modularisiert und kann sehr einfach in eine chroot-Umgebung gestellt werden. Die Module sind gut voneinander isoliert, ein "Durchgriff" durch den MTA durch einen Hacker ist nahezu ausgeschlossen. Dies macht ihn auch als Mailproxy auf einer Firewall geeignet. Eine genaue Anatomie von Postfix findet sich auf der Homepage www.postfix.org. Das dort vorhandene Manual ist so detailiert und ausführlich, dass ich hier darauf verweisen möchte.

4.2. MDA - Der interne Postverteiler

Die Eingangstür hatten wir schon, jetzt kommt - um beim Vergleich zu bleiben - der Schalter, an dem ich meine lagernden Briefe abholen kann. Dieser Postverteiler wird als MDA oder Mail Delivery Agent bezeichnet. Wo der MTA lokale Zieladressaten erkennt, gibt er die Mails intern weiter. Diese Weitergabe kann man beim Postfix flexibelst konfigurieren: Er kann direkt in ein Homeverzeichnis eines Users ablegen, meist in das Verzeichnis /~/mail.
Er kann hierzu ein weiteres Programm verwenden, hier wird unter Linux in der Regel procmail herangezogen, das auch einige Möglichkeiten zur Weiterleitung und Filterung besitzt. Man kann aber auch einen regelrechten Server für diese Zwecke einsetzen. Dafür sind etliche Programme erhältlich, z.B. UW-IMAP, qpopper und Cyrus. Der Cyrus unterliegt einer proprietären Lizenz, ist aber kostenfrei. Sein Funktionsumfang ist allerdings beeindruckend. Cyrus hat zwei Besonderheiten, die zu seiner Auswahl geführt haben: Cyrus speichert Mails in einer Datenbank, nicht in Userverzeichnissen. Dies ist aus Datenschutzgründen sinnvoll, da ein Zugriff auf die Datenbank deutlich schwieriger ist, als der Blick in die Dateien eines Verzeichnisses. Zum anderen ist es bei Cyrus möglich, LDAP, eine MySQL-Datenbank, eine Cyrus-eigene Userdatenbank (sasldb) oder ein PAM-Modul als Authentifizierungs-Mechanismus zu verwenden.

Der Vorteil: Der Mailuser muss nicht unbedingt ein User-Account auf dem Mailserver haben. Kein Account bedeutet kein Zugriff zum Mailserver als User, damit auch eine höhere Sicherheit für den Mailserver.

(Für das Testsystem wurde hiervon kein Gebrauch gemacht. Eine Umstellung dürfte, insbesondere durch die Verwendung von PAM, jedoch überhaupt kein Problem sein.) Ein weiteres, wenig beachtetes Feature: Sieve. Sieve ist eine Programmiersprache zur Filterung von Mails, um automatisches Einordnen von Mails in Ordner zu ermöglichen, Spam abzuwehren usw.

4.3. Glossar der Protokolle

Mit Mail tauchen immer wieder einige Protokolle auf, deshalb ein kurzes Glossar zu den Kürzeln:

SMTP	Simple Mail Transfer Protocol. Hiermit übermitteln Clients Mails an den MTA, dieser übermittelt per SMTP an den Internetprovider. Ein besonderes Problem: SMTP ist recht alt und kennt ursprünglich keine Benutzerbegrenzungen, Kennworte oder Authentifizierungen.
LMTP	Local Mail Transfer Protocol. Dieses werden Sie nur selten sehen. Postfix schickt seine internen Mails per LMTP an Cyrus (wenn man ihn so konfiguriert...)
POP3	Post Office Protocol Version 3. Clients holen hiermit Mail vom Server. Auch schon etwas älter, daher relativ unkomfortabel: Es gibt keine Mailordner, nur ein Postfach. Mails werden beim Abholen auf den Client geladen und dort gespeichert. Einzige weitere Funktion: Beim Herunterladen kann man die ursprüngliche Mail löschen oder stehenlassen.
IMAP	Ein Mail Access Protocol. Heute meist in der Version 4. IMAP ist eine komfortablere Weiterentwicklung des POP3. Bei IMAP bleiben die Mails auf dem Server, was eine Bearbeitung von verschiedenen Clients aus erheblich vereinfacht. Hier wird serverseitig bereits die Ordnerarchitektur implementiert, es können eigene Ordner im Postfach angelegt werden. Ferner sind bei einigen IMAP-Servern auch "schwarze Bretter" möglich.
SIEVE	(wörtl. "Sieb") ist kein Mailprotokoll. Sieve ist eine einfache Programmiersprache zur Mailbearbeitung und Filterung und wurde mittlerweile zum RFC-Standard erhoben. Die Möglichkeiten sind nicht unbeträchtlich: Filtern von unerwünschten Mails, automatisches Einsortieren in IMAP-Ordner, Urlaubsmeldung ("Vacations") oder Abwesenheitsmeldung usw.

4.4. Postfix

Der MTA Postfix ist bereits bei der Grundinstallation statt sendmail installiert worden.

Sollten Sie statt dessen sendmail aufgesetzt haben, können Sie wie folgt verfahren:

Stoppen Sie sendmail mit

  >> rcsendmail stop
  

  >> rpm -e --nodeps sendmail
  

4.5. Postfix: Update

Wenn Sie das Original-Postfix von der Distribution installiert haben, sollten Sie das Update von der SuSE-Homepage installieren. Laden Sie die Datei vom SuSE-Server oder einem Mirror (geht meist schneller) und geben Sie ein:

>> rcpostfix stop	(Anhalten des laufenden postfix)
>> rpm -Uhv <pfad>/postfix.rpm	(Akutelles Paket einspielen)

Wenn Sie von sendmail wechseln, geben Sie rpm -i statt rpm -Uhv ein...

Starten Sie den Postfix noch nicht wieder, es werden ersteinmal einige Konfigurationen vorgenommen.

4.6. Postfix: Konfiguration: chroot-Umgebung und Vorkonfiguration

Postfix kann ohne Probleme in einem chroot-Jail betrieben werden. Das bedeutet, es wird ein eigener Dateibereich geschaffen, in dem ein beliebiges Verzeichnis als "Pseudo-root-Verzeichnis" benutzt wird. Dieses Verzeichnis sieht der Prozess als root, obwohl es eigentlich irgend ein Unterverzeichnis ist. Dies ist ein Sicherheitsmerkmal, da ein Zugriff auf Dateien ausserhalb der chroot-Umgebung schwierig ist (er ist nicht unbedingt unmöglich, aber es setzt schon mehr Hackerfähigkeiten voraus... ;-). Es wird mir immer ein Rätsel bleiben, warum SuSE in der Distribution die standardmäßige Installation in ein chroot-Jail aufgegeben hat.

Zur Ersteinrichtung von Postfix gehen Sie wie folgt vor:

• Starten Sie YaST
• Wählen Sie "Administration des Systems"
• Wählen Sie "Konfigurationsdatei verändern"
• Suchen (Taste [F4]) Sie nach POSTFIX (geht schneller als von Hand durchblättern)
• POSTFIX_CHROOT auf yes setzen
• POSTFIX_DIALUP auf yes setzen
• POSTFIX_MASQUERADE_DOMAIN auf die Domain Ihres Mailproviders, z.B. gmx.de
• POSTFIX_NODNS auf yes setzen
• POSTFIX_RELAYHOST auf den FQDN-Namen des Mailproviders, z.B. [mail.gmx.net]
  Die eckigen Klammern sind wichtig, nicht weglassen!

Verlassen Sie nun YaST. Ich habe bei einigen Tests Schwierigkeiten bekommen. YaST ruft einen etwas eingeschränkten Durchlauf von SuSEconfig auf, der möglicherweise einige Probleme nach sich zieht. Die Probleme konnten vermieden werden, indem nach dem Verlassen von YaST das SuSEconfig einmal manuell gestartet wurde.

Diese Vorgehensweise erstellt eine durchaus funktionstüchtige Installation für den lokalen Betrieb. Allerdings sind Änderungen von Hand an der Konfiguration nicht möglich; jeder Aufruf von SuSEconfig würde wieder die Ursprungskonfiguration herstellen.

Deshalb müssen Sie nun die automatische Konfiguration abschalten:

• Starten Sie erneut YaST
• Wählen Sie "Administration des Systems"
• Wählen Sie "Konfigurationsdatei verändern"
• Suchen (Taste [F4]) Sie nach POSTFIX
• POSTFIX_CREATECF auf no setzen
• Yast beenden

Das chroot hat allerdings einen Haken: Die postfix-Prozesse erkennen das neu angelegte Verzeichnis /var/spool/postfix als root! Sie können daher auf einige Dateien und Verzeichnisse nicht mehr zugreifen, die zur Funktion benötigt werden. Unter /var/spool/postfix findet sich z.B. ein Verzeichnis etc, in das diverse Dateien aus /etc kopiert wurden. Änderungen dieser Dateien in /etc müssen nach /var/spool/postfix/etc kopiert werden, sonst gibt es u.U. Ärger. Postfix warnt beim Starten, wenn die Dateien differieren.

Spätestens dann ist es höchste Zeit, die entsprechende Datei zu kopieren.

4.7. Postfix: /etc/aliases

In dieser Datei werden Alias-Namen für die User interner Systemprogramme u.a. verwaltet. Der Eintrag "postfix: root" sorgt z.B. dafür, dass Meldungen, die an den postfix-Systemuser gesendet werden, unmittelbar an root weitergeleitet werden. Bitte verwenden Sie diese Datei keinesfalls für Umleitung von Domainnamen oder externen Mailadressen, das funktioniert nicht korrekt.

In der /etc/aliases sollten Einträge vorhanden sein, die root und postmaster auf einen normalen User umleiten. Aus Sicherheitsgründen (Mailviren) werden Mails an Root nicht zugestellt. Sie landet per Default beim User nobody, oder bei dem in /etc/aliases angegebenen Aliasnamen. Es muss also ein Eintrag

  root:		john
  

  	postfix: 		root
  

4.8. Postfix: Konfiguration: /etc/postfix/master.cf

Die /etc/postfix/master.cf ist die Transportsteuerung von Postfix. Als Transfer Agent muss postfix die verschiedenen Transportmöglichkeiten und deren Parameter kennen, das wird hier eingestellt.

Beachten Sie bitte unbedingt, dass die Zeilen der folgenden Datei zu lang sind, so das hier Zeilenumbrüche nötig werden. Diese dürfen Sie nicht mit eingeben!

Der lange Vorspann-Text wurde weggelassen.

  
   # ==========================================================================
   # service type	private	unpriv	chroot	wakeup	maxproc	command + args
   # 		(yes)	(yes)	(yes)	(never)	(50)
   # ==========================================================================
   smtp		inet	n	-	y	-	-	smtpd
   localhost:10025 inet    n	-	y	-	-	smtpd -o content_filter=
   
   #smtps	        inet	n	-	y	-	-	smtpd -o \ 
                  smtpd_tls_wrappermode=yes  -o smtpd_sasl_auth_enable=yes
   
   #submission	inet	n	-	y	-	-	smtpd -o smtpd_enforce_tls=yes \ 
                  -o smtpd_sasl_auth_enable=yes
   
   pickup	        unix	n	n	y	60	1	pickup
   cleanup	unix	-	-	y	-	0	cleanup
   qmgr		unix	n	-	y	300	1	qmgr
   #qmgr		fifo	n	-	n	300	1	nqmgr
   tlsmgr	        fifo	-	-	n	300	1	tlsmgr
   rewrite	unix	-	-	y	-	-	trivial-rewrite
   bounce	        unix	-	-	y	-	0	bounce
   defer		unix	-	-	y	-	0	bounce
   flush		unix	-	-	n	1000?	0	flush
   smtp		unix	-	-	y	-	-	smtp
   showq		unix	n	-	y	-	-	showq
   error		unix	-	-	y	-	-	error
   local		unix	-	n	n	-	-	local
   lmtp		unix	-	-	y	-	-	lmtp
   # external programms and transports
   
   cyrus		unix	-	n	n	-	-	pipe flags=R user=cyrus \ 
                  argv=/cyrus/bin/deliver -e -m ${extension} ${user}
   
   uucp		unix	-	n	n	-	-	pipe flags=F user=uucp argv=uux \ 
                  -r -n -z -a$sender - $nexthop!rmail ($recipient)
   
   ifmail	        unix	-	n	n	-	-	pipe flags=F user=ftn \ 
                  argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
   
   bsmtp		unix	-	n	n	-	-	pipe flags=F. user=foo \ 
                  argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient
   
   vscan		unix	-	n	n	-	-	pipe user=vscan \ 
                  argv=/usr/sbin/amavis ${sender} ${recipient}
   
   procmail	unix	-	n	n	-	-	pipe flags=R user=cyrus \ 
                  argv=/usr/bin/procmail -t -m USER=${user} EXT=${extension} /etc/procmailrc
   
   # postfix to fax link. 
   #fax		unix	-	n	n	-	1	pipe flags= user=fax \ 
                                                           argv=/usr/bin/faxmail -d -n ${user}
  
  

Die ersten Zeilen konfigurieren die internen Dienste von Postfix. Die meisten der aufgerufenen Programme finden sich unter /usr/lib/postfix. Ein "y" in der 5. Spalte besagt, das dieser Prozess in der chroot-Umgebung läuft.

Die letzte Zeile werden Sie mit einiger Sicherheit manuell einfügen müssen. Sie dient später als Transport für das Mail2fax Gateway. Die Zeile "localhost:10025...." usw. müssen Sie entkommentieren, wenn Sie mit AmaViS als Virenscanner arbeiten möchten.

4.9. Postfix: Konfiguration: /etc/postfix/main.cf

Die main.cf konfiguriert das Laufzeitverhalten von Postfix, erledigt die Steuerung der Adressmaskierung, welche Domainnamen wo verwendet werden usw.
Das SuSEconfig hat leider den Nachteil, das es viele Parameter einfach auskommentiert und am Ende der Datei wieder mit eigenen Angaben anhängt. Dieses macht das Ganze nicht übersichtlicher. Wenn Sie eine auskommentierte Zeile stutzig macht, schauen Sie mal ans Ende der Datei. Ich habe im Folgenden nur die aktiven Parameter angegeben, wie sie bei mir konfiguriert sind. Inaktive Parameter wurden weggelassen. Lesen Sie bitte die Originaldatei, dort finden Sie noch etliche Hinweise für Ihre eigene Konfiguration. Die u.a. Kommentare sind von mir eingefügt.

   queue_directory = /var/spool/postfix
   command_directory = /usr/sbin
   daemon_directory = /usr/lib/postfix
   mail_owner = postfix
   default_privs = nobody
   # Bitte setzen Sie hier nie einen privilegierten User wie
   # postfix oder root ein!
   myhostname = server.domain.tld
   # FQDN Ihres Mailservers, z.B. mail.meinnetz.intra
   mynetworks = 192.168.100.0/24, 127.0.0.0/8
   # Adresse des eigenen Netzwerkes und des Localhost, verhindert Zugriff
   # anderer Mailer zum Mailversand.
   alias_maps = hash:/etc/aliases
   alias_database = hash:/etc/aliases
   # Parameter für die alias-Datenbank.
   mailbox_transport = lmtp:unix:public/lmtp
   # Hierüber wird - per LMTP - auf Cyrus zugegriffen,
   #mailbox_transport = cyrus
   # der Mailbox-Transport cyrus bleibt auskommentiert! Das ist so korrekt.
   debug_peer_level = 2
   debugger_command =
   	 PATH=/usr/bin:/usr/X11R6/bin
   	 xxgdb $daemon_directory/$process_name $process_id & sleep 5
   # Debugger-Steuerung
   content_filter = vscan:
   # Welcher Transport wird vom Content Filter benutzt?
   mail_spool_directory = /var/mail
   mail_name = Postfix Mein Mailserver
   # Hier können Sie Ihrem Server einen Namen geben, der in Meldungen etc 
   # auftaucht. 
   canonical_maps = hash:/etc/postfix/canonical
   virtual_maps = hash:/etc/postfix/virtual
   relocated_maps = hash:/etc/postfix/relocated
   sender_canonical_maps = hash:/etc/postfix/sender_canonical
   smtpd_sender_restrictions = hash:/etc/postfix/access
   transport_maps = hash:/etc/postfix/transport
   # Hier werden die Pfade für die diversen Tabels von Postfix angegeben.
   masquerade_exceptions = root
   # Der User root wird bei der Adressmaskierung übergangen (nicht maskiert)
   myorigin = server.domain.tld
   # lokal gepostete Mail kommt scheinbar von dieser Adresse.
   # FQDN Ihres Mailservers, z.B. mail.meinnetz.intra
   masquerade_domains = gmx.de
   # Provider-Domain, muss eingetragen werden, um die envelope-address 
   # korrigieren zu können.
   mydestination = $myhostname, localhost.$mydomain, wonko.intra
   # Hier angegebene Domains werden von Postfix als eingene Adressen erkannt.
   defer_transports = smtp
   # Dieser Transportweg soll nicht automatisch, sondern manuell getriggert 
   # werden (z.B. bei Verbindungsaufbau).
   disable_dns_lookups = yes
   # nicht sofort DNS-Auflösung durchführen.
   relayhost = [mail.gmx.net]
   # Da sitzt der Mailprovider. Eckige Klammern verhindern die sofortige DNS-
   # Auflösung.
  

Nochmal die Bitte: Lesen Sie die Kommentare in der Originaldatei! Es lohnt sich, ebenso ein Blick in das sehr lesenswerte Postfix-HowTo und FAQ von RedHat:
http://www.redhat.com/[...]RH-postfix-HOWTO/book1.html

4.10. Postfix: Konfiguration: /etc/postfix/access

Die Datei /etc/postfix/access regelt den Zugriff zum Postfix-Mailversand. Baut man hier keine Sperren ein, mutiert der Server zum offenen Mailrelay!
In der Praxis heisst das: Ein netter (?) Zeitgenosse schickt eine Werbemail und eine Liste mit Mailadressen unbemerkt auf Ihren Server, und schon verteilt Ihr Server einige zigtausend Werbemails. Damit macht man sich kaum beliebt, und es kostet ohne Flatrate auch noch heftigst Gebühren. Öffnen Sie die Datei /etc/postfix/access mit einem Editor. Löschen Sie die Kommentarzeilen und tragen Sie nur eine einzige Zeile ein:

  localhost	RELAY
  

  postmap access
  

Es ist dringendst empfohlen, sich mit den Einstellungen und Möglichkeiten von Postfix zu befassen, speziell zum Thema Spam-Blocking. Die Config-Files sind gut dokumentiert, auch das Manual des Programmautors Wietse Venema ist hervorragend.

Noch eine weitere Überlegung zum Thema Spam-Vermeidung:
Sofern Mails nicht beim Provider per Mailqueue übermittelt werden (ist nur für wirklich große Installationen interessant), gilt: ZUM Provider mit SMTP, VOM Provider mit POP3 oder IMAP. Es besteht zunächst mal kein Grund, einen externen Zugriff auf den eigenen SMTP von außen zu gestatten. Ein entsprechender iptables-Eintrag kanns regeln. Eine Ausnahme entsteht, wenn externe Mitarbeiter sich in den Server einwählen. Dieses bedeutet allerdings einen Einwahlzugang, den man unmittelbar auf einem Server ohnehin nicht riskieren sollte.

4.11. Postfix: Konfiguration: Namensanpassung / Rewrite

Wer von Zuhause schreibt, wird in der Regel keine Mailadresse als Login-Namen verwenden. Also müssen Mails beim Versenden und beim Empfang entsprechend umadressiert werden. Postfix hat dafür ein Programm, das "trivial rewrite". Dieses zieht seine Adresskenntnisse aus den Datentabellen im System. Die für uns wichtigste Tabelle ist die "sender_canonical". Der Vorspann-Text in der Datei beschreibt die Funktion recht anschaulich: "Sie möchten zum Beispiel die ABSENDER-Adresse user@ugly.domain in die Adresse user@pretty.domain umschreiben, aber immer noch Mails an die EMPFÄNGER-Adresse user@ugly.domain schicken können." Wie praktisch: genau dieses benötigt man, wenn man eine kleine, unregistrierte SoHo-Domain benutzt. Das Tabellenformat ist recht simpel: links der Name im lokalen Netz, rechts der "offizielle" Mail-Teilnehmername:

  root@pc.domain.lokal		vorname.nachname@gmx.de
  

Auch diese Tabelle wird in das Hash-Datenbankformat übersetzt, um schnellen Zugriff zu haben:

  >> postmap sender_canonical
  

  >> postfix reload
  

Damit ist das System lauffähig. Mails werden mit dieser Konfiguration nicht automatisch zum Provider versandt. Dazu ist das Kommando "sendmail -q" notwendig. (Wird unten im Fetchmail integriert!)

4.12. Postfix: Weiter gehende Möglichkeiten:

Alle /etc/postfix/*-Dateien und Samples durchsehen. regexp_table ist z.B. hochinteressant, um Spam gleich vom Fleck weg ins Nirwana zu jagen. Leider ist dieses Verfahren - im Gegensatz zur Sieve-Filterung - nicht vom User konfigurierbar. Ein weiteres, gutes Dokument, wenn auch nicht mehr ganz aktuell, ist das oben bereits erwähnte Postfix-HowTo von RedHat. Es gibt zu dem Postfix/Cyrus-Gespann eine ganze Menge Dokumente und HowTo's im Internet. Allerdings ist vieles davon nicht mehr aktuell, viele Optionen sind in den letzten Versionen neu dazugekommen.

Auch hier die Warnung: Dieser Mailer ist nicht per se sicher. Schotten Sie ein solches System per Firewall vom Internet ab. Stellen Sie unbedingt sicher, dass Sie nicht als Spam-Relay missbraucht werden können!

4.13. Virusscanner: Ein leidiges, aber unvermeidliches Thema

Die meisten Viren kommen heute per Mail. Es ist zu befürchten, dass es nur eine Frage der Zeit ist, bis die ersten effektiven Viren unter Linux auftauchen. Das geht vermutlich wie von selbst.
Da an einem Server auch Windows-PC angeschlossen sein könnten, sollte ein Mail-Virenscanner nicht fehlen. Für private Zwecke kostenlos (einer der wenigen!) ist der Virenscanner AntiVir von H + B EDV. Eigentlich ist das kein Mailvirenscanner, sondern ein ganz normaler Scanner, der z.B. über einen Eintrag im crontab praktischerweise auch zur regelmäßigen Kontrolle des Systems verwendet werden kann.

Ein perl-Script namens AMaViS sorgt nebst entsprechender Konfiguration für die Verbindung zwischen Mail und Virenscanner.

4.14. Virusscanner: AMaViS

.. ist ein Kürzel für "A Mail Virus Scanner". AMaViS ist ein Perl-Script, das Mails vom MTA entgegennimmt und die Mails mit einem normalen Virenscanner bearbeitet. Es war zuweilen ein diffiziles Unterfangen, Postfix, AmaViS und den Virenscanner aufeinander abzustimmen. Seit einiger Zeit hat Postfix jedoch eine Schnittstelle für Virenscanner u.ä. integriert. Dieses hat vieles sehr vereinfacht. Freundlicherweise hat SuSE eine für Postfix und AntiVir konfigurierte Version von AMaViS auf der CD. Die bei der Installation mit installierte Version ist nicht mehr aktuell; sie sollte vom SuSE-Server aktualisiert werden. Gegenüber reinen Mailscannern hat AmaViS einen Vorteil: Nahezu jeder für Linux verfügbare Virenscanner lässt sich integrieren. Auch ein Scanning mit mehreren Virenscannern nacheinander ist - genügend CPU-Power vorausgesetzt - möglich.

4.15. Virusscanner: Aktuell ist Pflicht!

AntiVir ist zwar auf der SuSE-CD enthalten, ist aber naturgemäß veraltet, so dass ein Update der Signaturdatei nicht mehr möglich ist. Nach der Installation von AMaViS und des Zubehörs einschließlich des AntiVir empfiehlt sich daher der Download der aktuellen Version (AntiVir für Linux Workstation) von der Homepage www.hbedv.de. Dort kann man - private Anwendung vorausgesetzt - auch einen Lizenzschlüssel für diese normalerweise kostenpflichtige Version anfordern. Er kommt postwendend per Mail und wird einfach in das Verzeichnis /usr/lib/AntiVir kopiert - fertig. AntiVir wird damit zu einer Vollversion. Dies ist für das Update über Internet wichtig, aber auch für einige Scanfunktionen, die ohne den Lizenzschlüssel blockiert sind. Beachten Sie, dass der Schlüssel nur noch für die Workstation-Version gilt. Dieses sollte trotzdem durchgeführt werden, da der Scanner ohne den Schlüssel keine aktualisierten Signaturen akzeptiert. Diese Variante, auch die Unterscheidung zwischen Server und Workstation Version, ist seit 02.04.2002 von H+B EDV neu eingeführt worden.

Die Workstation-Version scannt nicht innerhalb von Archiven, spielt jedoch für den Mailscanner keine Rolle: AmaViS packt freundlicherweise für den Scanner aus.

4.16. Virusscanner: Installation der neuesten Version

Die Installation der neuesten Version ist denkbar einfach. Das heruntergeladene .tgz-File wird mit

  >> tar -xzvf  avlxwks.tgz 
  

AntiVir verfügt über neue Features: Ein automatisiertes Update via Internet und ein "On Access"-Scanning. Die erste Frage der Installation:

     Would you like to install this new Featureset [y]
  

     Would you like Antivir to start automatically? [Y]
  

  >> ln -s /usr/lib/AntiVir/avguard /etc/init.d/rc3.d/K01avguard
  

     Would you like to configure AntiVir?
  

• NumDaemons: Wieviele parallele Scannerdaemons sollen laufen? Der Vorschlagswert ist 3; das ist für einen Server etwas "dünn", es wurde 10 gewählt.
• Would you like to scan files as they are opened (Dateien beim Öffnen scannen? Y
• Would you like to scan files as they are closed (Dateien beim Schließen scannen?) Y
• Would You Like to scan files as they are executed (Beim Ausführen scannen?) Y
• Would you like to try to repair infected files (Reparaturversuch an infizierten Dateien?)
  Gewissensfrage. Recht praktisch, kann im Einzelfall aber schief gehen, daher "n"
• How should infected Files be handled? Drei Optionen stehen zur Auswahl:
  l - Log only, nur Meldung loggen, keine Schutzfunktion!
  r - Remove, Dateien werden gelöscht
  m - Move, Dateien werden in ein Verzeichnis verlegt.
  Bei Anwahl der Option "m" wird nach einem Verzeichnis gefragt, in dem infected Files abgelegt werden sollen. Es muss schreibberechtigt für den Virenscanner sein, sollte aber für Normaluser völlig unzugänglich bleiben!
• Would you like email notofication of viruses? Möchten Sie bei Virusfund eine eMail?
  y, natürlich möchte ich das wissen....
• email address to receive notifications? Geben Sie die Empfängeradresse an, an die die Mail geschickt werden soll.
• Would you like antivir to log to a custom file? y, Im messages-File geht so eine Meldung zu schnell in der Masse unter! Eine separate Datei ist besser!
• What will be log filename with abolute path? Dies wurde auf /var/log/antivir gesetzt, als Dateipfad und Logname.
• include path: Gibt Pfade an, deren Dateien gescannt werden. unterverzeichnisse werden automatisch einbezogen. Der Default-Wert /home wurde zunächst beibehalten.
• exclude path: Dateien aus diesem Verzeichnis inklusive Unterverzeichnissen werden nicht gescannt.
• How often should antivir look for updates? Option d: daily (täglich), es kann eine Anzahl von Stunden gesetzt werden oder n für niemals.
• AutoUpdateTime: bei täglichem Update kann hier die Uhrzeit im Format HH:MM angegeben werden. Wer eine Standleitung oder Dialer benutzt, kann ein "r" (random) eingeben, dann wird eine Zufallszeit genutzt. Dies ist nur für permanent laufende Rechner sinnvoll.

Schlussendlich zeigt der Installer nun nochmal die komplette Optionsliste und fragt "save configuration settings". Ein y speichert die Konfiguration. Die letzte Abfrage möchte den Virenscanner nun sofort starten, dies kann man getrost mit y beantworten.

Bitte beachten Sie: Ein Scanner ist nur so gut, wie er aktuell gehalten wird. Diesen Satz sollten Sie tiefst verinnerlichen und danach handeln. Das System wird es Ihnen danken.

Sind Postfix, AMaViS und AntiVir installiert, kann der erste Test des Postfix starten:

  >> rcpostfix start
  

4.17. Der Weg der Mail...

... ein ganz knapper Abriss, welchen Weg eine Mail durch den Postfix nimmt. Eine ausführliche Darstellung findet sich in Wietse Venema's Manual.

Postfix erhält die gesamte eingehende Mail. Der pickup- oder der smtp-Daemon sammelt diese und übergibt an den cleanup-Daemon. Cleanup übernimmt das Umsetzen von Mailadressen anhand der Tabellen, sowie die Umsetzung in eine Standard-Form user@host.domain.tld durch Aufruf des trivial-rewrite-Daemons. Es werden einige Korrektheitsprüfungen durchgeführt. Anschließend wird die Mail als Datei in die incomming-Queue übergeben und der Queuemanager darüber informiert.

Der Queuemanager ist der eigentliche "Postarbeiter". Er sorgt wiederum per trivial-rewrite-Daemon für eine korrekte Adressierung, wertet die Transport-Tabelle aus, um den korrekten Weg zum Ziel zu ermitteln und kontaktiert dementsprechend die "Delivery-Agents", die für die Auslieferung zuständigen Daemons: smtp, lmtp, pipe oder local. Diese leiten die Mails dann weiter, z.B. lmtp an den Cyrus-Mailserver, smtp ans Internet usw.

In diesem Wirrwarr fehlt eigentlich noch eines: Die Schnittstelle zum Virenscanner. Nun, genaugenommen gibt es keine erkennbare Schnittstelle! Als Parameter in der main.cf wurde "content_filter = vscan:" angegeben. Dieses ist grundsätzlich auch ein "transport", also eine Ausliefer-Route, die lediglich immer (!) anzusprechen ist, unabhängig von der Zieladresse der Mail. Ein Blick in die master.cf zeigt, dass dieser Transport auch eingetragen ist: Der Transport vscan ruft das Programm AMaViS auf. AMaViS seinerseits gibt diese Mail wieder auf dem normalen Weg an Postfix zurück. Es nutzt dafür den smtp-Daemon auf dem localhost, jedoch auf dem Port 10025. Ein weiterer Blick in die master.cf zeigt auch diese Konfiguration. Sie enthält den Eintrag "content_filter=" und setzt - nur für diesen Empfangsweg! - den Content-Filter außer Kraft.
Der Nachteil dieses Verfahrens: Jede Mail läuft zweimal durch das gesamte Postfix-System.

Dem stehen allerdings zwei Vorteile gegenüber: Eine sehr einfache Konfiguration, auch für andere Virenscanner oder z.B. ein online-Verschlüsselungssystem und zum anderen die Tatsache, dass sowohl ankommende als auch abgehende Mail gescannt wird.

Bedenken Sie aber bitte: Der Port 10025 darf nicht von außen erreichbar sein, sonst kann das System umgangen werden! Eine Sperre mit iptables ist hier für ein produktives System Pflicht.

4.18. Cyrus: Der IMAP/POP3-MDA

Von einer kompletten Eigenkompilation ist einem Neueinsteiger abzuraten. Zu Cyrus gehört auch die SASL-Library. Diese wird auch von Programmen der Distribution verwendet. Suse hat hier wie immer Pfade geändert. Eine Selbstkompilation von SASL setzt genügend Kenntnisse voraus, um diese Systemintegration wieder herzustellen.

Der Mailserver wurde seit der Auflage der SuSe Version 7.3 aktualisiert und eine Sicherheitslücke bereinigt. Deshalb sollten Sie ihn nicht von der Distributions-CD, sondern aus den Updates vom SuSE-Server installieren. Laden Sie folgende Pakete vom SuSE-Server:

  perl-Cyrus-IMAP
  perl-Cyrus- SIEVE-managesieve.rpm
  perl-Cyrus-SIEVE-acap.rpm
  cyrus-imapd.rpm
  cyrus-sasl.rpm
  cyrus-sasl-gssapi.rpm
  

   >> rpm -i <dateiname>
  

  >> rpm -U cyrus-sasl.rpm
  

4.19. Cyrus: Verzeichnisse

Auch hier habe ich die Datenverzeichnisse in das /data/-Area verlagert, das Anpassen ist also die erste Aufgabe zur Konfiguration.
Achtung: Vermeiden Sie unbedingt, die Dateien bei laufendem Cyrus zu kopieren! Stoppen Sie Cyrus zunächst mit

  >> rccyrus stop
  

  >> mv /var/imap  /data/imap
  >> mkdir /data/spool
  >> mv /var/spool/imap /data/spool/imap
  

      750 (rwxr-x---)
  

4.20. Cyrus: /etc/inet.d

Öffnen Sie die Datei /etc/inetd.conf mit einem Editor und prüfen Sie die Einträge pop2, pop3 und imap. Diese Zeilen müssen auskommentiert sein. Cyrus-Imapd bindet direkt auf diese Ports und erzeugt lediglich Fehlermeldungen, wenn der inetd diese Ports bereits belegt hat.

4.21. Cyrus: /etc/services

Öffnen Sie die Datei /etc/services. Dort müssen folgende Einträge vorhanden sein, ggf. tragen Sie sie bitte ein oder ändern vorhandene Einträge entsprechend:

  pop3	110/tcp
  imap	143/tcp
  imsp	406/tcp
  acap	674/tcp
  imaps	993/tcp
  pop3s	995/tcp
  kpop	1109/tcp
  sieve	2000/tcp	(Kommentieren Sie die "callbook"-Einträge aus!)
  lmtp	2003/tcp
  fud	4201/udp
  

4.22. Cyrus: User cyrus

Der User cyrus ist bei SuSE bereits angelegt, ebenso die Gruppe mail. Bei anderen Distributionen muss der User ggf. angelegt werden. Es muss bei SuSE noch ein Kennwort für diesen Systemuser eingegeben werden mit

  >> passwd cyrus
  

4.23. Cyrus: /etc/imapd.conf

Öffnen Sie die Datei /etc/imapd.conf und passen Sie sie Ihren Gegebenheiten an.

configdirectory: /data/imap	Pfad anpassen
partition-default: /data/spool/imap	Pfad anpassen
admins: cyrus root	Wer darf verwalten
allowanonymouslogin: no	Anmeldung mit anonymous-User. Bitte nicht...
autocreatequota: 10000	Automatisch Mailboxlimit 10.000 KB anlegen
reject8bit: no	8bit-Zeichen im Mail-Header zulassen
quotawarn: 90	Warnmeldung bei Erreichen v. 90% d. Quota
timeout: 30	nach dieser Zeit wird die Verbindung abgebaut
poptimeout: 10	dito, bei Verwendung von POP
dracinterval: 0	Dynamic Relay Authorisation Control (off)
drachost: localhost
sasl_pwcheck_method: pam	PAM als Authentifizierungsmethode

Damit läuft der Cyrus IMAPD schon ordentlich. Wer genauer auf seine Umgebung anpassen will oder einfach Spaß am Systemtuning hat, sollte einen Blick in "man imapd.conf" werfen. Parameter reichlich....

4.24. Cyrus: /etc/cyrus.conf

Suchen Sie in der Sektion SERVICES die Zeilen beginnend mit "lmtpunix" bzw. "lmpt".
Es darf in der hier angegebenen Konfiguration nur eine dieser Zeilen aktiv sein, kommentieren Sie andere Zeilen aus. Ändern Sie die lmtpunix-Zeile zu:

  lmtpunix	cmd="lmtpd" listen="/var/spool/postfix/public/lmtp" prefork=0
  

   # at least one LMTP is required for delivery
   #  lmtp	cmd="lmtpd" listen="lmtp" prefork=0
   lmtpunix	cmd="lmtpd" listen="/var/spool/postfix/public/lmtp" prefork=0
  

Beachten Sie bitte: Postfix läuft in der hier beschriebenen Konfiguration in einer chroot-Umgebung. Das heisst, die Postfix-Prozesse "sehen" ein anderes Rootverzeichnis als z.B. der Cyrus, der nicht chrooted läuft. Im Cyrus lautet die Pfadangabe "/var/spool/postfix/public/lmtp", Cyrus nutzt das "echte" root-Verzeichnis. Der Postfix-Daemon läuft aber chrooted, er erkennt "/var/spool/postfix" als sein root-Verzeichnis "/"!
Deshalb muss die Pfadangabe in der Postfix-main.cf "public/lmtp" lauten, damit beide auf den gleichen Socket zugreifen.

4.25. Cyrus: Anpassen des Syslog

Um Fehlermeldungen besser auswerten zu können, werden folgende Änderungen vorgenommen: Öffnen Sie die Datei /etc/syslog.conf mit einem Editor und fügen Sie folgende Zeilen an das Ende der Datei:

   local6.debug		-/var/log/imapd.log
   auth.debug		-/var/log/auth.log
  

4.26. Cyrus: Erster Testlauf

Es sollte nun möglich sein, einen ersten Teststart zu veranstalten mit

  >> rccyrus start.
  

Weitere häufige Fehlermeldungen:

• "unable to bind to....",
  Cyrus kann nicht an die imap- bzw. pop3-Ports binden, dort "sitzt" ein anderes Programm. In aller Regel ist das der inetd. Editieren Sie die Datei /etc/inetd.conf und kommentieren Sie die Einträge für IMAP und POP aus.
• "Unable to open berkeley DB /etc/sasldb":
  unbedenklich. Der LMTP-Daemon nutzt die SASL-libs zur Authentifikation und sucht zunächst die Datenbank "sasldb". Da die Datei nicht vorhanden ist, meckert lmtp. Da die Authentifikation dann über andere Wege abläuft, ist diese Meldung beim Booten unbedenklich.

4.27. Cyrus: Anlegen der ersten Postfächer

Cyrus verwaltet Mails unabhängig von den Linux-Usern. Deshalb müssen Postfächer angelegt werden. Geben Sie ein:

  >> cyradm -u cyrus localhost
  

  IMAP password:
  

  localhost>
  

  localhost>  cm user.root
  

  localhost> lm
  

listacl user.root root lrswipcda	Anzeige der Berechtigungen
setacl user.dummy root lrswipcda	root bekommt alle Rechte für das Postfach "Dummy"
dm user.dummy	löscht das Postfach.

Eine beliebte Falle: Wenn Sie ein Postfach löschen wollen oder müssen, müssen Sie sich vorher die Rechte an diesem Postfach geben. Dann können Sie es löschen.

Noch eine Falle: Wenn Sie sich mit dem Usernamen bei cyradm anmelden, mit dem Sie auf dem Linux-PC angemeldet sind, erhalten Sie statt "user.<name>" die Anzeige "INBOX".

Das muss beim Anlegen von Benutzern beachtet werden:
Bitte lassen Sie beim Anlegen von Postfächern das vorangestellte Schlüsselwort "user." inklusive dem Punkt nicht weg! Cyrus unterscheidet durch diesen Vorspann Benutzer von z.B. öffentlichen Postfächern.
Es dürfen keine Namen mit Punkt wie z.B. "Anton.Mustermann" vergeben werden, Cyrus nutzt den Punkt als Trennzeichen. Normalerweise wird der Mailbox-Username mit dem Anmeldenamen identisch sein, und ein Anmeldename "Anton.Mustermann" ist eher die Ausnahme, so dass dies kein Problem darstellt. Eine Mailadresse "anton.mustermann@domain.tld" setzt Postfix problemlos per Tabelle um.

4.28. Nachträge

Wer in das /etc/pam.d-Verzeichnis schaut, wird bei SuSE kein imap-file finden. Womit authentifiziert Cyrus-IMAPD dann? Es muss doch immer ein Skript mit dem entsprechenden Namen vorhanden sein! Es gibt ein PAM-Skript, das immer dann verwendet wird, wenn kein spezielles Skript vorhanden ist: "other". Für den Testbetrieb oder ein kleines Netzwerk reicht das, sofern die User auf dem Linux-System einen eigenen Account haben. Dies ist bei kleinen Systemen, die gleichzeitig als Drucker-/Datengrab für Büro-PC dienen, zumeist so. Werden Windows-PC mit Samba als Server eingesetzt, wird i.d.R ein User angelegt, um Homeverzeichnisse und Zugriffsrechte unter Samba zu verwalten, damit ist dann der Mailuser gleich erledigt (nicht jedoch das Anlegen des Postfaches mit cyradm!).
Eine weitere Möglichkeit wäre eine Mailuserverwaltung über LDAP. In einer SoHo-Umgebung lohnt LDAP kaum; der Aufwand dafür ist hoch. Wer spezialisierte Mailserver aufsetzt, in denen keine Userkonten auf dem Mailserver angelegt werden sollen, hat neben LDAP zwei weitere Möglichkeiten: Man kann die SASLDB-Datenbank nutzen. Diese wird manuell gepflegt mit dem Befehl "saslpasswd". Eine aufwändigere Möglichkeit: User-Verwaltung über eine SQL-Datenbank. Auch eine Authentifikation gegen einen vorhandenen Windows-Server ist per PAM-Modul denkbar. Choose your Poison. Ebenfalls eine SQL-basierte Variante ist das Programm Replex. (http://www.replex.org)

4.29. Mail abholen

Bisher können wir intern Mails schicken und Mails zum Provider weitergeben.
Für das Abholen von Mails vom Provider gibt es grundsätzlich mehrere Möglichkeiten.
Zum einen kann der eigene Mailserver mit einem speziellen Kommando alle Mails vom Provider holen. Dazu sind einige Voraussetzungen zu erfüllen: Der Provider muss die gesamte Mail in einer Queue (Warteschlange) zusammenbündeln, und sowohl der Provider als auch der lokale Mailserver müssen ESMTP (Extended SMTP) beherrschen. Dies dürfte in dieser Kombination nur bei sehr großen Umgebungen zutreffen.
Die häufigere Variante ist die Verwendung des Programmes fetchmail. Es ist einfach zu konfigurieren, auch wenn Mail von verschiedenen Providern abgeholt werden soll. Fetchmail ist wohl in allen Distributionen enthalten.

4.30. Fetchmail: Konfiguration

Dazu sind nur zwei Schritte nötig. Zum einen müssen wir fetchmail mitteilen, für wen Mails bei welchem Provider abgeholt werden soll. Dazu wird im Verzeichnis /root eine Datei .fetchmailrc angelegt (der Punkt zu Beginn ist wichtig!). In der Datei wird für jeden User eine Zeile angelegt:

   poll pop.t-online.de with proto POP3  
     user `mustermann' there with password `geheim`  options fetchall is FranzM
   poll pop.gmx.de with proto POP3  
     user `Alexandra@gmx.de' there with password `Agent`  options fetchall keep is Alex
   postconnect `sendmail -q`
  

  >> chmod 710 .fetchmailrc
  

  poll <provider> proto <proto>

  user <uname> there with password <pword> options fetchall is <localUser>
  

In der letzten Zeile:
postconnect <command>: führt abschließend das Kommando <command> aus, hier werden die abgehenden Mails mit sendmail -q verschickt.
Dieses "sofort anschließend verschicken" umgeht ein Problem: Beim Versand können die Provider über SMTP oft nicht authentifizieren. Um Missbrauch zu vermeiden, prüfen viele Provider, ob vorher eine POP- oder IMAP-Verbindung bestanden hat, diese ist ja per Kennwort bestätigt (sogenanntes SMTP-after-POP). Wird sendmail -q sofort nach Abholen der Mails aufgerufen, reicht das. Es kann allerdings Probleme geben, wenn viele User große Mails über eine langsame Leitung abholen. Der erste User ist dann bereits ausserhalb des Zeitlimits, in dem SMTP nach dem POP-Aufruf erfolgen muss.

Wenn Sie Cyrus z.B. mit SQL als Userdatenbasis nutzen, anstatt Benutzerkonten anzulegen, müssen hier natürlich die in der SQL-Base gespeicherten Namen als lokale User in der .fetchmailrc angegeben werden.
Beim Experimentieren können schon mal Mails verloren gehen. Beugen Sie vor, nehmen Sie als zusätzliche Option den Parameter "keep" mit auf. Er verhindert das Löschen der Mails beim Provider. Wundern Sie sich allerdings nicht, wenn Sie die Mail trotzdem nur einmal zu sehen bekommen: Postfix kann die Doppelzustellung erkennen und ausfiltern. Im Notfall kommen Sie aber immer noch direkt beim Provider an die Mail (die Sie dort auch manuell löschen sollten, solange die Option "keep" noch vorhanden ist).

4.31. Hinweise

Bedenken Sie bitte, dass das System nicht internetsicher ist. Wenn Sie diese Mailfunktionen testen wollen, sollten Sie unbedingt eine Firewall zwischenschalten und weitere Maßnahmen ergreifen. Stellen Sie insbesondere sicher, dass kein Zugriff vom Internet auf den SMTP-Port Ihres Mailservers möglich ist! Sie könnten sonst schnell als Spam-Relay missbraucht werden, bevor Sie einen eventuellen Fehler in der Konfiguration finden.

Diese Konfiguration entspricht u.U. nicht den üblichen datenschutzrechtlichen Bestimmungen. Für die Konfiguration von fetchmail muss der User "root" die Mailkennworte der Benutzer kennen und kann Mails daher auch lesen oder unter dem Namen des Users versenden.

4.32. Automatisierung

Hierzu gibt es - wie immer - mehrere Möglichkeiten. Sie können fetchmail einerseits als Daemon starten mit

  >> fetchmail -d 1800
  

       0,30 1-23 * * * root /usr/bin/fetchmail
  

Da bereits ein Virenscanner installiert ist, könnte eine ähnliche Zeile auch gleich Userverzeichnisse scannen. Sollten Sie oben bei der Virusscanner-Installation jedoch "scan on open" bzw. "scan on close" aktiviert haben, scannen Sie jede Ddatei dann gleich dreimal, da der Scanner die Datei öffnet, schließt und selbst scannt.....

4.33. Ausbau

Wem ein solches Mailsystem noch nicht reicht, kann selbst darauf noch aufsatteln:

• WebSIEVE: Programmierung der Mailfilter per Web-Frontend (siehe Kapitel WebSieve)
• WebMail: Ein Frontend wie z.B. GMX oder Web.de, das wäre doch was.
  Eine einfache Möglichkeit: SquirrelMail, eine komfortablere: IMP
  (siehe Kapitel Squirrelmail und Horde/IMP)
• Faxgateway: Sowohl der Versand als auch der Empfang von Faxen ist machbar (Siehe Kapitel HylaFAX)
• Anrufbeantworter mit Mailmeldung: Eine Mail mit dem Anruf als angehängte Sounddatei ? No Problem! (Kapitel VBOX)

Talkback Area