Verfasst am: Mi Sep 29, 2004 21:34 
CoolCasimir
Anmeldedatum: 14.01.2004
Wohnort: Hansestadt Hamburg
Beiträge: 2192
Linux Mailserver einrichten
Zur Einführung ein wenig Theorie. Allemal grau ist
bekanntlich alle Theorie, aber es fördert schon das Verständnis für die Vorgänge
in einem solchen System.
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 http://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
Deinstallieren Sie sendmail mit
>> rpm -e --nodeps sendmail
und verfahren Sie wie unter "Postfix: Update" beschrieben.
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!
Was bedeuten diese Einträge: CHROOT: yes rcconfig soll Postfix in die chroot Umgebung umsetzen
DIALUP: yes Mails werden gesammelt und erst auf Befehl versandt, das verhindert die Anwahl für jede einzelne mail (Flatrate-Besitzer können es auf no setzen, die Glücklichen.. )
Masquerade_Domain In der Regel wird man selbst eine andere (Intranet-)Domain verwenden als die des Mailproviders... Hier wird ein Eintrag in die postfix- Konfiguration eingebaut, um diese Adressen umzumaskieren.
NODNS: yes Es wird nicht für jede Mail automatisch eine DNS-Auflösung gestartet.
DIALUP Es soll nicht für jede Mail angewählt werden.
RELAYHOST Da werden die Mails hingeschickt....
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
(oder einen anderen User als John..) vorhanden sein. Ein weiterer Pflichteintrag ist
postfix: root
Prüfen Sie diese beiden Einträge, ergänzen Sie sie nötigenfalls. Beachten Sie bitte, dass aliases nicht im Klartext verwendet wird, sondern aus Geschwindigkeitsgründen in ein besonderes Datenbankformat übersetzt wird, unter Linux i.d.R. in das hash-Format. Wenn Sie Änderungen an /etc/aliases vornehmen, muss unbedingt anschließend der Befehl newaliases folgen. Newaliases erzeugt aus der aliases die eigentliche Hash-Datenbank aliases.db.
Erfolgt dieser Schritt nicht, werden die Änderungen nicht wirksam.
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.
/etc/postfix/master.cf
# ==========================================================================
# 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.
/etc/postfix/main.cf
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
Speichern Sie die Datei wieder ab. Auch hier gilt wie bei der aliases: Die Datei muss in ein Datenbankformat übersetzt werden. In diesem Fall geben Sie einfach
postmap access
ein, um die access.db zu erzeugen. Damit wird nur dem lokalen Rechner die Erlaubnis erteilt, Postfix als Relay zu nutzen.
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
Sicherheitshalber füge ich i.d.R. noch root@domain.lokal und root mit der gleichen offiziellen Adresse dazu.
Auch diese Tabelle wird in das Hash-Datenbankformat übersetzt, um schnellen Zugriff zu haben:
>> postmap sender_canonical
Wenn Sie Table-Dateien geändert und mit postmap übersetzt haben, oder eine der .cf-Dateien geändert haben, sollten Sie Postfix dies durch ein
>> postfix reload
mitteilen. Der Befehl veranlasst Postfix, die Konfiguration neu einzulesen, ohne den Betrieb zu unterbrechen.
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 http://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
entpackt. In dem ausgepackten Verzeichnis wird die Datei install gestartet. Diese installiert alle notwendigen Dateien usw. Die Konfiguration verläuft menügeführt in wenigen, kurzen Schritten. Eine vorhandene Version wird dabei überschrieben.
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]
sollte man mit y beantworten: beides macht Sinn. Danach sucht AntiVir nach der Kernelversion und beginnt mit dem Kopiervorgang. Danach fragt Antivir nach dem Autostart:
Would you like Antivir to start automatically? [Y]
Auch dieses sollte man bejahen, damit der Scanner automatisch beim Booten mit anläuft.
Das System legt in dem Moment einen Startlink an. Leider legt es jedoch keinen Stop-Link an, was das Testsystem beim Systemstop in Verwirrnis brachte: Der Server ließ sich nicht mehr stoppen. Ein manuell nachgetragener Link
>> ln -s /usr/lib/AntiVir/avguard /etc/init.d/rc3.d/K01avguard
brachte Abhilfe. Die eigentliche Installation ist beendet. Der Installer fragt nun
Would you like to configure AntiVir?
Auch dieses ist zu bejahen, damit wird eine Datei /etc/avguard.conf angelegt. Der Installer stellt viele Fragen....
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
Prüfen Sie die Errorlogs /var/log/messages und /var/log/mail auf besondere Fehlermeldungen.
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
Wer möchte / braucht: cyrus-imapd-devel, cyrus-sasl-devel.
Bei dieser Gelegenheit muss das Paket cyrus-sasl aktualisiert werden.
Installieren Sie die Pakete mit dem Befehl
>> rpm -i <dateiname>
Installieren Sie die perl-Pakete zuerst, sonst verweigert die Installation von cyrus-imapd.
Das Paket cyrus-sasl ist bereits installiert und wird aktualisiert mit:
>> rpm -U cyrus-sasl.rpm
Das Installationsskript setzt in der /etc/rc.config den Eintrag START_CYRUS="yes" und startet den Dienst.
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
Die Verzeichnisse /var/imap und /var/spool/imap wurden nach /data/imap und /data/spool/imap verlegt:
>> mv /var/imap /data/imap
>> mkdir /data/spool
>> mv /var/spool/imap /data/spool/imap
Danach sollte man unbedingt die Benutzerrechte kontrollieren. Normalerweise werden diese zwar korrekt mit übernommen, es kann aber nicht schaden. Das Verzeichnis /var/imap und die Unterverzeichnisse sind alle Owner:cyrus und group:mail mit den Berechtigungen
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
Bei der SuSE-Distribution sind die Einträge bis einschließlich pop3s vorhanden, der Rest muss angepasst bzw. nachgetragen werden.
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
und dem neuen Kennwort.
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
Als Ausschnitt aus der cyrus.conf:
# 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
Cyrus und Postfix können über eine Unix-Pipe kommunizieren, aber auch über einen Socket mit der Bezeichnung lmtp. Dazu notwendig ist ein Verzeichnis, das beide Programme gemeinsam nutzen, hier /var/spool/postfix/public/lmtp.
Der lmtp-Socket ist notwendig, wenn der Mailfilter "Sieve" genutzt werden soll.
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
Damit wird die Protokollierung von cyrus-IMAPD und der Authentifizierung in eigene Logfiles umgeleitet. Den Parameter "debug" sollte man später entfernen: Er sorgt für ausführliche und entsprechend große Logdateien.
4.26. Cyrus: Erster Testlauf
Es sollte nun möglich sein, einen ersten Teststart zu veranstalten mit
>> rccyrus start.
Es dauert einen Moment, dann sollte der Eingabeprompt wieder erscheinen. Die erste Kontrolle ist wie immer das Errorlog /var/log/messages. Ein Hinweis "no service Sieve" in /etc/services/ deutet darauf hin, dass das Editieren der /etc/services nicht oder nicht korrekt vorgenommen wurde. Beim ersten Start tauchen etliche Meldungen "creating /data/imap..." auf. Es werden Dateien und Verzeichnisse angelegt. Bei jedem Start, und regelmäßig ein- bis mehrmals am Tag, taucht eine Anzahl Meldungen "duplicate_prune /data/imap...." auf.
Cyrus ist defaultmäßig darauf eingestellt, uns mehrfach geschickte Mails nicht mehrfach zu präsentieren, sondern diese auszusortieren. "duplicate_prune..." ist einfach nur der damit verbundene "Aufräumprozess".
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
oder einen anderen Admin-Berechtigten, je nach dem, was Sie in der imapd.conf eingetragen haben. Das Programm sollte mit der Abfrage
IMAP password:
antworten. Das Kennwort für den Admin-User eingeben, danach sollte der Prompt
localhost>
erscheinen. Mit einem ? erhält man eine Befehlsliste. Die erste Mailbox für den root-user wird angelegt mit
localhost> cm user.root
Ein anschließendes
localhost> lm
zeigt die bereits angelegte mailbox user.root. Das cyradm-Programm wird mit dem Kommando "exit" verlassen.
Weitere Kommandos:
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`
Speichern Sie die Datei ab, und setzen Sie die Rechte auf
>> chmod 710 .fetchmailrc
(Eine nette Falle: Bei einigen Providern muss nur ein Name angegeben werden, bei anderen stattdessen name@domain.tld...)
Die Parameter erklären sich fast von selbst:
poll <provider> proto <proto>
user <uname> there with password <pword> options fetchall is <localUser>
poll Hole Mail ab
<proto> Mailprotokoll des Providers, hier POP3
<provider> Webadresse des Mailservers des Providers, z.B. mail.gmx.net
<uname> User Name auf dem Mailer des Providers
<pword> Kennwort des Users auf dem Mailserver
options fetchall Alle Mails abholen (werden beim Provider gelöscht!)
..keep zusätzliche Option für Testzwecke: Mails werden beim Provider nicht gelöscht.
<localUser> Lokaler Benutzername des Users im Mailsystem
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
Fetchmail läuft dann im Hintergrund und löst alle 30 Minuten (1800 Sekunden) den Mailtransfer aus.
Eine Alternative ist die Verwendung der crontab-Tabelle. Der Eintrag
0,30 1-23 * * * root /usr/bin/fetchmail
löst den Mailtransfer immer zur vollen und halben Stunde von 1 Uhr morgens bis 23 Uhr abends aus. Hier wurde bewusst eine Lücke gelassen, die z.B. zur Datensicherung verwendet werden kann, oder auch nützlich ist, wenn eine DSL-Flatrate-Leitung um Mitternacht getrennt wird.
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.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 http://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
Deinstallieren Sie sendmail mit
>> rpm -e --nodeps sendmail
und verfahren Sie wie unter "Postfix: Update" beschrieben.
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!
Was bedeuten diese Einträge: CHROOT: yes rcconfig soll Postfix in die chroot Umgebung umsetzen
DIALUP: yes Mails werden gesammelt und erst auf Befehl versandt, das verhindert die Anwahl für jede einzelne mail (Flatrate-Besitzer können es auf no setzen, die Glücklichen.. )
Masquerade_Domain In der Regel wird man selbst eine andere (Intranet-)Domain verwenden als die des Mailproviders... Hier wird ein Eintrag in die postfix- Konfiguration eingebaut, um diese Adressen umzumaskieren.
NODNS: yes Es wird nicht für jede Mail automatisch eine DNS-Auflösung gestartet.
DIALUP Es soll nicht für jede Mail angewählt werden.
RELAYHOST Da werden die Mails hingeschickt....
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
(oder einen anderen User als John..) vorhanden sein. Ein weiterer Pflichteintrag ist
postfix: root
Prüfen Sie diese beiden Einträge, ergänzen Sie sie nötigenfalls. Beachten Sie bitte, dass aliases nicht im Klartext verwendet wird, sondern aus Geschwindigkeitsgründen in ein besonderes Datenbankformat übersetzt wird, unter Linux i.d.R. in das hash-Format. Wenn Sie Änderungen an /etc/aliases vornehmen, muss unbedingt anschließend der Befehl newaliases folgen. Newaliases erzeugt aus der aliases die eigentliche Hash-Datenbank aliases.db.
Erfolgt dieser Schritt nicht, werden die Änderungen nicht wirksam.
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.
/etc/postfix/master.cf
# ==========================================================================
# 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.
/etc/postfix/main.cf
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
Speichern Sie die Datei wieder ab. Auch hier gilt wie bei der aliases: Die Datei muss in ein Datenbankformat übersetzt werden. In diesem Fall geben Sie einfach
postmap access
ein, um die access.db zu erzeugen. Damit wird nur dem lokalen Rechner die Erlaubnis erteilt, Postfix als Relay zu nutzen.
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
Sicherheitshalber füge ich i.d.R. noch root@domain.lokal und root mit der gleichen offiziellen Adresse dazu.
Auch diese Tabelle wird in das Hash-Datenbankformat übersetzt, um schnellen Zugriff zu haben:
>> postmap sender_canonical
Wenn Sie Table-Dateien geändert und mit postmap übersetzt haben, oder eine der .cf-Dateien geändert haben, sollten Sie Postfix dies durch ein
>> postfix reload
mitteilen. Der Befehl veranlasst Postfix, die Konfiguration neu einzulesen, ohne den Betrieb zu unterbrechen.
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 http://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
entpackt. In dem ausgepackten Verzeichnis wird die Datei install gestartet. Diese installiert alle notwendigen Dateien usw. Die Konfiguration verläuft menügeführt in wenigen, kurzen Schritten. Eine vorhandene Version wird dabei überschrieben.
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]
sollte man mit y beantworten: beides macht Sinn. Danach sucht AntiVir nach der Kernelversion und beginnt mit dem Kopiervorgang. Danach fragt Antivir nach dem Autostart:
Would you like Antivir to start automatically? [Y]
Auch dieses sollte man bejahen, damit der Scanner automatisch beim Booten mit anläuft.
Das System legt in dem Moment einen Startlink an. Leider legt es jedoch keinen Stop-Link an, was das Testsystem beim Systemstop in Verwirrnis brachte: Der Server ließ sich nicht mehr stoppen. Ein manuell nachgetragener Link
>> ln -s /usr/lib/AntiVir/avguard /etc/init.d/rc3.d/K01avguard
brachte Abhilfe. Die eigentliche Installation ist beendet. Der Installer fragt nun
Would you like to configure AntiVir?
Auch dieses ist zu bejahen, damit wird eine Datei /etc/avguard.conf angelegt. Der Installer stellt viele Fragen....
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
Prüfen Sie die Errorlogs /var/log/messages und /var/log/mail auf besondere Fehlermeldungen.
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
Wer möchte / braucht: cyrus-imapd-devel, cyrus-sasl-devel.
Bei dieser Gelegenheit muss das Paket cyrus-sasl aktualisiert werden.
Installieren Sie die Pakete mit dem Befehl
>> rpm -i <dateiname>
Installieren Sie die perl-Pakete zuerst, sonst verweigert die Installation von cyrus-imapd.
Das Paket cyrus-sasl ist bereits installiert und wird aktualisiert mit:
>> rpm -U cyrus-sasl.rpm
Das Installationsskript setzt in der /etc/rc.config den Eintrag START_CYRUS="yes" und startet den Dienst.
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
Die Verzeichnisse /var/imap und /var/spool/imap wurden nach /data/imap und /data/spool/imap verlegt:
>> mv /var/imap /data/imap
>> mkdir /data/spool
>> mv /var/spool/imap /data/spool/imap
Danach sollte man unbedingt die Benutzerrechte kontrollieren. Normalerweise werden diese zwar korrekt mit übernommen, es kann aber nicht schaden. Das Verzeichnis /var/imap und die Unterverzeichnisse sind alle Owner:cyrus und group:mail mit den Berechtigungen
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
Bei der SuSE-Distribution sind die Einträge bis einschließlich pop3s vorhanden, der Rest muss angepasst bzw. nachgetragen werden.
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
und dem neuen Kennwort.
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
Als Ausschnitt aus der cyrus.conf:
# 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
Cyrus und Postfix können über eine Unix-Pipe kommunizieren, aber auch über einen Socket mit der Bezeichnung lmtp. Dazu notwendig ist ein Verzeichnis, das beide Programme gemeinsam nutzen, hier /var/spool/postfix/public/lmtp.
Der lmtp-Socket ist notwendig, wenn der Mailfilter "Sieve" genutzt werden soll.
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
Damit wird die Protokollierung von cyrus-IMAPD und der Authentifizierung in eigene Logfiles umgeleitet. Den Parameter "debug" sollte man später entfernen: Er sorgt für ausführliche und entsprechend große Logdateien.
4.26. Cyrus: Erster Testlauf
Es sollte nun möglich sein, einen ersten Teststart zu veranstalten mit
>> rccyrus start.
Es dauert einen Moment, dann sollte der Eingabeprompt wieder erscheinen. Die erste Kontrolle ist wie immer das Errorlog /var/log/messages. Ein Hinweis "no service Sieve" in /etc/services/ deutet darauf hin, dass das Editieren der /etc/services nicht oder nicht korrekt vorgenommen wurde. Beim ersten Start tauchen etliche Meldungen "creating /data/imap..." auf. Es werden Dateien und Verzeichnisse angelegt. Bei jedem Start, und regelmäßig ein- bis mehrmals am Tag, taucht eine Anzahl Meldungen "duplicate_prune /data/imap...." auf.
Cyrus ist defaultmäßig darauf eingestellt, uns mehrfach geschickte Mails nicht mehrfach zu präsentieren, sondern diese auszusortieren. "duplicate_prune..." ist einfach nur der damit verbundene "Aufräumprozess".
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
oder einen anderen Admin-Berechtigten, je nach dem, was Sie in der imapd.conf eingetragen haben. Das Programm sollte mit der Abfrage
IMAP password:
antworten. Das Kennwort für den Admin-User eingeben, danach sollte der Prompt
localhost>
erscheinen. Mit einem ? erhält man eine Befehlsliste. Die erste Mailbox für den root-user wird angelegt mit
localhost> cm user.root
Ein anschließendes
localhost> lm
zeigt die bereits angelegte mailbox user.root. Das cyradm-Programm wird mit dem Kommando "exit" verlassen.
Weitere Kommandos:
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`
Speichern Sie die Datei ab, und setzen Sie die Rechte auf
>> chmod 710 .fetchmailrc
(Eine nette Falle: Bei einigen Providern muss nur ein Name angegeben werden, bei anderen stattdessen name@domain.tld...)
Die Parameter erklären sich fast von selbst:
poll <provider> proto <proto>
user <uname> there with password <pword> options fetchall is <localUser>
poll Hole Mail ab
<proto> Mailprotokoll des Providers, hier POP3
<provider> Webadresse des Mailservers des Providers, z.B. mail.gmx.net
<uname> User Name auf dem Mailer des Providers
<pword> Kennwort des Users auf dem Mailserver
options fetchall Alle Mails abholen (werden beim Provider gelöscht!)
..keep zusätzliche Option für Testzwecke: Mails werden beim Provider nicht gelöscht.
<localUser> Lokaler Benutzername des Users im Mailsystem
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
Fetchmail läuft dann im Hintergrund und löst alle 30 Minuten (1800 Sekunden) den Mailtransfer aus.
Eine Alternative ist die Verwendung der crontab-Tabelle. Der Eintrag
0,30 1-23 * * * root /usr/bin/fetchmail
löst den Mailtransfer immer zur vollen und halben Stunde von 1 Uhr morgens bis 23 Uhr abends aus. Hier wurde bewusst eine Lücke gelassen, die z.B. zur Datensicherung verwendet werden kann, oder auch nützlich ist, wenn eine DSL-Flatrate-Leitung um Mitternacht getrennt wird.
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.....
Zuletzt bearbeitet von CoolCasimir am Do Dez 09, 2004 15:19, insgesamt einmal bearbeitet
_________________
Gruß CoolCasimir
PHP Gallery | Datei Upload in PHP mit Userlogin | Newssystem mit Userverwaltung | Flammenschrift estellen
______________________________________________
Nil tam difficile est, quin quaerendo investigari possiet
. Werde eine
Änderung, hoffendlich in deinem Sinne, vornehmen. Der erste Satz war
überflüssig. Die Datenbank verträgt auch gute, ausführliche Artikel. Jede(r)
kann schliesslich lesen, was interessiert 
Die Pakete
sind auf der DVD und nicht auf den CD,s !
- hat mir bis
jetzt sehr geholfen einen kleinen Mailserver aufzusetzen 
Registrieren
FAQ
Mitgliederliste
Benutzergruppen.jpg)