IMAP E-Mail-Server unter Linux einrichten
Inhalt
Worum geht es überhaupt?
Diese Anleitung beschreibt die Einrichtung eines IMAP E-Mail-Servers für ein
kleines Netzwerk unter
Debian Woody (http://www.debian.org).
Ziel ist es, ein zentrales "E-Mail-Lager"
einzurichten, auf das via IMAP aus dem ganzen Netzwerk zugegriffen werden
kann.
Da heutzutage niemand mehr von der Spam-Problematik verschont bleibt,
soll außerdem bereits beim Einsortieren der Mails eine Filterung
geschehen, die einen Großteil des ungewünschten Mülls entsprechend
vorsortiert.
Hinweis: Soweit nicht anders erwähnt, müssen alle Schritte
in dieser Anleitung als Superuser
root ausgeführt werden, da es
sich um administratorische Arbeiten handelt, die weitreichende Rechte
erfordern. Nach Beendigung der Konfiguration darf man aber nicht vergessen,
sich wieder als normaler User am System anzumelden!
-> Nach oben
Eingesetzte Software
Cyrus 1.5.19
(http://asg.web.cmu.edu/cyrus/imapd/)
Exim 3.35
(http://www.exim.org)
Fetchmail 5.9.11
Bogofilter 0.17.4
(http://sourceforge.net/projects/bogofilter/)
SpamAssassin 2.63
(http://www.spamassassin.org)
-> Nach oben
Serverkonfiguration
Mails abholen mit Fetchmail
Ganz am Anfang liegen unsere Mails noch beim Provider und müssen von dessen
POP3-Server abgeholt werden. Abholen können wir sie ganz einfach mit dem
Programm Fetchmail, das wir aber erst noch installieren müssen.
Wer möchte, kann Fetchmail auch aus den Sourcen installieren. Eine
Anleitung dazu findet sich unter
http://www.newbie-net.de/anleitung_fetchmail.html#install_src
Debian-typisch ist die Installation aber mit einem einfachen Befehl
geschehen:
apt-get install fetchmail fetchmail-common
Die anschließenden Fragen zur Konfiguration beantwortet man
folgendermaßen:
Install a system-wide fetchmail service? - "Yes"
Run system-wide fetchmail as root? - "No"
Jetzt muß man Fetchmail noch sagen, wo es die Mails abholen soll. Dies
erfolgt unter Debian in der Konfigurationsdatei
/etc/fetchmailrc. Diese Datei existiert nicht, sondern
muß neu angelegt werden. Dies
geschieht mit folgenden Befehlen, mit denen wir auch gleich die richtigen
Rechte setzen:
touch /etc/fetchmailrc
chmod 600 /etc/fetchmailrc
Eine Beispieldatei könnte so aussehen:
set no bouncemail
poll pop.Mein-Provider.de protocol POP3 \
user "Mein-Benutzername" password "Mein-Passwort" is "lokaler-benutzername" fetchall
Die Angaben für den POP3-Server, Benutzernamen und Paßwort sowie der lokale
Benutzername sind natürlich entsprechend anzupassen.
Wem meine Ausführungen zu Fetchmail zu knapp sind:
Karsten Kruse hat unter
http://www.newbie-net.de/anleitung_fetchmail.html eine etwas detailliertere
Anleitung zu Fetchmail verfaßt, die sicher die eine oder andere Frage noch
beantworten kann. Und ansonsten hilft (wie immer) die gute Manpage weiter.
-> Nach oben
Exim verteilt unsere Mails weiter
Fetchmail hat unsere Mails abgeholt, nun müssen sie weiterverteilt werden.
Die nächste Station auf dem Weg ist der lokale Mailserver. Bei Debian ist
das standardmäßig Exim, das bereits bei der Installation
eingerichtet wird.
Wer sich nicht mehr sicher ist, welche Optionen er bei der Installation
gewählt hat, kann dies jederzeit mit dem Befehl
eximconfig nachholen.
Auf unserem Server sollte Exim mit den folgenden Einstellungen eingerichtet
werden:
Select a number from 1 to 5, from the list above.
"2" ist die richtige Wahl (
Internet site using smarthost).
What is the `visible' mail name of your system?
Hier muß der Name des Servers eingetragen werden, also z.B.
mailserver.meine-domain.de
Wichtig: Dieser Name muß ein gültiger FQDN
(Fully Qualified Domain Name) sein. Wer keine eigene
Domain besitzt, kann sich solch einen FQDN auch kostenlos bei einem Service
wie
http://www.my-fqdn.de
besorgen.
Does this system have any other names which may appear on incoming mail messages(...)?
Hier kann im Normalfall einfach <Enter> gedrückt werden
Are there any domains you want to relay mail for?
Wenn man nicht sehr genau weiß, was man tut, sollte man hier auf gar
keinen Fall etwas eintragen. Andernfalls könnte der eigene Rechner
ungewollt zum offenen Relay für Spammer werden.
Are there any networks of local machines you want to relay mail for?
Da unser Mailserver als Server für ein kleines Netzwerk dienen soll, gibt man
hier das Netzwerk an, das seine Mails über den Server verschicken soll.
Liegen alle IP-Adressen des lokalen Netzes beispielsweise im Bereich
192.168.1.x, so lautet die Angabe:
192.168.1.0/24
Which machine will act as the smarthost and handle outgoing mail?
Hier gibt man den Namen des Mailausgangsservers seines Providers an, z.B.
smtp.mein-provider.de
Which user account(s) should system administrator mail go to?
Da man unter Linux aus Sicherheitsgründen nie als
root arbeiten
sollte, können alle Mails, die für
root bestimmt sind, an einen
lokalen Benutzer weitergeleitet werden. Hier sollte man den eigenen
User-Account angeben, also z.B.
lokaler-benutzername
In der abschließenden Übersicht prüft man noch einmal die
getätigten Einstellungen und bestätigt dann mit
Y
Damit die von Fetchmail abgeholten Mails von Exim auch an das für die
Sortierung zuständige Procmail weitergegeben werden, ist allerdings noch
ein wenig Handarbeit nötig. In der Konfigurationsdatei
/etc/exim/exim.conf müssen folgende Änderungen vorgenommen
werden:
# /etc/exim/exim.conf
#
(...)
#######################################################################
# TRANSPORTS CONFIGURATION #
#######################################################################
# Zustellung via Procmail:
procmail_pipe:
driver = pipe
command = "/usr/bin/procmail -t -d ${local_part}"
from_hack
return_path_add
delivery_date_add
envelope_to_add
check_string = "From "
escape_string = ">From "
user = $local_part
group = mail
#######################################################################
# DIRECTORS CONFIGURATION #
# Specifies how local addresses are handled #
#######################################################################
(...)
localuser:
driver = localuser
transport = procmail_pipe
(...)
Die meisten Smarthosts erfordern inzwischen eine Authentifizierung per
SMTP-AUTH, da nur so ein Mißbrauch als offenes Relay zuverlässig
verhindert werden kann. Exim für die Nutzung von SMTP-AUTH zu
konfigurieren, ist sehr einfach und erfordert nur einen kleinen Eintrag in
der
/etc/exim/exim.conf:
(...)
#######################################################################
# AUTHENTICATION CONFIGURATION #
#######################################################################
plain:
driver = plaintext
public_name = PLAIN
client_send = "^Benutzername^Paßwort"
# End of Exim configuration file
Die Einträge für Benutzername und Paßwort sind natürlich
entsprechend anzupassen.
Um zu verhindern, daß der eigene Mailserver als offenes Relay von
Spammern aus dem Internet mißbraucht werden kann, sollte man Exim
außerdem so konfigurieren, daß es nur auf den internen
IP-Adressen "lauscht". Dazu gilt es wieder die
/etc/exim/exim.conf
zu bearbeiten und diesmal diesen Eintrag abzuändern:
# This will cause it to accept mail only from the local interface
local_interfaces = 127.0.0.1:192.168.1.1
Dieses Beispiel geht davon aus, daß der Mailserver die IP-Adresse
192.168.1.1 besitzt. Lautet sie anders, so ist der Eintrag
entsprechend anzupassen.
Wer einen eher schwachbrüstigen Rechner als Server einsetzt, der kann
unter Umständen Probleme mit dem großen Speicherhunger von
SpamAssassin bekommen. Abhilfe schaffen können diese Einträge
in der
exim.conf, die die Zahl der gleichzeitig verarbeiteten Mails
begrenzen und zudem auf die Auslastung des Systems reagieren:
smtp_accept_queue_per_connection = 4
smtp_accept_queue = 6
queue_only_load = 0.8
Da Exim unter Debian normalerweise über den Inetd gestartet wird, ist
ein Neustart des Programms nicht nötig; die geänderte
Konfigurationsdatei wird in diesem Fall automatisch berücksichtigt.
-> Nach oben
Procmail sortiert
Nachdem wir jetzt Exim gesagt haben, daß es unsere Mails zur Sortierung an
Procmail weitergeben soll, müssen wir natürlich Procmail
einrichten und einstellen, was es mit den Mails machen soll.
Die Installation ist einfach wie gehabt:
apt-get install procmail
Als nächstes legt man ein Log-Verzeichnis für Procmail an:
mkdir /var/log/mail
chown mail.root /var/log/mail
Die Konfiguration von Procmail geschieht in der globalen Konfigurationsdatei
/etc/procmailrc. Diese Datei sieht bei mir folgendermaßen aus:
# /etc/procmailrc
#
# Zuerst einige allgemeine Definitionen:
#
# cyrdeliever sortiert die Mails in die Cyrus-Mailboxen ein:
DELIVERMAIL="/usr/sbin/cyrdeliver"
#
# Das Logfile, in das Fehlermeldungen etc. geloggt werden:
LOGFILE="/var/log/mail/procmail.log"
#
# Damit die procmailrc übersichtlicher bleibt, vergeben wir
# "Kurznamen" für einige Zustellbefehle. Auskunft über
# die genaue Syntax gibt die Manpage zu cyrdeliever.
IMAP="$DELIVERMAIL -e -a $LOGNAME -m user.$LOGNAME"
BACKUP="$DELIVERMAIL -e -a $LOGNAME -m user.$LOGNAME.Backup"
GMXSPAM="$DELIVERMAIL -e -a $LOGNAME -m user.$LOGNAME.GMX-SPAM"
BOGOSPAM="$DELIVERMAIL -e -a $LOGNAME -m user.$LOGNAME.BogoSPAM"
SPAMIT="$DELIVERMAIL -e -a $LOGNAME -m user.$LOGNAME.SPAM"
#
# Um detailliertere Fehlermeldungen zu loggen, VERBOSE auf on setzen
VERBOSE=off
# Zur Sicherheit ein Backup, falls bei der Zustellung etwas
# schiefgeht:
#
# "/bin/sed 1d" dient dazu, den von Procmail gesetzten ungültigen
# "From"-Header wieder zu entfernen!
#
:0 c
| /bin/sed 1d | $BACKUP
# bei Fehler zurück in die Queue
:0 e
{ EXITCODE=75 HOST }
# Manche GMX-Mails sind schon als Spam gekennzeichnet
:0
* ^*** GMX Spamverdacht ***
| /bin/sed 1d | $GMXSPAM
# bei Fehler zurück in die Queue
:0 e
{ EXITCODE=75 HOST }
# Überprüfung durch Bogofilter
#
:0fw
| /usr/bin/bogofilter -u -e -p -l -d /home/$LOGNAME/.bogofilter/
:0
* ^X-Bogosity: Yes, tests=bogofilter
| /bin/sed 1d | $BOGOSPAM
# bei Fehler zurück in die Queue
:0 e
{ EXITCODE=75 HOST }
# Überprüfung durch Spam Assassin
#
:0fw
| /usr/bin/spamc -u $LOGNAME
:0
* ^X-Spam-Status: Yes
| /bin/sed 1d | /usr/bin/spamassassin -d | $SPAMIT
# bei Fehler zurück in die Queue
:0 e
{ EXITCODE=75 HOST }
# Zustellung in die INBOX des Users:
#
:0 w
| /bin/sed 1d | $IMAP
# bei Fehler zurück in die Queue
:0 e
{ EXITCODE=75 HOST }
# Das Ergebnis der Zustellung wird geloggt:
#
:0 w
{
EXITCODE=$?
HOST
}
Wem das ganze etwas kryptisch vorkommt, der liegt vollkommen richtig. Procmail
ist nicht ganz einfach zu konfigurieren, bietet dafür aber mächtige
Filtermöglichkeiten.
In diesem Beispiel wird Procmail für folgendes genutzt: Zuerst wird ein Backup jeder
Mail im IMAP-Ordner
INBOX/Backup erzeugt. User mit GMX-Accounts haben meist
schon einen aktivierten Spam-Filter, daher kann man alle derart gekennzeichneten
Mails direkt vorab aussortieren und im IMAP-Ordner
INBOX/GMX-SPAM ablegen.
Die anderen Mails werden dann zuerst durch Bogofilter geprüft. Hält Bogofilter
die Mail für Spam, wird sie unter
INBOX/BogoSPAM gespeichert, andernfalls
prüft SpamAssassin die Mail ebenfalls. Je nach Ergebnis dieser letzten Prüfung
landet die Mail dann im IMAP-Ordner
INBOX oder im IMAP-Ordner
INBOX/SPAM.
Die
procmailrc ist folgendermaßen aufgebaut: Am Anfang der
Konfigurationsdatei befinden sich einige allgemeingültige
Variablendefinitionen, die im wesentlichen Pfade und Programmnamen
betreffen. Wer sich näher dafür interessiert, wird in
man procmailrc sicher fündig werden.
Auf diesen "Kopfteil" folgen die eigentlichen Filterregeln, die von oben
nach unten abgearbeitet werden. Erfüllt eine Mail die gestellte
Bedingung, so wird die Bearbeitung beendet. Will man also eine Mail
mehrfach bearbeiten, so muß man zuerst eine Kopie der Mail erstellen
(siehe unten).
Eine Regel besteht aus einer Einleitungszeile und einer Aktionszeile, sieht
also z.B. so aus:
:0 c
| /bin/sed 1d | $BACKUP
Jede Einleitungszeile beginnt mit einem Doppelpunkt. Darauf
folgt immer eine Null, und danach optional weitere Zeichen. Das "
c"
der ersten Filterregel erstellt eine Kopie der Nachricht und arbeitet
dann mit dieser Kopie weiter. Auf diese Weise erzeugen wir ein Backup
jeder Mail (sinnvoll, solange man nicht sicher ist, ob das Mailsystem
vollständig korrekt konfiguriert ist).
"
e" sorgt dafür, daß diese Filterregel nur
ausgeführt wird, wenn die vorherige Filterregel mit einer
Fehlermeldung abgebrochen wurde. Auf diese Weise schützen wir uns
vor einem Mailverlust, denn das folgende
{ EXITCODE=75 HOST }
sorgt dafür, daß die Mail zurück in die Queue kommt.
Ohne diese Regel könnte die Mail verlorengehen!
Das "
w" schließlich läßt Procmail mit dem
Fortfahren auf den Exitcode des auszuführenden Filters/Programmes
warten - so ist sichergestellt, daß die Mail auch schon
von SpamAssassin geprüft wurde, bevor entschieden wird, wie sie
einsortiert wird.
Die Pipe (|) am Beginn einer Aktionszeile sorgt dafür, daß die
Mail umgeleitet wird. Bei der Überprüfung durch SpamAssassin
geschieht dies beispielsweise durch den Befehl
:0fw
| /usr/bin/spamc -u $LOGNAME
Er leitet die Mail weiter an das Programm
spamc, das Teil des
SpamAssassin ist. Durch das zusätzliche Flag "
f" in der
Einleitungszeile wird dafür gesorgt, daß die Mail
anschließend von Procmail weiter bearbeitet wird - andernfalls
sähe Procmail die Zustellung an dieser Stelle nämlich als
beendet an!
Durch Kombination der bislang genannten Optionen lassen sich fast alle
Filterregeln verstehen, nur eine wichtige fehlt noch:
:0
* ^X-Spam-Status: Yes
| /bin/sed 1d | /usr/bin/spamassassin -d | $SPAMIT
Hier ist die dritte Zeile die eigentliche Aktionszeile, die zweite Zeile
ist eine Bedingungszeile. Daß dem so ist, erkennt Procmail an dem
vorangestellten Sternchen (*). Danach folgt ein sogenannter
regulärer Ausdruck. Diese regulären Ausdrücke sorgen
in Filtern bei vielen Programmen für eine große Flexibilität
und viele verschiedene Filtermöglichkeiten - es gibt nahezu
nichts, was sich nicht mit regulären Ausdrücken darstellen
ließe.
An dieser Stelle handelt es sich aber nur um einen sehr einfachen
regulären Ausdruck, denn geprüft wird nur, ob die Mail die
Zeichenkette "X-Spam-Status: Yes" enthält (die einer Spam-Mail von
SpamAssassin hinzugefügt wurde). Zusätzlich muß diese
Zeichenkette am Anfang einer Zeile stehen, das signalisiert das "
^".
Enthält eine Filterregel eine Bedingungszeile, so wird die
Aktionszeile nur ausgeführt, falls die Bedingung erfüllt wurde!
Procmail bietet natürlich noch vielfältige Filtermöglichkeiten,
auf die ich an dieser Stelle aber nicht eingehen kann. Erste Anlaufstelle
für weitere Informationen sind die Manpages zu
procmail und
procmailrc. Auf die verwendeten Optionen der Programme
spamc und bogofilter werde ich an entsprechender Stelle in dieser Anleitung
noch näher eingehen.
Damit die Logdatei von Procmail nicht irgendwann überläuft, kann
man Logrotate dazu nutzen, um diese Datei in regelmäßen
Abständen zu löschen.
Dazu legt man einfach eine neue Datei
/etc/logrotate.d/procmail an,
die folgenden Inhalt besitzt:
/var/log/mail/procmail.log {
weekly
rotate 5
compress
missingok
}
-> Nach oben
Erste Vorsortierung mit Bogofilter
Bogofilter ist ein Spamfilter, der im Gegensatz zu SpamAssassin ausschließlich
auf der Bayes'schen Filtertechnologie beruht. Dabei handelt es sich um eine
Technik, die mit Hilfe von Wahrscheinlichkeiten und einer Art "künstlicher
Intelligenz" Vorhersagen darüber trifft, ob es sich bei einer Mail um
Spam handelt oder nicht. Mehr zum Bayes'schen Prinzip findet sich z.B. unter
http://support.gfi.com/manuals/de/me9/me9manual_de-1-05.html.
Sicher wird sich jetzt der eine oder andere fragen, warum man mit Bogomail
und SpamAssassin zwei Spamfilter auf einem System einsetzen sollte. Darauf
gibt es mehrere Antworten. Zum einen gilt auch hier das alte Sprichwort
"Zwei Augen sehen mehr als eines", d.h. SpamAssassin dient als zweite Absicherung
hinter Bogofilter. Spam-Mails, die durch die erste Überprüfung noch
hindurchgerutscht sind, werden höchstwahrscheinlich von der zweiten
Überprüfung erfaßt werden. Außerdem ist Bogofilter im
Gegensatz zu SpamAssassin nicht in Perl, sondern in C geschrieben. Damit ist
es deutlich ressourcenschonender als SpamAssassin, was sich bei vielen
zu prüfenden Mails auf älteren Systemen durchaus bemerkbar macht.
Leider ist Bogofilter in Debian Woody noch nicht enthalten. Es existiert aber
ein sogenannter "Backport" dafür, das ist ein Debian-Paket einer aktuellen
Bogofilter-Version, das speziell für Debian Woody erzeugt wurde.
Achtung: Debian "Stable" bedeutet, daß die einzelnen Pakete und ihr
Zusammenspiel von vielen Benutzern über einen längeren Zeitraum getestet und
für stabil befunden wurden. Installiert man Backports, so ist diese Stabilität
unter Umständen nicht mehr gewährleistet. Abstürze, ein "seltsames" Reagieren
des Systems oder auch Probleme beim Upgrade auf das nächste Debian-Release sind
nicht auszuschließen. Insbesondere weniger erfahrene (Debian-)Newbies oder
Betreiber von Produktiv-Servern sollten daher überlegen, ob sie wirklich einen
Backport installieren wollen.
Die Debian-Backports sind im allgemeinen aber von sehr guter Qualität und werden
meist auch von den Maintainern der Pakete erzeugt. Ich selbst habe mit den
Debian-Backports noch keinerlei negative Erfahrungen gemacht und halte sie für
stabiler als so manche Releases anderer Linux-Distributionen. Trotzdem sollte jeder
erst nach reiflicher Überlegung die Entscheidung für oder gegen einen Backport treffen!
Zur Installation des Bogofilter-Backports ist folgender zusätzliche Eintrag in der
Datei
/etc/apt/sources.list nötig:
deb http://www.ecology.uni-kiel.de/mirrors/debian/backports.org/debian stable bogofilter
Neben dem genannten existieren noch einige weitere Mirrors. Eine Liste aller Backport-Mirrors
findet sich unter
http://www.backports.org/mirrors.html.
Die eigentliche Installation erfolgt dann in typischer Debian-Manier mittels
apt-get update
apt-get install bogofilter
Nun gilt es, in der Datei
/etc/bogofilter.cf einige Einstellungen
zu treffen:
bogofilter_dir=~/.bogofilter
charset_default=iso-8859-15
Der Aufruf von Bogofilter erfolgt in der Datei
/etc/procmailrc. Die
verwendete Syntax
/usr/bin/bogofilter -u -e -p -l -d /home/$LOGNAME/.bogofilter/
bewirkt im Einzelnen folgendes:
-u Gefilterte Mails werden automatisch zum Lernen benutzt
-e Bogofilter wird immer mit dem Exitcode 0 beendet, es wird kein
Unterschied zwischen Ham und Spam getroffen
-p Es wird ein "X-Bogosity Header" eingefügt, der Auskunft
darüber gibt, ob eine Mail als Spam erkannt wurde
-l Aktionen werden ins Syslog geloggt
-d Der Pfad der zu verwendenden wordlist.db (die Datei, in der
Bogofilter Spam-Kriterien speichert). Da Bogofilter in der
/etc/procmailrc als "root" aufgerufen wird, die wordlist.db aber
userspezifisch bleiben soll, ist diese explizite Angabe
notwendig.
Damit Bogofilter korrekt zwischen Ham und Spam unterscheiden kann, muß
das Programm trainiert werden. Dazu kann z.B. eine vorhandene "Spam-Sammlung"
dienen. Folgendes kleine Skript kann die von SpamAssassin als Spam
klassifizierten Mails zum Training von Bogofilter benutzen. Das Skript
setzt voraus, daß die Home-Verzeichnisse der User mit
/home/User-Name benannt sind (Standardeinstellung); dies ist
gegebenenfalls anzupassen. Es wird als
/usr/local/bin/bogo_train
gespeichert:
#!/bin/sh
#
# /usr/local/bin/bogo_train
#
# Skript, um Bogofilter mittels von SpamAssassin ausgefilterten Spam-Mails
# zu trainieren; dabei werden nur Mails berücksichtigt, die innerhalb
# der letzten 24h modifiziert wurden. Dadurch wird eine Mehrfach-Klassifizierung
# ungelöschter älterer Spam-Mails verhindert.
#
for USER in $(ls /var/spool/cyrus/mail/user/)
do find /var/spool/cyrus/mail/user/$USER/SPAM \
-name \*. -ctime -1 -print | \
while read filename
do /usr/bin/bogofilter -d /home/$USER/.bogofilter/ -s < "$filename"
done
chown $USER /home/$USER/.bogofilter
chmod 666 /home/$USER/.bogofilter/wordlist.db
done
Anschließend wird die Datei noch ausführbar gemacht mittels
chmod 755 /usr/local/bin/bogo_train
Damit dieses Skript täglich ausgeführt wird, genügt unter Debian
ein Link in
/etc/cron.daily/. Er wird folgendermaßen angelegt:
ln -s /usr/local/bin/bogo_train /etc/cron.daily/
Alle von Bogofilter als Spam klassifizierten Mails werden zukünftig im
Ordner
INBOX/BogoSPAM abgelegt. Befindet sich dort eine falsch
klassifizierte Mail ("false positive"), so muß sie an den Befehl
/usr/bin/bogofilter -Sn übergeben werden. Für Anwender
des E-Mail-Programms Mutt beschreibe ich im entsprechenden Abschnitt eine komfortable
Lösung für dieses Vorgehen.
-> Nach oben
SpamAssassin filtert
Im vorletzten Schritt haben wir Procmail bereits für die Verwendung mit
SpamAssassin konfiguriert - jetzt gilt es, dieses SpamAssassin selbst
zu installieren und einzurichten. Dabei stellt sich unwillkürlich die
Frage "Was ist dieses SpamAssassin überhaupt?".
SpamAssassin ist ein Mail-Filter, der mit großer Sicherheit
unerwünschte Werbemails (sogenannten "Spam") erkennt und entsprechend
markiert. Die Beurteilung, ob eine Mail Spam ist oder nicht, wird anhand
mehrerer Kriterien gefällt. Für "spam-typische" Merkmale
(z.B. nur HTML, kein Absender, viele Frage- und Ausrufezeichen im Betreff etc.)
in der Mail werden Punkte verteilt, die am Ende summiert werden. Wird eine
(konfigurierbare) Höchstgrenze überschritten, so wird die Mail mit
einem entsprechenden Header als Spam markiert und kann so von Procmail
in die jeweilige Mailbox einsortiert werden.
Wer sich genauer für die einzelnen Tests interessiert, findet eine
Auflistung unter
http://www.spamassassin.org/tests.html
Wie immer, so müssen wir auch dieses Programm erst installieren,
bevor wir es nutzen können. Leider ist in Debian Woody nur das
vergleichsweise alte SpamAssassin 2.20 enthalten, das z.B. noch keinen
Bayes-Filter besitzt. Diese Version installiert man folgendermaßen:
apt-get install spamassassin
Es existieren allerdings Backports des aktuellen SpamAssassin für Debian
Woody.
Achtung: Debian "Stable" bedeutet, daß die einzelnen Pakete und ihr
Zusammenspiel von vielen Benutzern über einen längeren Zeitraum getestet und
für stabil befunden wurden. Installiert man Backports, so ist diese Stabilität
unter Umständen nicht mehr gewährleistet. Abstürze, ein "seltsames" Reagieren
des Systems oder auch Probleme beim Upgrade auf das nächste Debian-Release sind
nicht auszuschließen. Insbesondere weniger erfahrene (Debian-)Newbies oder
Betreiber von Produktiv-Servern sollten daher überlegen, ob sie wirklich einen
Backport installieren wollen.
Die Debian-Backports sind im allgemeinen aber von sehr guter Qualität und werden
meist auch von den Maintainern der Pakete erzeugt. Ich selbst habe mit den
Debian-Backports noch keinerlei negative Erfahrungen gemacht und halte sie für
stabiler als so manche Releases anderer Linux-Distributionen. Trotzdem sollte jeder
erst nach reiflicher Überlegung die Entscheidung für oder gegen einen Backport treffen!
Zur Installation des SpamAssassin-Backports ist folgender zusätzliche Eintrag in der
Datei
/etc/apt/sources.list nötig:
deb http://www.ecology.uni-kiel.de/mirrors/debian/backports.org/debian stable spamassassin
Neben dem genannten existieren noch einige weitere Mirrors. Eine Liste aller Backport-Mirrors
findet sich unter
http://www.backports.org/mirrors.html.
Die eigentliche Installation erfolgt dann in typischer Debian-Manier mittels
apt-get update
apt-get install spamassassin spamc
In der Datei
/etc/spamassassin/local.cf müssen folgende
Einstellungen getroffen werden:
bayes_file_mode 0777
report_safe 0
rewrite_subject 0
Aus Performancegründen ist es empfehlenswert, den spamd als Daemon
zu starten. Dazu paßt man die Datei
/etc/default/spamassassin
folgendermaßen an:
# /etc/default/spamd.conf
# Change to one to enable spamd
ENABLED=1
# Options
# See man spamd for possible options. The -d option is automatically added.
OPTIONS="-a -c -m 6"
Das Hinzufügen der Option
-m 6 bewirkt, daß nicht mehr
als 6 Instanzen gleichzeitig gestartet werden. Damit verhindert man eine
Überlastung des Servers, schafft aber auch gleichzeitig eine
Engstelle. Denn damit wird die Zahl der gleichzeitig bearbeiteten Mails
ebenfalls auf 6 beschränkt - zu wenig für Systeme mit einem
sehr großen Mailumsatz.
Wer über einen entsprechend dimensionierten Server verfügt und
einen großen Maildurchgang hat, kann diese Zahl auch deutlich höher
setzen - wie hoch, kann wohl nur durch Tests ermittelt werden.
Der Parameter "
-a" bewirkt etwas anderes: Absender werden aufgrund
der von ihnen in der Vergangenheit bereits verschickten Mails bewertet und
somit automatisch auf eine sogenannte "Whitelist" gesetzt. D.h. wenn uns
ein Freund viele Mails schickt, die von SpamAssassin nicht als Spam
bewertet wurden, so wird auch ein "Ausrutscher" (z.B. eine HTML-Mail mit
"Signalwörtern") als "Nicht-Spam" bewertet und durchgelassen.
Eine solche Whitelist läßt sich natürlich nicht nur
automatisch erzeugen, sondern man kann auch von Hand Adressen eintragen.
Dazu erzeugt man zuerst (als User!) eine entsprechende Vorlagendatei, indem
man einfach
spamassassin
ohne Parameter aufruft und sofort wieder mit <Strg+d> beendet. Nun existiert
eine Datei
~/.spamassassin/user_prefs und kann den eigenen
Wünschen angepaßt werden.
Eine Adresse fügt man mit einem solchen Eintrag der Whitelist hinzu:
whitelist_from mein-bester-freund@isp.de
Natürlich kann man umgekehrt auch Mails auf eine Blacklist setzen:
blacklist_from boeser-mensch@anderer-isp.de
Ebenfalls in der Datei
~/.spamassassin/user_prefs stellt man ein,
ab welcher Punktzahl eine Mail als Spam eingestuft wird. Die Voreinstellung
required_hits 5
ist durchaus sinnvoll gewählt und sollte nur geändert werden, wenn
zu viele Mails falsch eingestuft werden.
Wurde eine Mail zu Unrecht als Spam eingestuft, so läßt sich dies
folgendermaßen rückgängig machen: Man speichert die Mail
in eine Datei (z.B. in mutt mit Druck auf "
s"). Dann ruft man
SpamAssassin auf mit dem Befehl
spamassassin -W < Datei-ohne-Spam
Die Mail läßt sich dann mit dem Befehl
spamassassin -d < Datei-ohne-Spam > Mail-ohne-Markierung
in einer neuen Datei ohne Spam-Markierung speichern.
Auch eine unerkannte Spam-Mail kann man dem Programm zeigen
(SpamAssassin ist lernfähig) und einen
Spam-Report erstellen; dies geschieht mit
spamassassin -rR < Datei-mit-Spam
Der Bayes-Filter von SpamAssassin >=2.5x kann mit dem Programm
sa-learn trainiert werden. Bei der Ausführung von
spamassassin -r geschieht dies automatisch;
ausgehend von der oben angelegten
Datei-mit-Spam kann man es allerdings auch per Hand
starten:
sa-learn --spam --single < Datei-mit-Spam
Wer mehrere Mails in einer Datei speichert (meist im mbox-Format), kann
diese Mails folgendermaßen als Spam erkennen lassen:
sa-learn --spam --mbox Datei-mit-viel-Spam
Der Parameter "--single" fällt dann weg, da mehr als eine Nachricht
erkannt werden sollen.
Im Gegensatz zum "bösen Spam" gibt es bei SpamAssassin auch den
"guten Ham", d.h. Mails, die eben nicht als Spam erkannt sondern
unbehelligt weitergeleitet werden sollen.
Auch das Erkennen von "Ham" kann man mit
sa-learn trainieren,
dies geschieht analog zum Spam-Training mit den Befehlen
sa-learn --ham --single < Datei-ohne-Spam
sa-learn --ham --mbox Datei-mit-vielen-guten-Mails
Je mehr trainiert wird, desto besser und zuverlässiger werden
natürlich die Erkennungsraten. Mehr zu dem Thema findet sich
übrigens in der Manpage zu
sa-learn.
Hinweis: Die hier aufgeführten Befehle müssen auf dem
Server ausgeführt werden,
d.h. eventuell muß die E-Mail erst vom
Client auf den Server kopiert werden (z.B. mit
scp).
SpamAssassin ist sicher nicht unfehlbar, und gerade E-Mails von Ebay und
Amazon.de werden gerne mal irrtümlich als Spam eingestuft. Aber das
Programm hat doch eine sehr geringe Zahl an false positives (zu Unrecht
als Spam eingestufte Mails) und hilft dabei, die eigene Mailbox frei
von Werbemails zu halten. Ich möchte nicht mehr darauf verzichten!
Übrigens setzt jetzt mit GMX auch ein großer E-Mail-Provider
SpamAssassin ein - sehr zur Freude seiner Nutzer!
Noch einige Worte zur Erläuterung der SpamAssassin-Aufrufe in der
/etc/procmailrc: Der Befehl
/usr/bin/spamc -u $LOGNAME
bewirkt, daß für die Überprüfung der Mail die
Konfigurationsdateien des jeweiligen Users verwendet werden sollen. Damit
kann ein userspezifischer Bayes-Filter effektiv trainiert und genutzt
werden.
Die Zustellung einer von SpamAssassin als "Spam" klassifizierten Mail erfolgt
mittels des Befehls
/bin/sed 1d | /usr/bin/spamassassin -d | $SPAMIT.
Durch die Option
-d werden die von SpamAssassin hinzugefügten
Zusatzinformationen wieder aus der Mail entfernt. Dies ist nötig, damit
Bogofilter beim Lernen dieser Mails nicht fälschlicherweise die
SpamAssassin-Markierungen als typische Spam-Merkmale bemerkt.
-> Nach oben
Das Kernstück - Cyrus verwaltet
Wir haben unseren E-Mail-Server jetzt fast fertig eingerichtet, aber
das eigentliche Kernstück - der IMAP-Server - fehlt
noch. Das Wichtigste kommt schließlich immer am Schluß... ;-)
Wer Cyrus aus den Sourcen installieren möchte, findet dazu eine
gute Anleitung auf der offiziellen
Cyrus-Homepage unter
Cyrus IMAP Installation (http://en.tldp.org/HOWTO/Cyrus-IMAP-6.html).
In Debian ist Cyrus auf verschiedene Pakete verteilt, deshalb erfordert
die Installation einen etwas längeren Befehl:
apt-get install cyrus-admin cyrus-common cyrus-imapd
Die Installationsroutine hat uns bereits daraufhingewiesen - wir
müssen in der
/etc/imapd.conf noch einen Administrator für
den Mailserver eintragen. Üblicherweise wählt man dazu den
User cyrus. Dazu trägt man folgendes ein:
(...)
# Uncomment the following and add the space-separated users who
# have admin rights
admins: cyrus
(...)
Nun muß man dem User cyrus nur noch ein Paßwort zuweisen:
passwd cyrus
Damit ist der Cyrus-IMAP-Server eigentlich schon fertig eingerichtet, jetzt
geht es nur noch um die Userverwaltung. Am einfachsten nutzt man dazu
die lokale Userverwaltung des Systems mit
/etc/passwd und
/etc/shadow, d.h. jeder IMAP-User muß
zuerst als User auf dem Server angelegt werden. Der passende Befehl
dazu lautet unter Debian:
useradd -m test-user
passwd test-user
Die Mailboxen der Cyrus-User werden mit dem Programm
cyradm
verwaltet. Das Programm kennt u.a. folgende Befehle:
cm Erzeugt eine neue Mailbox
lm Listet Mailboxen auf, Wildcards sind erlaubt
dm Löscht eine Mailbox und alle darunterliegenden Mailboxen
renm Umbenennen einer Mailbox
lam Listet die Zugriffskontrollen einer Mailbox auf
sam Hinzufügen von Zugriffsrechten auf eine Mailbox
dam Löschen von Zugriffsrechten auf eine Mailbox
sq Setzen von Quota-Limits
lq Zeigt die Quotas für eine Mailbox an
lqr Zeigt die Quotas für eine Toplevel-Mailbox an
help Zeigt eine Hilfe aller Befehle an
quit Beendet das Programm
Unserem frisch erstellten User "
test-user" verschaffen wir
folgendermaßen einen IMAP-Account:
mailserver:~# cyradm -user cyrus localhost
localhost password:
localhost> cm user.test-user
Wichtig: Die Mailboxstruktur von Cyrus ist hierarchisch gegliedert,
das Trennzeichen zwischen den Hierarchien ist der Punkt. Es ist eine
Konvention, daß alle User-Mailboxen unterhalb von "user" liegen, d.h.
die Toplevel-Mailbox des Users "test-user" heißt "user.test-user".
Daher darf ein Ordnername keinen Punkt enthalten, da dieser sofort als
Hierarchietrennzeichen interpretiert wird!
In unserem Procmail-Skript haben wir die Unterordner "Backup" und "SPAM"
benutzt, also sollten wir sie auch anlegen. Außerdem sind ein paar
weitere Ordner immer sinnvoll:
localhost> cm user.test-user.Backup
localhost> cm user.test-user.BogoSPAM
localhost> cm user.test-user.GMX-SPAM
localhost> cm user.test-user.SPAM
localhost> cm user.test-user.Gesendete_Nachrichten
localhost> cm user.test-user.Entwuerfe
Ob das Anlegen der Ordner erfolgreich war, zeigt das Kommando "
lm":
localhost> lm
user.test-user user.test-user.Gesendete_Nachrichten
user.test-user.Backup user.test-user.GMX-SPAM
user.test-user.BogoSPAM user.test-user.SPAM
user.test-user.Entwuerfe
Manch einer wird sich fragen, warum man denn drei verschiedene Ordner für Spam
anlegen muß. Das ist bei dieser Art der Installation allerdings nötig,
um die verschiendenen Programme korrekt zu trainieren. Dabei landet im Ordner
INBOX/GMX-SPAM aller Spam, der schon von GMX markiert wurde. Befinden
sich in diesem Ordner "false positives", so ist die Whitelist direkt bei GMX zu
bearbeiten.
Im Ordner
INBOX/BogoSPAM landet alles, was von Bogofilter
als Spam markiert wurde; "false positives" in diesem Ordner müssen bei
Bogofilter korrigiert werden (Übergabe des Mailtextes an Bogofilter mit
den Optionen
/usr/bin/bogofilter -Sn).
INBOX/SPAM ist schließlich der Ablageort von Mails, die
SpamAssassin als Spam klassifiziert hat, die Bogofilter aber als Ham oder
als unklar beurteilt hat. Das oben erwähnte Skript
/usr/local/bin/bogo_train
sorgt dafür, daß diese Mails Bogofilter explizit als "Spam" vorgestellt
werden. Befinden sich in diesem Ordner "false positives", so sind sie sowohl bei
Bogofilter (mittels
/usr/bin/bogofilter -Sn) als auch bei SpamAssassin
(mittels
/usr/bin/sa-learn --ham --single) als Ham zu klassifizieren!
Zurück zu Cyrus: Einen User zu löschen ist nicht ganz so einfach, wie ihn anzulegen.
Denn aus Sicherheitsgründen ist der Befehl "
dm" ersteinmal
gesperrt, es fehlt (auch dem Administrator!) das entsprechende
Zugriffsrecht ("
d").
Folgendermaßen kann die Mailbox eines Users doch gelöscht werden:
localhost> sam user.test-user cyrus d
localhost> dm user.test-user
localhost> lm
localhost>
Der abschließe Befehl "
lm" beweist, daß die Mailbox des Users
"test-user" wieder gelöscht wurde, und mit ihr alle Unterordner.
Mit Hilfe der Cyrus-Zugriffsrechte sind vielseitige Zugriffskontrollen
möglich, die aber den Umfang dieser Anleitung sprengen würden.
Weiterführendes dazu findet sich u.a. auf der
Cyrus-Homepage (http://asg.web.cmu.edu/cyrus/imapd/) oder im
Artikel
IMAP Emailserver unter Linux (http://www.linux-tin.org/tin.german/setupguide/server/suse/html/mailserver.htm).
-> Nach oben
Clientkonfiguration
Exim auf den Clientrechnern
Unser Mailserver dient als Mailsausgangsserver (SMTP-Server) für
unser lokales Netzwerk. D.h. in allen E-Mail-Programmen sollten für
den SMTP-Server diese Einstellungen vorgenommen werden:
Servername: 192.168.1.1 (bzw. die IP-Adresse des Servers)
Port: 25
Protokoll: SMTP
Manche Programme (z.B. Mutt) erfordern allerdings einen lokalen
SMTP-Server auf jedem Clientrechner im Netzwerk. Deshalb müssen
wir auf jedem dieser Rechner Exim so konfigurieren, daß es die
Mails annimmt und an den zentralen Mailserver weiterleitet.
Mit Hilfe von
eximconfig ist dies schnell geschehen:
Select a number from 1 to 5, from the list above.
Diesmal ist "
3" zu wählen (
Satellite system).
What is this system's name?
Hier muß der Name des Servers eingetragen werden, also z.B.
client1.meine-domain.de
Where will your users read their mail?
Diesmal geht es darum, auf welchem System die User ihre Mails lesen. Dies
geschieht per IMAP auf dem lokalen Mailserver, deshalb sollte man hier
mailserver.meine-domain.de angeben.
Which machine will act as the smarthost and handle outgoing mail?
Alle unsere Mails sollen über unseren lokalen Mailserver verschickt
werden, also tragen wir das auch ein:
mailserver.meine-domain.de
Which user account(s) should system administrator mail go to?
Da man unter Linux aus Sicherheitsgründen nie als root arbeiten sollte,
können alle Mails, die für root bestimmt sind, an einen lokalen Benutzer
weitergeleitet werden. Hier sollte man den eigenen User-Account angeben, also
z.B. lokaler-benutzername
In der abschließenden Übersicht prüft man noch einmal die
getätigten Einstellungen und bestätigt dann mit
Y
Damit man als lokaler User mit Mutt Mails mit einer beliebigen
Absender-Adresse im Envelope-From verschicken kann, muß
zusätzlich zur entsprechenden Option in der
~/.muttrc (siehe
unten) noch in der
/etc/exim/exim.conf folgende Option
ergänzt werden:
trusted_users = mail : lokaler-benutzername
Wer die Absenderadresse nicht von Mutt setzen lassen will, kann auch
das "Address Rewriting" von Exim dazu nutzen. Es ist standardmäß
bereits eingeschaltet, nötig ist nur noch ein entsprechender
Eintrag in der Datei
/etc/email-addresses
Ein solcher Eintrag hat folgende Form:
lokaler-benutzername: meine-externe-email@isp.de
-> Nach oben
Mutt - ein Beispiel für einen IMAP-Client
Es gibt unzählige IMAP-fähige E-Mail-Clients für die
verschiedenen Betriebssysteme. Für Windows zu nennen sind z.B.
Pegasus und Netscape/Mozilla, unter Linux verbreitet sind KMail, Sylpheed
oder Evolution.
Gemein haben diese E-Mail-Programme, daß sie aufgrund eines großen
Funktionsumfangs mehr oder weniger stark aufgebläht erscheinen und
außerdem (unter Linux) einen laufenden X-Server benötigen.
Daher habe ich mich für einen anderen E-Mail-Client entschieden, der
auf der Textkonsole läuft und nach kurzer Einarbeitungszeit mindestens
genauso komfortabel (wenn nicht sogar deutlich schneller) zu bedienen
ist: Mutt.
Bevor ich nun beschreibe, wie Mutt für die Verwendung mit einem
IMAP-Server einzurichten ist, hier kurz ein Überblick über die
Einstellungen, die in einem der üblichen Mailprogramme (meist in
einer Dialogbox) vorgenommen werden müssen:
Servername: 192.168.1.1 (bzw. die IP-Adresse des Servers)
Port: 143
Protokoll: IMAP
Benutzername: lokaler Username auf dem Server
Passwort: Passwort des lokalen Users auf dem Server
Die Konfiguration von Mutt geschieht zum größten Teil in der
Datei
.muttrc im Home-Verzeichnis des jeweiligen Users. Die Datei
bietet vielfältige Möglichkeiten, um das Aussehen und Verhalten
des Programmes an die individuellen Vorlieben anzupassen. Eine komplette
Einführung in Mutt würde aber den Rahmen dieser Anleitung sprengen,
ich werde nur auf die (speziell für IMAP) wichtigsten Optionen eingehen.
Meine
~/.muttrc sieht folgendermaßen aus:
# Persönliche Daten festlegen
set from = "meine_email@isp.de"
set realname = "Mein Name"
my_hdr Priority: normal
# From benutzen
set use_from
# Mein Hostname ist "inkorrekt"
set hidden_host = yes
# Envelope From setzen, da sonst von Exim der lokale Username gesetzt wird
set envelope_from
# Geantwortet wird immer mit der Adresse, an die die Mail ging
set reverse_name
set reverse_realname
# Bekannte E-Mail-Adressen durch den Alias ersetzen
set reverse_alias
# Für den Euro anpassen
set charset=iso-8859-15
set send_charset="us-ascii:iso-8859-15:iso-8859-1:utf-8"
# Meine E-Mail-Adressen
set alternates="^(e-mail1@isp1\.de|e-mail2@isp2\.com|e-mail3@isp3\.net)$"
# Adressbuch (alias-File) einbinden
source ~/.mail_aliases
set alias_file=~/.mail_aliases
# $folder auf das IMAP-Rootverzeichnis setzen
set folder=imap://192.168.1.1/
# IMAP-Inbox als Spoolfile benutzen
set spoolfile=imap://192.168.1.1/INBOX
# Mailboxen für neue Mails setzen
mailboxes /var/mail/$USER +INBOX
# IMAP-UserID festlegen
set imap_user="Benutzername"
# IMAP-Paßwort festlegen
set imap_pass="Passwort"
# gelesene Mails in der Inbox belassen
set move=no
# Editor festlegen
set editor="/usr/bin/vim"
# einzelne Tasten anpassen
bind index home first-entry
bind index end last-entry
bind pager home top
bind pager end bottom
bind browser home first-entry
bind browser end last-entry
bind index B bounce-message
bind pager B bounce-message
bind pager b previous-page
bind index G imap-fetch-mail
bind pager G imap-fetch-mail
bind pager h display-toggle-weed
bind editor TAB complete
bind editor ^Space buffy-cycle
# Mails bei Bogofilter als "Spam" klassifizieren
macro index N "|ssh 192.168.1.1 /usr/bin/bogofilter -Ns -v"
# Mails bei Bogofilter als "Ham" klassifizieren
# (die Erkennung von "false positives korrigieren)
macro index w "|ssh 192.168.1.1 /usr/bin/bogofilter -Sn -v"
# Für eine einwandfreie Weitergabe der Mail an Bogofilter notwendig
unset pipe_decode
# Bequem Spam-Mails per Tastendruck an SpamAssassin auf
# dem Server reporten; setzt ein installiertes ssh voraus
macro index S "| ssh 192.168.1.1 /usr/bin/sa-learn --spam --single"
#
# Mails als "Ham" klassifizieren
macro index H "| ssh 192.168.1.1 /usr/bin/sa-learn --ham --no-rebuild --single"
#
# Mails zur Whitelist hinzufügen
macro index W "| ssh 192.168.1.1 /usr/bin/spamassassin -W"
#
# Datenbank des Bayes-Filters neu erzeugen
macro index R "| ssh 192.168.1.1 /usr/bin/sa-learn --rebuild"
# Threading einschalten
set sort=threads
# Gesendete Mails speichern
set record=+INBOX/Gesendete_Nachrichten
# Immer eine Kopie von geschriebenen Mails behalten
set copy=yes
# Mailfolder für unvollendete Nachrichten festlegen
set postponed=+INBOX/Entwuerfe
# Nachrichten auch ohne Betreff möglich
set abort_nosubject=no
# Geteilte Ansicht einschalten (10 Zeilen für den Pager)
set pager_index_lines=10
# Menu-Scroll aktivieren
set menu_scroll
# MIME auto-view
auto_view text/html image/gif image/jpg
# Falls vorhanden, immer den Reply-To nutzen
set reply_to
# Festlegen, welche Header angezeigt werden sollen
# Erstmal alles _nicht_ anzeigen:
ignore *
# Aber die hier will ich sehen:
unignore from: subject to cc mail-followup-to date \
x-mailer user-agent reply-to
# Anzeigereihenfolge der Header festlegen
unhdr_order *
hdr_order date from subject to cc mail-followup-to \
reply-to user-agent x-mailer
Die meisten der Einstellungen in dieser Konfigurationsdatei sollten
selbsterklärend sein, auf die für IMAP bedeutsamen gehe ich im
folgenden kurz ein.
Wer sich näher mit allen hier vorgestellten Optionen beschäftigen
will, wird in der Mutt-Manpage sowie in den unter
Quellen und weiterführende Links genannten Seiten
fündig werden.
Mit den Befehlen
set folder=imap://192.168.1.1/ und
set spoolfile=imap://192.168.1.1/INBOX legt man fest, wie die
Default-Mailbox heißt. In diesem Fall wird über IMAP zugegriffen
(daher "
imap://"), und die Mailbox liegt auf dem Server "
192.168.1.1".
Der Zugriff auf das IMAP-Postfach ist natürlich mit einem Passwort
geschützt, daher muß Mutt noch gesagt werden, mit welchem
Benutzernamen und welchem Passwort man sich am IMAP-Server anmelden will.
Dazu dienen die Optionen
set imap_user="Benutzername" und
set imap_pass="Passwort" (natürlich entsprechend anzupassen!).
Der Befehl
mailboxes /var/mail/$USER +INBOX bewirkt, daß nicht
nur in der INBOX auf dem IMAP-Server, sondern auch im lokalen Mailspool auf
dem Client-Rechner nach neuen Nachrichten gesucht wird. Denn hier kann
z.B. ein Logfile eines Cron-Jobs landen, und das soll schließlich nicht
völlig unbemerkt geschehen.
Ein Druck auf die Taste "
G" frischt die Ansicht des IMAP-Ordners auf,
in der Zwischenzeit eventuell eintroffene Nachrichten werden danach auch
angezeigt. Damit dieses Verhalten funktioniert, sind die beiden Einträge
bind index G imap-fetch-mail und
bind pager G imap-fetch-mail
nötig.
Sofern der eigene Username in der lokalen Exim-Konfiguration zu den
"Trusted Users" hinzugefügt wurde, ist auch noch die Option
set envelope_from von Bedeutung. Damit wird die Absenderadresse als
Envelope-From gesetzt und nicht von Exim mit dem lokalen Usernamen
(User@localhost) bzw. einer (statischen) Rewrite-Rule überschrieben.
Wichtig ist dies insbesondere, wenn man mehrere verschiedene E-Mail-Adressen
nutzt, die man alle unter einem User-Account verwenden will.
Zur besseren Integration von SpamAssassin habe ich einige
macro-Kommandos
gesetzt, die das Melden von Spam bzw. Ham per einfachem Tastendruck
erlauben. Die Befehle sind entsprechend kommentiert, bei Fragen helfen die
jeweiligen Manpages weiter.
Die restlichen von mir gesetzten Optionen sind hauptsächlich optischer
Natur, ein Blick in
man muttrc sollte bei Interesse für
Erklärung sorgen.
-> Nach oben
Quellen und weiterführende Links
-> Nach oben
