News |
Buchempfehlungen |
Links |
Computerspiele |
CD-R/DVD±R(W)
FreeBSD |
NetBSD |
Linux |
Kursfahrt 2000 |
Medizinstudium
Schule |
Über mich |
Impressum |
Feedback |
Übersicht
|
Übersicht |
| Installation von NetBSD 1.6.2 |
| Installation von NetBSD 2.0 |
| IMAP-Server |
| anacron |
|
IMAP E-Mail-Server unter NetBSD einrichtenInhalt
Worum geht es überhaupt?Diese Anleitung beschreibt die Einrichtung eines IMAP E-Mail-Servers für ein kleines Netzwerk unter NetBSD 2.0 (http://www.netbsd.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. Wer noch keine Erfahrungen mit NetBSD hat, sich aber einmal an dieses sehr flexible und hochportable Betriebssystem heranwagen möchte, für den ist vielleicht die Anleitung NetBSD: Installation und Grundkonfiguration (http://home.arcor.de/hm-gerhards/netbsd/netbsd_install.html) hilfreich. Durch den Verzicht auf spezielle Konfigurationsprogramme (die es unter NetBSD ohnehin nicht gibt) und die Beschreibung der Konfigurationsdateien sollte der in dieser Anleitung beschriebene Aufbau eines IMAP E-Mail-Servers aber ohne größere Probleme mit kleinen Anpassungen (z.B. die jeweiligen Programmpfade) auch unter z.B. FreeBSD oder jeder aktuellen Linux-Distribution umgesetzt werden können. 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!
Weiterhin wird vorausgesetzt, daß die NetBSD-Package-Collection ( pkgsrc) korrekt installiert ist.
-> Nach oben Eingesetzte SoftwareBogofilter 0.92.8 (http://sourceforge.net/projects/bogofilter/)Cyrus 2.2.12 (http://asg.web.cmu.edu/cyrus/imapd/) Exim 4.44 (http://www.exim.org) Fetchmail 6.2.5 (http://www.catb.org/~esr/fetchmail) Procmail 3.22 (http://www.procmail.org) SpamAssassin 3.0.3 (http://www.spamassassin.org) Anacron 2.3 -> Nach oben ServerkonfigurationMails abholen mit FetchmailGanz 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.NetBSD-typisch ist die Installation aber mit einem einfachen Befehl geschehen: root@host:~> cd /usr/pkgsrc/mail/fetchmail root@host:/usr/pkgsrc/mail/fetchmail> make installAls nächtes muß das Beispiel-Startskript für den Fetchmail-Daemon an die richtige Stelle kopiert werden: root@host:~> cp /usr/pkg/share/examples/rc.d/fetchmail /etc/rc.d/Folgender Eintrag in der globalen Konfigurationsdatei /etc/rc.conf dient
dazu, Fetchmail bei jedem Systemstart automatisch zu starten:
# Fetchmail starten fetchmail=YESJetzt muß man Fetchmail noch sagen, wo es die Mails abholen soll. Dies erfolgt unter NetBSD in der Konfigurationsdatei /usr/pkg/etc/fetchmail.conf. Diese Datei existiert nicht, sondern
muß neu angelegt werden. Dies geschieht mit folgenden Befehlen, mit denen
wir auch gleich die richtigen Rechte setzen und das Logverzeichnis für
Fetchmail anlegen:root@host:~> touch /usr/pkg/etc/fetchmail.conf root@host:~> chmod 600 /usr/pkg/etc/fetchmail.conf root@host:~> mkdir /var/log/mail root@host:~> chown root.mail /var/log/mailEine Beispieldatei könnte so aussehen: set daemon 600 set logfile /var/log/mail/fetchmail.log set no bouncemail poll pop.Mein-Provider.de protocol POP3 \ user "Mein-Benutzername" password "Mein-Passwort" is "lokaler-benutzername" fetchallDie Angaben für den POP3-Server, Benutzernamen und Paßwort sowie der lokale Benutzername sind natürlich entsprechend anzupassen. Die Angabe set daemon 600 führt dazu, daß Fetchmail als Daemon
gestartet wird und alle 10 Minuten (=600 Sekunden) nach neuen Mails schaut. Wem dieses
Intervall zu kurz gewählt ist, der kann diesen Wert natürlich durch eine größere
Zahl ersetzen.
Wenn die komplette Konfiguration des Mailservers abgeschlossen ist, kann Fetchmail dann mit dem Befehl root@host:~> /etc/rc.d/fetchmail startgestartet werden. Alternativ geschieht dies auch automatisch mit dem nächsten Systemstart. Die Option fetchall in der Konfigurationsdatei sorgt dafür, daß alle
Mails von diesem Account heruntergeladen werden. Um beim anfänglichen
Testen des neuen Servers keinen Verlust wichtiger Mails zu riskieren, empfiehlt
es sich, die Option fetchall zumindest während der
Testperiode durch die Option keep zu ersetzen. Dann werden alle
neuen Mails zwar über POP3 abgerufen, aber auf dem Server belassen.
Damit die Logdatei von Fetchmail nicht immer weiterwächst, empfiehlt es sich, sie in regelmäßen Abständen zu "rotieren". Dafür kann man unter NetBSD z.B. das Programm Newsyslog verwenden, näheres dazu im Abschnitt Nacharbeiten - Logfile-Rotation mit newsyslog einrichten. 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 weiterAllgemeine KonfigurationFetchmail hat unsere Mails abgeholt, nun müssen sie weiterverteilt werden. Die nächste Station auf dem Weg ist der lokale Mailserver. Bei NetBSD ist das standardmäßig Sendmail, dessen Konfiguration aber relativ kryptisch ist. Daher bevorzuge ich Exim, das sich durch eine relativ leicht verständliche Konfigurationsdatei und gleichzeitig sehr große Flexibilität auszeichnet.Zur Installation von Exim sind folgende Schritte nötig: root@host:~> cd /usr/pkgsrc/mail/exim/ root@host:/usr/pkgsrc/mail/exim> make installNun befindet sich Exim auf der Festplatte, noch läuft allerdings der Sendmail-Daemon der Standardinstallation. Bevor dieser endgültig durch Exim ersetzt werden kann, müssen erst noch einige Einstellungen in der Exim-Konfigurationsdateit /usr/pkg/etc/exim/configure vorgenommen werden.
Dazu vorab ein paar Worte zum Aufbau der Exim-Konfigurationsdatei. Die Datei ist in mehrere thematisch zusammengehörige Abschnitte unterteilt, wobei jeder Abschnitt (mit Ausnahme des ersten) mit dem Schlüsselwort begin eingeleitet wird. Kommentarzeilen beginnen wie üblich mit einer
#.
Ich werde im folgenden die einzelnen Abschnitte anhand meiner ausführlich kommentierten Konfigurationsdatei vorstellen und die für mein Setup relevanten Optionen dabei erwähnen. Mit Exim läßt sich allerdings noch sehr viel mehr verwirklichen, als ich an dieser Stelle darstellen kann. Alle weiteren Optionen sind aber im ausführlichen Exim-Handbuch unter http://www.exim.org/exim-html-4.40/doc/html/ sehr gut beschrieben, auf das ich alle Interessierten verweisen möchte. Zuerst jetzt also ein Blick auf die "allgemeinen" Optionen, den MAIN CONFIGURATION SETTINGS, die am Anfang der Konfigurationsdatei stehen:
###################################################################### # MAIN CONFIGURATION SETTINGS # ###################################################################### # Der primary_hostname ist der sogenannte FQDN des Systems, d.h. der # komplette Name, wie er nach aussen sichtbar ist. Aufgebaut ist er # nach dem Muster rechnername.domain.tld # Wer keine eigene Domain registriert hat, kann auch z.B. bei # DynDNS (http://www.dyndns.org) kostenlos eine Subdomain nutzen. # Der entsprechende FQDN lautet dann z.B. rechnername.subdomain.dyndns.org # primary_hostname = lokaler-server.subdomain.dyndns.org # Hier werden die lokalen Domains angegeben, d.h. alle Adressen, fuer # die Mails angenommen und lokal zugestellt werden. Die Angabe "@" # ist gleichbedeutend mit dem "primary_hostname" # domainlist local_domains = @ # Wer seinen Server als Relay fuer eine andere Domain konfigurieren # moechte, fuer den ist diese Option wichtig. Alle anderen sollten # hier auf keinen Fall irgendetwas eintragen, da der Rechner sonst als # sogenanntes offenes Relay von Spammern missbraucht werden koennte! # domainlist relay_to_domains = # In diesem Beispiel soll der zentrale Mailserver alle Mails aus dem lokalen # Netz (Adressen nach dem Muster 192.168.1.x) annehmen und ins Internet # weiterverteilen. # hostlist relay_from_hosts = 127.0.0.1 : 192.168.1.0/24 # Eine sogenannte "unqualified address" ist eine Mailadresse, die hinter dem # Benutzernamen kein "@domain" besitzt. Exim mag das nicht, und so sollte # diese Option entsprechend dem FQDN des Rechners gesetzt werden, auch wenn # der Versand in diesem Beispiel mit voellig anderen Absender-Adressen # (z.B. von GMX oder Arcor) erfolgen wird. # qualify_domain = lokaler-server.subdomain.dyndns.org # Um Verzoegerungen zu vermeiden, wenn kein Nameserver verfuegbar ist (weil # der Server z.B. offline ist), empfiehlt sich folgende Einstellung, bei # der die DNS-Lookups abgeschaltet werden # host_lookup = # Hier gilt aehnliches wie beim letzten Punkt; um Verzoegerungen und # Probleme durch Firewalls zu vermeiden, wird in diesem Beispiel die # Nutzung des ident-Dienstes (RFC1413) durch Exim abgeschaltet # rfc1413_hosts = rfc1413_query_timeout = 0s # Mailclients, die ihre Mails nicht ueber SMTP an den lokalen MTA ausliefern, # sondern dazu den Alias /usr/sbin/sendmail verwenden, duerfen normalerweise # die Absenderadresse nicht frei waehlen. Stattdessen wird # benutzername@fqdn als Absender gesetzt und evtl. noch entsprechend den # gesetzten Filterregeln umgeschrieben. # Wer aber Mailprovider wie z.B. GMX oder Arcor nutzt, wird auch seine dortige # Adresse als Absender angeben wollen. Dazu dient folgende Option, die es # allen Benutzern erlaubt, beliebige Absender-Adressen zu verwenden. # untrusted_set_sender = * # Als "lokal" werden die Interfaces bezeichnet, auf denen Exim Mail entgegen- # nehmen und ohne Beschraenkung weiterverteilen soll. Dazu gehoert immer die # Adresse 127.0.0.1 fuer "localhost", sowie in diesem Beispiel die Adresse # 192.168.1.9, mit der der Server im lokalen Netzwerk erreichbar ist. # local_interfaces = 127.0.0.1 : 192.168.1.9 # Wer einen eher schwachbruestigen Rechner als Server einsetzt, der kann # unter Umstaenden Probleme mit dem grossen Speicherhunger von SpamAssassin # bekommen. Abhilfe schaffen koennen diese Eintraege, 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 # Die wenigsten Privatrechner werden ueber eine Standleitung ans Internet # angebunden. Meistens ist der Zugang in DialUp-Form realisiert, so dass keine # staendige Online-Verbindung besteht. Um E-Mails nach "draussen" ersteinmal # zwischenzuspeichern und keine direkte Zustellung zu versuchen, kann die # naechste Option gesetzt werden. # Die eigentliche Zustellung kann dann z.B. durch einen Cronjob erfolgen, der # feststellt, ob der Rechner online ist und dann gegebenenfalls ein "exim -q" # ausloest; alternativ kann auch in der Datei /etc/ppp/ip-up ein "exim -q" # aufgerufen werden. # # queue_smtp_domains = * # Einige Mail-Clients (z.B. Pegasus 3.x) senden im EHLO ungueltige Zeichen. # Um die Verbindung trotzdem zu erlauben und ein Senden von Mails auch mit # diesen Clients zu ermoeglichen, wird die folgende Option gesetzt. # helo_accept_junk_hosts = *Der nächste Abschnitt der Exim-Konfigurationsdatei beschäftigt sich mit den sogenannten ACLs, den Access Control Lists. Hiermit kann man festlegen,
wie mit eingehenden Mails verfahren werden soll. Es handelt sich dabei um
Sicherheitsrichtlinien, mit denen man (grob gesagt) bestimmt, welche Mails angenommen
und welche abgewiesen werden. Für ein Standardsystem sollten die Vorgaben sehr gut
ihren Dienst tun. Wer mehr benötigt, arbeitet sich am besten in die gute
Dokumentation dazu ein.
Für das Relaying von Mails aus dem lokalen Netz heraus ist insbesondere die Option accept hosts = +relay_from_hosts wichtig, die nicht durch ein
Kommentarzeichen ausgeschaltet sein darf.
Die sogenannten Router legen fest, wie eine Nachricht zugestellt werden soll.
Dabei ist insbesondere relevant, ob die Zustellung lokal erfolgen soll oder nach "draussen"
geht. Außerdem kann man festlegen, ob eine direkte Zustellung erfolgen soll, oder
alle Mails über einen sogenannten Smarthost verschickt werden.
Viele Mailprovider sind zum Schutz vor Spam dazu übergegangen, Mails von DialUp-Zugängen aus nicht mehr direkt anzunehmen. Die Verwendung eines Smarthosts (z.B. den des Mail-Providers) für alle ausgehenden E-Mails ist daher dringend zu empfehlen! In der Routers Configuration ist weiterhin zu beachten, daß die
Reihenfolge der einzelnen Router wichtig ist. D.h. die einzelnen
Router werden von oben nach unten solange abgearbeitet, bis eine Nachricht
damit verschickt werden kann - auch wenn der Versand eigentlich erst mit einem
anderen Router beabsichtigt war, der weiter unten steht!
Die weitere Exim-Konfiguration beschreibe ich für zwei verschiedene Fälle getrennt, um eine bessere Übersichtlichkeit zu erreichen. Der erste Fall (Versand über einen Smarthost) beschreibt die Situation, daß alle Mails über denselben Smarthost verschickt werden. Diese Lösung ist deutlich einfacher zu konfigurieren, zeigt in der täglichen Nutzung aber durchaus Schwächen: So sortiert z.B. GMX in der Voreinstellung Mails als Spam ein, wenn sie nicht über den zu ihrer Domain gehörigen Server verschickt worden sind (also z.B. Mails mit Web.de-Absender über den Arcor-Server verschickt wurden). Der zweite Fall (Absenderabhängiger Versand über mehrere Smarthosts) beschreibt ein deutlich komplexeres Setup, bei dem der jeweils verwendete Smarthost anhand der Absenderadresse der Mail bestimmt wird. Die Zugangsdaten für SMTP-AUTH können dabei für jeden Server getrennt festgelegt werden. Wichtig: Bitte für die Konfiguration genau eine der beiden nachfolgenden Lösungen verwenden und die Lösungen nicht vermischen! -> Nach oben Versand über einen SmarthostBei dieser Lösung werden alle Mails über denselben Smarthost verschickt. Das kann z.B. der Mailserver des Internet-Providers sein, oder ein anderer Server, der nach Authentifizierung (SMTP-AUTH) beliebige Absenderadressen erlaubt.Hier nun die weiteren Abschnitte der Exim-Konfigurationsdatei für dieses Setup:
######################################################################
# ROUTERS CONFIGURATION #
# Specifies how addresses are handled #
######################################################################
# THE ORDER IN WHICH THE ROUTERS ARE DEFINED IS IMPORTANT! #
# An address is passed to each router in turn until it is accepted. #
######################################################################
begin routers
# Dies ist der Router fuer den direkten Mailversand; aus den angefuehrten
# Gruenden habe ich diesen Router durch Voranstellen von Kommentarzeichen
# deaktiviert.
#
# dnslookup:
# driver = dnslookup
# domains = ! +local_domains
# transport = remote_smtp
# ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
# no_more
# Mails, die an lokale Benutzer wie "root" geschickt werden, sollten an
# andere Accounts umgeleitet werden, die regelmaessig von den
# Verantwortlichen gelesen werden. Dazu dient die Datei /etc/aliases
# (mehr dazu in der Anleitung).
#
system_aliases:
driver = redirect
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/aliases}}
file_transport = address_file
pipe_transport = address_pipe
# Mail an lokale Benutzer soll in diesem Setup immer mittels Procmail
# zugestellt werden. Daher muss die Einstellung fuer "transport"
# entsprechend angepasst werden.
#
localuser:
driver = accept
check_local_user
# transport = local_delivery
transport = procmail_pipe
cannot_route_message = Unknown user
# Alle Mails nach "draussen" werden ueber den Relay-Server
# relay.server.tld verschickt.
#
smarthost:
domains = ! +local_domains
driver = manualroute
transport = remote_smtp
route_list = "* relay.server.tld"
host_find_failed = defer
no_more
######################################################################
# TRANSPORTS CONFIGURATION #
######################################################################
# ORDER DOES NOT MATTER #
# Only one appropriate transport is called for each delivery. #
######################################################################
begin transports
# Dieser Transport-Mechanismus wird beim Versand ueber SMTP-Verbindungen
# benutzt
#
remote_smtp:
driver = smtp
# Wenn der verwendete Smarthost eine Authentifizierung ueber SMTP-AUTH
# erfordert (heutzutage fast immer erforderlich; wenn moeglich, sollte
# man es nutzen), dann muss er hier eingetragen werden
#
hosts_try_auth = relay.server.tld
# Die lokale Zustellung aller Mails soll ueber Procmail erfolgen, da
# darueber auch die Spam-Filterung mittels Bogofilter und SpamAssassin
# koordiniert wird. Dies ist die Zustell-Regel, die dafuer sorgt, dass
# die Mails von Exim an Procmail uebergeben werden.
#
procmail_pipe:
driver = pipe
path = "/bin:/usr/bin:/usr/pkg/bin"
command = "/usr/pkg/bin/procmail -t -d ${local_part}"
return_path_add
delivery_date_add
envelope_to_add
check_string = "From "
escape_string = ">From "
user = $local_part
group = mail
(...)
######################################################################
# AUTHENTICATION CONFIGURATION #
######################################################################
begin authenticators
# Wenn eine Authentifizierung beim Smarthost ueber SMTP-AUTH erfolgen
# soll, muessen hier die Zugangsdaten entsprechend eingetragen werden.
#
cram_md5:
driver = cram_md5
public_name = CRAM-MD5
client_name = "Benutzername"
client_secret = "Passwort"
plain:
driver = plaintext
public_name = PLAIN
client_send = "^Benutzername^Passwort"
login:
driver = plaintext
public_name = LOGIN
client_send = ": Benutzername: Passwort"
(...)
Die Exim-Konfigurationsdatei ist damit fertig. Eine komplette Beispiel-Konfigurationsdatei
für dieses Setup kann heruntergeladen werden unter
 http://home.arcor.de/hm-gerhards/download/netbsd_imap/exim_single_smarthost.conf
Weiter mit der Konfiguration des Exim-Servers geht es im Abschnitt Sendmail durch Exim ersetzen. -> Nach oben Absenderabhängiger Versand über mehrere SmarthostsWie bereits oben erwähnt, ist dieses Setup deutlich komplexer aufgebaut, ist dadurch aber äußerst flexibel. So wird jeweils in Abhängigkeit von der Absenderadresse bestimmt, welcher Smarthost verwendet werden soll. Beispielsweise werden so Mails mit dem Absender xyz[at]gmx[dot]de über den GMX-Smarthost verschickt, Mails mit dem Absender xyz[at]arcor[dot]de über den Arcor-Smarthost - und zwar auch, wenn beide Mails vom gleichen lokalen User kommen.Aufgrund der Komplexizität dieser Lösung möchte ich jedem Einsteiger nahelegen, sich zunächst mit der einfacheren Lösung mit einem Smarthost vertraut zu machen, ehe er sich an dieses Setup heranwagt. Die Idee für dieses Setup stammt von Uwe Kerstan, der mir freundlicherweise erlaubt hat, es in meine Anleitung einzubauen. Seine Erläuterungen dazu finden sich unter http://www.linuxer.onlinehome.de/apps/exim4.htm. Bei ihm und bei mir hat sich dieses Setup im täglichen Betrieb bewährt; nichtsdestotrotz ist es noch als "experimentell" anzusehen und sollte auch mit der entsprechenden Umsicht und Vorsicht eingesetzt werden. Sollten Probleme auftauchen, so sollten zu Beginn der Fehlersuche ersteinmal alle Einträge auf die korrekte Schreibweise zu überprüfen - oft genug verursacht z.B. ein simples $ an der falschen Stelle
große Probleme.
Hier jetzt die entsprechenden Abschnitte für dieses Setup:
######################################################################
# MAIN CONFIGURATION SETTINGS #
######################################################################
(...)
# Fuer eine korrekte Fehlerbehandlung ueber einen sogenannten
# "Systemfilter" sind zusaetzlich zu den im allgemeinen
# Anleitungsabschnitt bereits beschriebenen Einstellungen
# noch folgende Eintraege noetig:
#
system_filter = /usr/pkg/etc/exim/exim_system_filter.conf
system_filter_user = mail
######################################################################
# ROUTERS CONFIGURATION #
# Specifies how addresses are handled #
######################################################################
# THE ORDER IN WHICH THE ROUTERS ARE DEFINED IS IMPORTANT! #
# An address is passed to each router in turn until it is accepted. #
######################################################################
begin routers
# Dies ist der Router fuer den direkten Mailversand; aus den angefuehrten
# Gruenden habe ich diesen Router durch Voranstellen von Kommentarzeichen
# deaktiviert.
#
# dnslookup:
# driver = dnslookup
# domains = ! +local_domains
# transport = remote_smtp
# ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
# no_more
# Mails, die an lokale Benutzer wie "root" geschickt werden, sollten an
# andere Accounts umgeleitet werden, die regelmaessig von den
# Verantwortlichen gelesen werden. Dazu dient die Datei /etc/aliases
# (mehr dazu in der Anleitung).
#
system_aliases:
driver = redirect
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/aliases}}
file_transport = address_file
pipe_transport = address_pipe
# Mail an lokale Benutzer soll in diesem Setup immer mittels Procmail
# zugestellt werden. Daher muss die Einstellung fuer "transport"
# entsprechend angepasst werden.
#
localuser:
driver = accept
check_local_user
# transport = local_delivery
transport = procmail_pipe
cannot_route_message = Unknown user
# Alle Mails nach "draussen" werden ueber den jeweils zugehoerigen
# Relay-Server verschickt. Zu dessen Bestimmung dient die Datei
# /usr/pkg/etc/exim/passwd.user die nach folgendem Muster aufgebaut
# ist:
# E-Mailadresse:E-Mailadresse:Lokaler_Username:Relay-Server:Benutzername:Passwort
#
# Grob gesagt, bewirken dieser Router folgendes: Die "condition" prueft, ob
# ein entsprechender Eintrag vorhanden ist. Dabei wird nach einer Zeile mit
# der Absender-Adresse ($sender_address) gesucht. Wird sie gefunden, so wird
# der Eintrag nach dem dritten Doppelpunkt als Wert zurueckgeliefert,
# ansonsten der Wert "fail".
#
# War die Suche erfolgreich, so wird die Verarbeitung mit diesem Router
# fortgesetzt. Fuer den Versand wird dann unter "route_list" auf die
# beschriebene Weise wieder der zu verwendende Smarthost anhand der
# "sender_address" aus der Datei gelesen.
#
smarthost_auto:
domains = ! +local_domains
condition = "${extract{3}{:}{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}"
driver = manualroute
transport = remote_smtp
route_list = "* ${extract{3}{:}{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}"
host_find_failed = defer
no_more
######################################################################
# TRANSPORTS CONFIGURATION #
######################################################################
# ORDER DOES NOT MATTER #
# Only one appropriate transport is called for each delivery. #
######################################################################
begin transports
# Dieser Transport-Mechanismus wird beim Versand ueber SMTP-Verbindungen
# benutzt
#
remote_smtp:
driver = smtp
# Hier wird der jeweilige Smarthost wieder auf die oben beschriebene
# Weise aus der Datei /usr/pkg/etc/exim/passwd.user geholt und
# automatisch fuer SMTP-AUTH eingetragen.
#
hosts_try_auth = "${extract{3}{:}{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}"
# Die lokale Zustellung aller Mails soll ueber Procmail erfolgen, da
# darueber auch die Spam-Filterung mittels Bogofilter und SpamAssassin
# koordiniert wird. Dies ist die Zustell-Regel, die dafuer sorgt, dass
# die Mails von Exim an Procmail uebergeben werden.
#
procmail_pipe:
driver = pipe
path = "/bin:/usr/bin:/usr/pkg/bin"
command = "/usr/pkg/bin/procmail -t -d ${local_part}"
return_path_add
delivery_date_add
envelope_to_add
check_string = "From "
escape_string = ">From "
user = $local_part
group = mail
(...)
######################################################################
# AUTHENTICATION CONFIGURATION #
######################################################################
begin authenticators
# Benutzername und Kennwort, mit denen sich Exim beim jeweiligen
# Smarthost anmelden soll, werden in Abhaengigkeit von der Absenderadresse
# aus der Datei /usr/pkg/etc/exim/passwd.user geholt.
cram_md5:
driver = cram_md5
public_name = CRAM-MD5
client_name = "${extract{4}{:}{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}"
client_secret = "${extract{5}{:}{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}"
plain:
driver = plaintext
public_name = PLAIN
client_send = "^${extract{4}{::}\
{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}\
^${extract{5}{::}\
{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}"
login:
driver = plaintext
public_name = LOGIN
client_send = ": ${extract{4}{::}\
{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}\
: ${extract{5}{::}\
{${lookup{$sender_address}lsearch*\
{/usr/pkg/etc/exim/passwd.user}{$value}fail}}}"
(...)
Die Exim-Konfigurationsdatei ist damit fertig. Eine komplette Beispiel-Konfigurationsdatei
für dieses Setup kann heruntergeladen werden unter
http://home.arcor.de/hm-gerhards/download/netbsd_imap/exim_auto_smarthost.conf
Wie bereits in der Konfigurationsdatei beschrieben, werden noch mehrere zusätzliche Konfigurationsdateien für diese Lösung benötigt. Am wichtigsten ist natürlich die Datei /usr/pkg/etc/exim/passwd.user, in der die einzelnen Mail-Adressen und
Relay-Server samt Benutzernamen und Passwörtern eingetragen werden. Ein Beispiel für
diese Datei sieht folgendermaßen aus:
# # /usr/pkg/etc/exim/passwd.user # # Die Eintraege sind alle nach folgendem Muster aufgebaut, Trennzeichen # zwischen den einzelnen Eintraegen ist ein einfacher Doppelpunkt: # # E-Mailadresse:E-Mailadresse:Lokaler_Username:Relay-Server:Benutzername:Passwort # # Die doppelte E-Mailadresse zu Beginn der Datei ist wichtig fuer die # Fehlerbehandlung! # mail@provider.tld:mail@provider.tld:username:mail.provider.tld:benutzerkennung:passwortFür die Fehlerbehandlung wichtig ist die Datei /usr/pkg/etc/exim/exim_system_filter.conf. Sie enthält folgendes:
#
# /usr/pkg/etc/exim/exim_system_filter.conf
#
# Kann eine Mail nicht verschickt werden, so geht der Bounce ueblicherweise
# an die im Absender genannte Adresse. Nach dieser Adresse werden nun alle
# Zeilen in der Datei /usr/pkg/etc/exim/passwd.user durchsucht (jeweils im
# Feld hinter dem ersten Doppelpunkt).
# Falls diese Suche erfolgreich war, wird die Fehlermeldung an den
# entsprechenden lokalen User (steht im Feld hinter dem zweiten Doppelpunkt)
# zugestellt.
#
# War die Suche nicht erfolgreich, so wird die Fehlermeldung an den Postmaster
# (bzw. seinen in der Datei /etc/aliases eingestellten Alias) geschickt.
#
if not first_delivery then finish endif
if error_message
then
logfile /var/log/exim/filterlog
if
$h_to: contains ${extract{1}{:}{${lookup{$h_to:}lsearch*{/usr/pkg/etc/exim/passwd.user}{$value}}}}
then
logwrite "$tod_log Error-Messages send to $h_to:."
headers add "X-RETURN: to local sender $h_to:."
deliver ${extract{2}{:}{${lookup{$h_to:}lsearch*{/usr/pkg/etc/exim/passwd.user}{$value}}}}
else
logwrite "$tod_log Error-Messages send to postmaster."
headers add "X-RETURN: to postmaster."
deliver postmaster
endif
finish
endif
Diese Datei steht zum Download bereit unterhttp://home.arcor.de/hm-gerhards/download/netbsd_imap/exim_system_filter.conf
Weiter mit der Konfiguration des Exim-Servers geht es im Abschnitt Sendmail durch Exim ersetzen. -> Nach oben Sendmail durch Exim ersetzenNachdem die Exim-Konfigurationsdatei erfolgreich erstellt worden ist, kann man nun darangehen, den noch laufenden Sendmail durch Exim zu ersetzen. Zuerst überzeugt man sich aber noch davon, daß man bei der Erstellung der Konfigurationsdatei nicht versehentliche Syntaxfehler eingebaut hat:root@host:~> exim -C /usr/pkg/etc/exim/configure -bV Exim version 4.42 #1 built 26-Dec-2004 12:11:04 Copyright (c) University of Cambridge 2004 Probably Berkeley DB version 1.8x (native mode) Support for: IPv6 TCPwrappers OpenSSL Lookups: lsearch wildlsearch nwildlsearch iplsearch dbm dbmnz Authenticators: cram_md5 plaintext spa Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Fixed never_users: 0 Configuration file is /usr/pkg/etc/exim/configureWenn alles in Ordnung ist, gilt es nun, ersteinmal ein paar Rechte zu korrigieren, damit niemand Zugriff auf die Passwörter für die E-Mail-Accounts erlangen kann: root@host:~> chown mail.mail /usr/pkg/etc/exim/* root@host:~> chmod 600 /usr/pkg/etc/exim/passwd.userNun wird das Startskript für Exim an die richtige Stelle kopiert: root@host:~> cp /usr/pkg/share/examples/rc.d/exim /etc/rc.d/Folgende Einstellungen in der Datei /etc/rc.conf sind nötig, um
demnächst Exim anstelle von Sendmail zu starten:
sendmail=NO exim=YESNun kann man Sendmail stoppen mittels eines root@host:~> /etc/rc.d/sendmail stopDer Aufruf des Mailserver-Binaries geschieht unter NetBSD immer über ein Wrapper-Skript namens /usr/sbin/mailwrapper. Damit dieses
Skript auch immer den richtigen MTA aufruft, werden die entsprechenden
Kommandopfade in der Datei /etc/mailer.conf festgelegt. Diese
Datei muß nun gesichert und durch die entsprechende Variante für
Exim ersetzt werden:
root@host:~> mv /etc/mailer.conf /etc/mailer.conf.sendmail root@host:~> cp /usr/pkg/share/examples/exim/mailer.conf /etc/mailer.confWie oben bereits angeführt, dient die Datei /etc/aliases dazu,
um Mail für System-Accounts wie root an häufig gelesene
Postfächer der jeweiligen Administratoren umzuleiten. Wieder gilt es,
die entsprechende Sendmail-Datei zu sichern und durch das Exim-Pendant zu ersetzen:
root@host:~> mv /etc/aliases /etc/aliases.sendmail root@host:~> cp /usr/pkg/etc/exim/aliases /etc/aliasesNun muß die Datei noch entsprechend angepaßt werden. Auf meinem System leite ich alle entsprechenden Mails an root, postmaster etc
an meinen User michael weiter. Meine /etc/aliases sieht
daher folgendermaßen aus:
# # /etc/aliases # # The following alias is required by the mail RFCs 2821 and 2822. # Set it to the address of a HUMAN who deals with this system's mail problems. # postmaster: michael # It is also common to set the following alias so that if anybody replies to a # bounce message from this host, the reply goes to the postmaster. # mailer-daemon: postmaster # You should also set up an alias for messages to root, because it is not # usually a good idea to deliver mail as root. # root: michaelDer Exim-Daemon kann nun erstmals gestartet werden: root@host:~> /etc/rc.d/exim start Starting exim.Ob der Daemon wirklich läuft, kann man einfach herausfinden, indem man versucht, eine Verbindung auf Port 25 (SMTP) herzustellen: user@host:~> telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 lokaler-server.subdomain.dyndns.org ESMTP Exim 4.42 quit 221 lokaler-server.subdomain.dyndns.org closing connection Connection closed by foreign host.Der Exim-Daemon lauscht jetzt also an Port 25 und ist bereit, Mails entgegenzunehmen. Damit sind die Konfigurationsschritte für Exim auf dem Server fast abgeschlossen. Damit die Logdateien von Exim nicht immer weiterwachsen, empfiehlt es sich, sie in regelmäßen Abständen zu "rotieren". Dafür kann man unter NetBSD z.B. das Programm newsyslog verwenden, näheres dazu im Abschnitt Nacharbeiten - Logfile-Rotation mit newsyslog einrichten. -> Nach oben Procmail sortiertNachdem 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: root@host:~> cd /usr/pkgsrc/mail/procmail root@host:/usr/pkgsrc/mail/procmail> make installDa das Logverzeichnis bereits bei der Installation von Fetchmail angelegt wurde, muß das an dieser Stelle nicht mehr erfolgen. Die Konfiguration von Procmail geschieht in der globalen Konfigurationsdatei /usr/pkg/etc/procmailrc. Diese Datei sieht bei mir folgendermaßen aus:
#
# /usr/pkg/etc/procmailrc
#
# Zuerst einige allgemeine Definitionen:
#
# deliver sortiert die Mails in die Cyrus-Mailboxen ein:
DELIVERMAIL="/usr/pkg/cyrus/bin/deliver"
#
# Das Logfile, in das Fehlermeldungen etc. geloggt werden:
LOGFILE="/var/log/mail/procmail.log"
#
# Damit die procmailrc uebersichtlicher bleibt, vergeben wir
# "Kurznamen" fuer einige Zustellbefehle. Auskunft ueber
# die genaue Syntax gibt die Manpage zu deliver.
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:
#
# "/usr/bin/sed 1d" dient dazu, den von Procmail gesetzten ungueltigen
# "From"-Header wieder zu entfernen!
#
:0 c
| /usr/bin/sed 1d | $BACKUP
# bei Fehler zurueck in die Queue
:0 e
{ EXITCODE=75 HOST }
# Manche GMX-Mails sind schon als Spam gekennzeichnet
:0
* ^*** GMX Spamverdacht ***
| /usr/bin/sed 1d | $GMXSPAM
# bei Fehler zurueck in die Queue
:0 e
{ EXITCODE=75 HOST }
# Ueberpruefung durch Bogofilter
#
:0fw
| /usr/pkg/bin/bogofilter -u -e -p -l -d /home/$LOGNAME/.bogofilter/
:0
* ^X-Bogosity: Yes, tests=bogofilter
| /usr/bin/sed 1d | $BOGOSPAM
# bei Fehler zurueck in die Queue
:0 e
{ EXITCODE=75 HOST }
# Ueberpruefung durch SpamAssassin
#
:0fw
| /usr/pkg/bin/spamc -u $LOGNAME
:0
* ^X-Spam-Status: Yes
| /usr/bin/sed 1d | /usr/pkg/bin/spamassassin -d | $SPAMIT
# bei Fehler zurueck in die Queue
:0 e
{ EXITCODE=75 HOST }
# Zustellung in die INBOX des Users:
#
:0 w
| /usr/bin/sed 1d | $IMAP
# bei Fehler zurueck in die Queue
:0 e
{ EXITCODE=75 HOST }
# Das Ergebnis der Zustellung wird geloggt:
#
:0 w
{
EXITCODE=$?
HOST
}
Diese Datei steht zum Download bereit unterhttp://home.arcor.de/hm-gerhards/download/netbsd_imap/procmailrc
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 | /usr/bin/sed 1d | $BACKUPJede 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/pkg/bin/spamc -u $LOGNAMEEr 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 | /usr/bin/sed 1d | /usr/pkg/bin/spamassassin -d | $SPAMITHier 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 immer weiterwächst, empfiehlt es sich, sie in regelmäßen Abständen zu "rotieren". Dafür kann man unter NetBSD z.B. das Programm newsyslog verwenden, näheres dazu im Abschnitt Nacharbeiten - Logfile-Rotation mit newsyslog einrichten. -> Nach oben Erste Vorsortierung mit BogofilterBogofilter 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. Zur Installation von Bogofilter sind lediglich die folgenden Zeilen nötig: root@host:~> cd /usr/pkgsrc/mail/bogofilter/ root@host:/usr/pkgsrc/mail/bogofilter> make installNun gilt es, in der Datei /usr/pkg/etc/bogofilter.cf einige Einstellungen
zu treffen:
bogofilter_dir=~/.bogofilter spam_header_name=X-Bogosity stats_in_header=Yes spamicity_tags = Yes, No, Unsure header_format = %h: %c, tests=bogofilter, spamicity=%p, version=%v charset_default=iso-8859-15 ham_cutoff = 0.00 spam_cutoff = 0.99Damit wird das Verzeichnis festgelegt, in dem für jeden User die Bogofilter-Datenbanken geführt werden ( ~/.bogofilter), sowie einige Einstellungen zum Header
festgelegt, den Bogofilter nach der Überprüfung jeder Mail hinzufügt. Für
weitergehende Erläuterungen empfehle ich einen Blick in die gut dokumentierte
Konfigurationsdatei oder direkt in die Manpage.
Der Aufruf von Bogofilter erfolgt in der Datei /usr/pkg/etc/procmailrc. Die
verwendete Syntax /usr/pkg/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
/usr/pkg/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. Eventuell muß man dieses Verzeichnis erst noch neu anlegen und
in den Pfad einbinden, da es unter NetBSD 2.0 nicht mehr zu den Standard-Verzeichnissen
gehört:
root@host:~> mkdir -p /usr/local/binHier jetzt das Skript:
#!/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.
#
# das Cyrus-Spoolverzeichnis muss gegebenenfalls entsprechend
# angepasst werden
MAILDIR=/var/spool/imap/mail/user/
for USR in $(ls $MAILDIR)
do find $MAILDIR/$USR/SPAM \
-name \*. -ctime -1 -print | \
while read filename
do /usr/bin/bogofilter -d /home/$USR/.bogofilter/ -s < "$filename"
done
chown -R $USR /home/$USR/.bogofilter
chmod 666 /home/$USR/.bogofilter/*
done
Diese Datei steht zum Download bereit unterhttp://home.arcor.de/hm-gerhards/download/netbsd_imap/bogo_train
Anschließend wird die Datei noch ausführbar gemacht mittels root@host:~> chmod 755 /usr/local/bin/bogo_trainDamit dieses Skript täglich ausgeführt wird, muß man nun noch einen entsprechenden Cronjob anlegen. Da viele Heimrechner nicht 24h pro Tag durchlaufen, empfiehlt sich eine Kombination von cron mit dem Programm anacron. So ist sichergestellt, daß das Skript auch dann regelmäßig ausgeführt wird, wenn der Rechner zum Zeitpunkt des eigentlichen Cronjobs ausgeschaltet war. Die Installation von anacron und das Zusammenspiel von cron und anacron beschreibe ich im nächsten Abschnitt anacron - die etwas andere Zeitschaltuhr. 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/pkg/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 anacron - die etwas andere ZeitschaltuhrAuf jedem Serversystem gibt es verschiedene Dienste, die regelmäßig (z.B. jede Woche) ausgeführt werden müssen. Dazu zählt z.B. das Rotieren von Logdateien mittelsnewsyslog, das Aktualisieren der
locate-Datenbank oder auch das
weiter oben
beschriebene Skript bogo_train.
Bei einem klassischen Serversystem, das 24 Stunden pro Tag durchläuft, wird diese Aufgabe typscherweise von dem Daemon cron mit sogenannten
"Cronjob" erledigt. Voraussetzung dafür ist allerdings, daß das System
dafür tatsächlich läuft.
Mit einem kleinen Beispiel kann man diese Problematik sehr schnell verdeutlichen: Angenommen, man erstellt einen Cronjob, der jeden Sonntag um 15 Uhr eine neue locate-Datenbank erzeugt. Der zugehörige Rechner steht aber in einem Büro,
und ist nur von Montags bis Freitags eingeschaltet. Infolge dessen wird die
locate-Datenbank nie aktualisiert werden - weil der Cron-Daemon diesen
Befehl eben nur genau Sonntags um 15 Uhr startet. Läuft das System zu
diesem Zeitpunkt nicht, wird der Befehl auch nicht ausgeführt.
Zur Umgehung dieses Problems bietet es sich an, cron mit dem Programm
anacron zu kombinieren. anacron hat andere Stärken als
cron, es merkt sich nämlich, wann welches Programm zuletzt ausgeführt
worden ist. Beispielsweise kann man für die locate-Datenbank einstellen,
daß sie alle 7 Tage aktualisiert werden soll. Stellt anacron nun beim
Systemstart fest, daß seit dem letzten Programmstart z.B. 8 Tage vergangen sind (oder
auch beliebig mehr), so wird ein Update der Datenbank gestartet. Auf diese Weise ist
sichergestellt, daß alle notwendigen Systemdienste auch dann regelmäßig
ausgeführt werden, wenn der Rechner nicht 24 Stunden pro Tag
durchläuft.
Im Gegensatz zu cron arbeitet anacron allerdings eher "ungenau", d.h.
das kleinste einstellbare Intervall ist ein Tag. Dienste, die häufiger ausgeführt werden
sollen (z.b. jede Stunde oder alle 15 Minuten) muß man weiterhin von cron
starten lassen. Denn hier liegt die Stärke von cron, das sehr exakte
(minutengenaue) Aufrufe ermöglicht.
Bevor ich das genaue Zusammenspiel von cron und anacron auf einer
typischen NetBSD-Installation beschreibe, gilt es ersteinmal, anacron zu installieren.
cron gehört zur NetBSD-Grundinstallation, muß also nicht installiert
werden. Die Installation von anacron läuft NetBSD-typisch ab:
root@host:~> cd /usr/pkgsrc/time/anacron root@host:/usr/pkgsrc/time/anacron> make installDamit anacron auch bei jedem Systemstart aufgerufen wird, kopiert man das Startskript
nach /etc/rc.d/ mittels
root@host:~> cp /usr/pkg/share/examples/rc.d/anacron /etc/rc.d/und aktiviert es in der /etc/rc.conf mit dem Eintrag
anacron=YES anacron_flags="-s"Der Eintrag anacron_flags="-s" sorgt dafür, daß anacron
die aufzurufenden Programme nacheinander abarbeitet. Damit kann man auf schwächer
dimensionierten Systemen eine zu hohe Systemlast verhindern. Nähere Informationen
dazu finden sich in der guten Manpage unter man 8 anacron
Nun muß man dafür sorgen, daß sich cron und
anacron nicht gegenseitig stören. Denn für das korrekte Funktionieren
von anacron ist wichtig, daß die davon kontrollierten Dienste nicht an
anacron vorbei aufgerufen werden, z.B. durch einen Cronjob. Also gilt es die
crontab des Users root entsprechend anzupassen, die alle entsprechenden
Cronjobs enthält. Der dazu nötige Befehl lautet crontab
-e und öffnet die crontab im jeweiligen Lieblingseditor (der in der
Umgebungsvariable $EDITOR eingestellt ist). Unter NetBSD sieht sie standardmäßig
folgendermaßen aus:
# SHELL=/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log CRON_WITHIN=7200 # #minute hour mday month wday command # */10 * * * * /usr/libexec/atrun # # rotate log files every hour, if necessary 0 * * * * /usr/bin/newsyslog # # do daily/weekly/monthly maintenance 15 3 * * * /bin/sh /etc/daily 2>&1 | tee /var/log/daily.out | sendmail -t 30 4 * * 6 /bin/sh /etc/weekly 2>&1 | tee /var/log/weekly.out | sendmail -t 30 5 1 * * /bin/sh /etc/monthly 2>&1 | tee /var/log/monthly.out | sendmail -tZu Beginn der Datei werden ein paar allgemeine Variablen gesetzt. In den danach folgenden Zeilen (Kommentarzeilen werden mit einer # eingeleitet)
ist jeweils ein Kommando angegeben, sowie die genaue Uhrzeit, zu der es
ausgeführt werden soll. Die Spalten bedeuten dabei von links nach rechts,
in welcher Minute, Stunde, an welchem Tag des Monats, in welchem Monat und an
welchem Wochentag das Kommando ausgeführt werden soll. Ein Stern
(*) steht stellvertretend für die Angabe "alle". D.h. das
erste Kommando /usr/libexec/atrun wird alle 10 Minuten
(*/10) in jeder Stunde, an jedem Tag des Monats, in jedem Monat und an
jedem Wochentag ausgeführt.
Der zweite Befehl ( /usr/bin/newsyslog) wird hingegen nur zu jeder vollen
Stunde (0 in der Spalte für die Minuten) ausgeführt.
Diese beiden Kommandos werden mehrfach am Tag ausgeführt, also ist es sinnvoll, sie weiterhin von cron aufrufen zu lassen. Die nachfolgenden Befehle
werden allerdings einmal pro Tag (das Skript /etc/daily) bzw pro
Woche (/etc/weekly) oder pro Monat (/etc/monthly)
aufgerufen. Hier ist es sinnvoll, den Aufruf von anacron vornehmen zu lassen.
Nur so ist bei einem System, das nicht 24 Stunden pro Tag läuft, sichergestellt, daß
diese Skripte regelmäßig ausgeführt werden.
Eine Möglichkeit, cron am Aufruf dieser Skripte zu hindern, wäre
einfach die entsprechenden Zeilen durch ein Kommentarzeichen zu deaktivieren. Aber die
folgende Lösung ist eleganter und überläßt anacron nur
dann den Aufruf dieser Befehle, wenn es wirklich installiert ist. Außerdem sollte man
anacron einmal pro Tag von cron aufrufen lassen - es könnte
ja doch einmal sein, daß der Rechner länger als 24 Stunden durchläuft.
Nach den Änderungen hat die crontab dann folgendes Aussehen:
# SHELL=/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log CRON_WITHIN=7200 # #minute hour mday month wday command # */10 * * * * /usr/libexec/atrun # # rotate log files every hour, if necessary 0 * * * * /usr/bin/newsyslog # # # Einmal taeglich anacron aufrufen 15 3 * * * /usr/pkg/sbin/anacron # # do daily/weekly/monthly maintenance 15 3 * * * test -e /usr/pkg/sbin/anacron || /bin/sh /etc/daily 2>&1 | tee /var/log/daily.out | sendmail -t 30 4 * * 6 test -e /usr/pkg/sbin/anacron || /bin/sh /etc/weekly 2>&1 | tee /var/log/weekly.out | sendmail -t 30 5 1 * * test -e /usr/pkg/sbin/anacron || /bin/sh /etc/monthly 2>&1 | tee /var/log/monthly.out | sendmail -tIn diesem Beispiel wird anacron damit jeden Tag um 03.15 Uhr aufgerufen - natürlich
nur, wenn der Rechner zu dieser Zeit überhaupt läuft.
Wichtig: Die crontab muß mit einer leeren Zeile enden, sonst wird der Befehl
der letzten Zeile nicht beachtet!
Weitergehende Erläuterungen zu cron finden sich z.B. in der guten
Anleitung von Henning Hülsebusch und Ulrich Heilmann unter
http://www.newbie-net.de/anleitung_cron.html
oder natürlich in den Manpages zu cron und crontab.
anacron ist nun fast fertig konfiguriert, jetzt gilt es nur noch festzulegen,
welche Befehle von anacron ausgeführt werden sollen. Dazu dient die
Konfigurationsdatei /usr/pkg/etc/anacrontab, die (im Gegensatz zu cron)
mit einem beliebigen Texteditor bearbeitet werden kann.
Vorab ein paar Worte zur Syntax dieser Datei. Sie weicht etwas von der Cron-Syntax ab. In der ersten Spalte gibt man an, alle wieviel Tage ein Befehl ausgeführt werden soll. Steht dort beispielsweise eine 1, so wird der Befehl jeden Tag ausgeführt.
Soll das Kommando nur einmal pro Woche ausgeführt werden, so setzt man dort eine 7
Wenn ein System längere Zeit ausgeschaltet war, könnte es sein, daß sehr viele Kommandos auf einmal ausgeführt werden müssen. Daher kann man in der zweiten Spalte eine Verzögerung (in Minuten) angeben, die nach dem Aufruf von anacron
bis zur Ausführung des Kommandos gewartet wird. So kann man beispielsweise bei einem
Befehl 15 eintragen und beim nächsten Befehl 30, und verhindert
auf diese Weise eine zu starke Auslastung des Systems direkt nach dem Booten.
In der dritten Spalte gibt man einen eindeutigen Namen für den jeweiligen Auftrag an, der weder Leerzeichen noch Schrägstriche ( /) enthalten darf. Danach folgt
dann in der vierten und letzten Spalte schließlich das auszuführende Kommando.
Um die weiter oben beschriebenen System-Wartungsskripte unter NetBSD auszuführen, könnte die Datei /usr/pkg/etc/anacrontab damit folgendermaßen
aussehen:
# $NetBSD # # anacrontab - Configuration file for NetBSD. # # See anacrontab(5) and anacron(8) for more information. # SHELL=/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log #days delay id command 1 5 daily /bin/sh /etc/daily 2>&1 | tee /var/log/daily.out | sendmail -t 7 15 weekly /bin/sh /etc/weekly 2>&1 | tee /var/log/weekly.out | sendmail -t 30 30 monthly /bin/sh /etc/monthly 2>&1 | tee /var/log/monthly.out | sendmail -tNatürlich steht es jedem frei, weitere eigene Aufträge für anacron
zu erstellen. Um beispielsweise das
weiter oben
beschriebene Skript bogo_train jeden Tag aufzurufen, fügt man folgende
Zeile hinzu:
#days delay id command 1 45 bogotrain /usr/local/bin/bogo_trainDamit wird das Skript jeden Tag 45 Minuten nach Systemstart aufgerufen - bzw jede Nacht um 4.00 Uhr, falls das System durchlaufen sollte. -> Nach oben SpamAssassin filtertProcmail haben wir 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 Die Installation von SpamAssassin ist bekannt einfach: root@host:~> cd /usr/pkgsrc/mail/spamassassin root@host:/usr/pkgsrc/mail/spamassassin> make installIn der Datei /usr/pkg/etc/spamassassin/local.cf müssen nun
folgende Einstellungen getroffen werden:
bayes_file_mode 0777 report_safe 0 use_auto_whitelist 1 auto_whitelist_file_mode 0777Der Parameter " use_auto_whitelist 1" bewirkt folgendes: 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 user@host:~> spamassassinohne 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.deNatürlich kann man umgekehrt auch Mails auf eine Blacklist setzen: blacklist_from boeser-mensch@anderer-isp.deEbenfalls in der Datei ~/.spamassassin/user_prefs stellt man ein,
ab welcher Punktzahl eine Mail als Spam eingestuft wird. Die Voreinstellungrequired_hits 5ist 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 Befehluser@host:~> spamassassin -W < Datei-ohne-SpamDie Mail läßt sich dann mit dem Befehl user@host:~> spamassassin -d < Datei-ohne-Spam > Mail-ohne-Markierungin 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 user@host:~> spamassassin -rR < Datei-mit-SpamDer 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:
user@host:~> sa-learn --spam < Datei-mit-SpamWer 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-SpamIm 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 Befehlenuser@host:~> sa-learn --ham < Datei-ohne-Spam user@host:~> sa-learn --ham --mbox Datei-mit-vielen-guten-MailsJe 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).Aus Performancegründen ist es empfehlenswert, den spamd als Daemon zu starten. Dazu kopiert man das Beispiel-Startskript in das Init-Verzeichnis: root@host:~> cp /usr/pkg/etc/rc.d/spamd /etc/rc.d/Damit der spamd-Daemon auch bei jedem Systemstart mit den passenden
Optionen gestartet wird, sind folgende Einträge in der Datei
/etc/rc.conf nötig:
spamd=YES spamd_flags="-c -m4"Das Hinzufügen der Option -m 4 bewirkt, daß nicht mehr
als 4 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 4 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 individuell ermittelt werden. 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 /usr/pkg/etc/procmailrc: Der Befehl /usr/pkg/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 /usr/bin/sed 1d | /usr/pkg/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 verwaltetWir 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ß... ;-)Benötigt werden der eigentliche Cyrus-IMAP-Server sowie der saslauth-Daemon, der für die Authentifizierung sorgt. Die Installation erfolgt NetBSD-typisch mit einem root@host:~> cd /usr/pkgsrc/mail/cyrus-imapd/ root@host:/usr/pkgsrc/mail/cyrus-imapd> make install root@host:~> cd /usr/pkgsrc/security/cyrus-saslauthd/ root@host:/usr/pkgsrc/security/cyrus-saslauthd> make installIn der Konfigurationsdatei /usr/pkg/etc/imapd.conf wird unter anderem
festgelegt, welche Verzeichnisse Cyrus zur Ablage von Konfigurationsdateien
(als Option configdirectory) und für die eigentlichen
Mailboxen (partition-default) nutzen soll. Die (durchaus sinnvolle)
Standardeinstellung sieht folgendermaßen aus:
configdirectory: /var/imap partition-default: /var/spool/imapDiese Verzeichnisse existieren allerdings noch nicht, sondern müssen erst noch angelegt und mit den passenden Rechten versehen werden: root@host:~> mkdir /var/imap root@host:~> chown cyrus.mail /var/imap root@host:~> chmod 750 /var/imap root@host:~> mkdir /var/spool/imap root@host:~> chown cyrus.mail /var/spool/imap root@host:~> chmod 750 /var/spool/imap root@host:~> su cyrus cyrus@host:~> /usr/pkg/cyrus/bin/mkimap cyrus@host:~> exit root@host:~>Mit den letzten drei Befehlen wird eine passende Struktur an Unterverzeichnissen mit den korrekten Rechten angelegt (deshalb muß der Befehl unbedingt als User cyrus ausgeführt werden!).
Als Authentifizierungsmethode soll in diesem Beispiel der saslauthd
dienen, d.h. er muß auch in /usr/pkg/etc/imapd.conf entsprechend
ausgewählt sein:
sasl_pwcheck_method: saslauthd allowplaintext: yesDamit man sich mittels cyradm direkt von der Kommandozeile aus anmelden kann,
muß die Option allowplaintext: yes gesetzt sein.
Der saslauthd ermöglicht es, zur Authentifizierung die normalen
System-Benutzer aus der Datei /etc/passwd zu verwenden. Zu seiner
Verwendung muß noch ein symbolischer Link angelegt werden:
root@host:~> ln -s /usr/pkg/lib/sasl2 /usr/lib/sasl2Üblicherweise geschieht die Administration des Mailservers über den User cyrus. Dementsprechend muß in der Datei
/usr/pkg/etc/imapd.conf folgender Eintrag stehen (Standardvorgabe):
admins: cyrusNun muß man dem User cyrus nur noch ein Paßwort zuweisen: root@host:~> passwd cyrusTypisch für die NetBSD-Package-Collection ist, daß die Startdateien für Cyrus und den saslauth-Daemon erst noch an ihren eigentlichen Ort kopiert werden müssen: root@host:~> cp /usr/pkg/share/examples/rc.d/cyrus /etc/rc.d/ root@host:~> cp /usr/pkg/share/examples/rc.d/saslauthd /etc/rc.d/Damit beide Dienste bei jedem Systemstart gestartet werden, sind folgende Einträge in der Hauptkonfigurationsdatei /etc/rc.conf nötig:
saslauthd=YES cyrus=YESAnschließend kann man beide Dienste von Hand starten: root@host:~> /etc/rc.d/saslauthd start root@host:~> /etc/rc.d/cyrus startDamit 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, d.h. jeder
IMAP-User muß zuerst als User auf dem Server angelegt werden. Der
passende Befehl dazu lautet unter NetBSD:root@host:~> useradd -m test-user root@host:~> passwd test-userDie 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 ver Zeigt Versionsinformationen der Serversoftware anUnserem frisch erstellten User " test-user" verschaffen wir
folgendermaßen einen IMAP-Account:root@host:~> cyradm -user cyrus -auth login localhost localhost password: localhost> cm user.test-userWichtig: 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.EntwuerfeOb das Anlegen der Ordner erfolgreich war, zeigt das Kommando " lm":localhost> lm user.test-user (\HasChildren) user.test-user.Backup (\HasNoChildren) user.test-user.BogoSPAM (\HasNoChildren) user.test-user.Entwuerfe (\HasNoChildren) user.test-user.GMX-SPAM (\HasNoChildren) user.test-user.Gesendete_Nachrichten (\HasNoChildren) user.test-user.SPAM (\HasNoChildren)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 ) 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 cd 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/modules.php?op=modload&name=PagEd&file=index&topic_id=1&page_id=13). Wer Hilfe bei Installation oder Konfiguration sucht, der wird sicher auch in den Verzeichnissen /usr/pkg/share/doc/html/cyrus-imapd/ und /usr/pkg/share/doc/html/cyrus-sasl/
oder in den guten Manpages (z.B. man 5 imapd.conf) fündig werden.
-> Nach oben Nacharbeiten - Logfile-Rotation mit newsyslog einrichtenWie weiter oben bereits erwähnt, wird die Aktivität von Fetchmail, Procmail und Exim in diversen Logfiles festgehalten. Damit diese Logfiles nicht immer weiterwachsen und irgendwann die komplette Festplatte ausfüllen, müssen sie von Zeit zu Zeit "rotiert" werden. Dabei werden die alten Inhalte in mehreren Generationen gesichert.D.h. wenn man eine Logdatei logfile beispielsweise alle 24 Stunden rotieren
läßt, finden sich die Inhalte der 24 Stunden zuvor in der Datei logfile.0,
die Inhalte der Zeit von vor 48 Stunden bis vor 24 Stunden in der Datei logfile.1
usw bis zur maximalen Generationenzahl. Beim "rotieren" wird dann die jeweils älteste
Logdatei gelöscht und durch die nächstjüngere überschrieben - so daß
sich der Inhalt von logfile dann in logfile.0 wiederfindet und
logfile leer ist und für neue Log-Einträge zur Verfügung steht.
Dieses "rotieren" wird unter NetBSD typischerweise vom Dienstprogramm newsyslog
übernommen. Es gehört zur NetBSD-Grundinstallation, ist also normalerweise schon
auf dem System installiert. Aufgerufen wird es stündlich von cron, ein
entsprechender Cronjob sollte ebenfalls bereits angelegt sein. Kontrollieren läßt
sich dies folgendermaßen:
root@host:~> crontab -l | grep newsyslog 0 * * * * /usr/bin/newsyslogDie Konfiguration von newsyslog geschieht in der Datei /etc/newsyslog.conf
in der sich bereits einige Einträge für System-Logfiles befinden. Diese Einträge
ergänzt man nun um die Logfiles von Fetchmail, Procmail und Exim:
# $NetBSD: newsyslog.conf,v 1.18 2003/11/21 18:07:09 abs Exp $ # # Configuration file for newsyslog(8). # # logfilename [owner:group] mode ngen size when flags [/pidfile] [sigtype] # /var/log/aculog uucp:dialer 640 7 * 24 Z /var/log/authlog 600 5 100 * Z /var/log/cron root:wheel 600 3 100 * Z /var/log/kerberos.log 640 7 * 24 ZN /var/log/lpd-errs 640 7 100 * Z /var/log/maillog 600 7 * 24 Z /var/log/messages 644 10 250 * Z /var/log/wtmp 644 7 * 168 ZBN /var/log/wtmpx 644 7 * 168 ZBN /var/log/xferlog 640 7 250 * Z # # # neue Eintraege fuer Exim-Logfiles /var/log/exim/main mail:mail 640 10 * 24 Z /var/log/exim/panic mail:mail 640 10 * 24 Z /var/log/exim/reject mail:mail 640 10 * 24 Z # # der folgende Eintrag ist nur noetig, falls man das Setup # "Exim mit Auto-Smarthost" installieren moechte /var/log/exim/filterlog mail:mail 640 10 * 24 Z # # # Procmail-Logfile /var/log/mail/procmail.log root:mail 640 10 * 24 Z # # # Fetchmail-Logfile /var/log/mail/fetchmail.log root:mail 640 10 * 24 ZDie einzelnen Einträge haben dabei folgende Bedeutung: Zu Beginn jeder Zeile steht der Name der zu rotierenden Logdatei. Davon durch Leerzeichen getrennt finden sich Besitzer:Gruppe dieser Datei, danach folgen die Zugriffsrechte
der Datei (640 entspricht den Rechten rw-r---).
In der Spalte ngen gibt man die Zahl der Generationen an, die von
der Logdatei aufbewahrt werden sollen. Der Eintrag 10 dort
bedeutet, daß 10 Generationen (logfile.0 bis
logfile.9) aufbewahrt werden.
Das * bei size signalisiert, daß die Rotation
unabhängig von der Dateigröße zu einem festgesetzten Zeitpunkt
geschieht - der mit 24 (für 24 Stunden) in der folgenden
Spalte angegeben wird.
In der letzten Spalte ( flags) kann man schließlich noch
weitere Optionen angeben. Die Angabe von Z dort bewirkt, daß die
alten Logfiles in komprimierter Form platzsparend aufbewahrt werden.
Nähere Details zur Syntax und zu weiteren Optionen sind in der guten Manpage unter man 8 newsyslog nachzulesen.
-> Nach oben ClientkonfigurationExim auf den ClientrechnernUnser 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: SMTPManche 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. Zuerst muß natürlich auch auf den Client-Rechnern Exim installiert werden: root@host:~> cd /usr/pkgsrc/mail/exim/ root@host:/usr/pkgsrc/mail/exim/> make installNun kann man daran gehen, die Konfigurationsdatei /usr/pkg/etc/exim/configure
entsprechend anzupassen:
######################################################################
# MAIN CONFIGURATION SETTINGS #
######################################################################
# Der primary_hostname ist der sogenannte FQDN des Systems, d.h. der
# komplette Name, wie er nach aussen sichtbar ist. Aufgebaut ist er
# nach dem Muster rechnername.domain.tld
# Wer keine eigene Domain registriert hat, kann auch z.B. bei
# DynDNS (http://www.dyndns.org) kostenlos eine Subdomain nutzen.
# Der entsprechende FQDN lautet dann z.B. rechnername.subdomain.dyndns.org
#
primary_hostname = client.subdomain.dyndns.org
# Hier werden die lokalen Domains angegeben, d.h. alle Adressen, fuer
# die Mails angenommen und lokal zugestellt werden. Die Angabe "@"
# ist gleichbedeutend mit dem "primary_hostname"
#
domainlist local_domains = @
# Wer seinen Server als Relay fuer eine andere Domain konfigurieren
# moechte, fuer den ist diese Option wichtig. Alle anderen sollten
# hier auf keinen Fall irgendetwas eintragen, da der Rechner sonst als
# sogenanntes offenes Relay von Spammern missbraucht werden koennte!
#
domainlist relay_to_domains =
# In diesem Beispiel soll der zentrale Mailserver alle Mails aus dem lokalen
# Netz (Adressen nach dem Muster 192.168.1.x) annehmen und ins Internet
# weiterverteilen. Die einzelnen Client-Rechner sollen hingegen nur lokal
# auf dem jeweiligen Rechner (127.0.0.1) verschickte Mails annehmen.
#
hostlist relay_from_hosts = 127.0.0.1
# Eine sogenannte "unqualified address" ist eine Mailadresse, die hinter dem
# Benutzernamen kein "@domain" besitzt. Exim mag das nicht, und so sollte
# diese Option entsprechend dem FQDN des Rechners gesetzt werden, auch wenn
# der Versand in diesem Beispiel mit voellig anderen Absender-Adressen
# (z.B. von GMX oder Arcor) erfolgen wird.
#
qualify_domain = client.subdomain.dyndns.org
# Um Verzoegerungen zu vermeiden, wenn kein Nameserver verfuegbar ist (weil
# der Server z.B. offline ist), empfiehlt sich folgende Einstellung, bei
# der die DNS-Lookups abgeschaltet werden
#
host_lookup =
# Hier gilt aehnliches wie beim letzten Punkt; um Verzoegerungen und
# Probleme durch Firewalls zu vermeiden, wird in diesem Beispiel die
# Nutzung des ident-Dienstes (RFC1413) durch Exim abgeschaltet
#
rfc1413_hosts =
rfc1413_query_timeout = 0s
# Mailclients, die ihre Mail nicht ueber SMTP an den lokalen MTA ausliefern,
# sondern dazu den Alias /usr/sbin/sendmail verwenden, duerfen normalerweise
# die Absenderadresse nicht frei waehlen. Stattdessen wird
# benutzername@fqdn als Absender gesetzt und evtl. noch entsprechend den
# gesetzten Filterregeln umgeschrieben.
# Wer aber Mailprovider wie z.B. GMX oder Arcor nutzt, wird auch seine dortige
# Adresse als Absender angeben wollen. Dazu dient folgende Option, die es
# allen Benutzern erlaubt, beliebige Absender-Adressen zu verwenden.
#
untrusted_set_sender = *
# Als "lokal" werden die Interfaces bezeichnet, auf denen Exim Mail entgegen-
# nehmen und ohne Beschraenkung weiterverteilen soll. Auf den Client-Rechnern
# sollte dies auf das lokale Interface 127.0.0.1 beschraenkt sein.
#
local_interfaces = 127.0.0.1
(...)
######################################################################
# ROUTERS CONFIGURATION #
# Specifies how addresses are handled #
######################################################################
# THE ORDER IN WHICH THE ROUTERS ARE DEFINED IS IMPORTANT! #
# An address is passed to each router in turn until it is accepted. #
######################################################################
begin routers
(...)
# Wenn alle User des Client-Systems einen Mail-Account auf dem
# lokalen IMAP-Server haben und ihre Mails nur dort lesen, ist es
# sinnvoll, alle lokalen Mails in das IMAP-Postfach zu leiten
#
#localuser:
# driver = redirect
# check_local_user
# data = ${quote:$local_part}@lokaler-server.subdomain.dyndns.org
# cannot_route_message = Unknown user
#
# Falls diese Mails doch lieber weiterhin lokal auf dem Client-Rechner
# zugestellt werden sollen, ist stattdessen folgende Eintrag korrekt
#
localuser:
driver = accept
check_local_user
transport = local_delivery
cannot_route_message = Unknown user
# Alle Mails nach "draussen" werden ueber den internen Mailserver
# verschickt.
#
smarthost:
domains = ! +local_domains
driver = manualroute
transport = remote_smtp
route_list = "* lokaler-server.subdomain.dyndns.org"
host_find_failed = defer
no_more
(...)
Die Exim-Konfigurationsdatei ist damit fertig. Eine komplette Beispiel-Konfigurationsdatei
für dieses Setup kann heruntergeladen werden unter
http://home.arcor.de/hm-gerhards/download/netbsd_imap/exim_client.conf
Die meisten der in dieser Konfigurationsdatei aufgeführten Abschnitte wurden weiter oben bereits im Rahmen der Server-Konfiguration ausführlich beschrieben. Ich werde daher nur noch auf ein paar Besonderheiten eingehen. Hauptaufgabe der Exim-Clients ist es, Mails vom lokalen Rechner entgegenzunehmen und an den zentralen Mail-Server zu senden, der dann alle nach "draussen" gehenden Mails aus dem lokalen Netzwerk ins Internet verschickt. Es gibt allerdings Mails, die auch lokal zugestellt werden sollen. Dazu gehören insbesondere Statusreport-Mails, z.B. Rückmeldungen von ausgeführten Cronjobs. Diese Mails werden vom localuser-Router normalerweise in das lokale Postfach
auf dem Client-Rechner zugestellt - was natürlich voraussetzt, daß dieses
Postfach auch von jemandem gelesen wird. Problematisch wird es, wenn nur noch die
IMAP-Postfächer auf dem Server gelesen und alle anderen lokalen Mailboxen nicht
beachtet werden.
Unter der Voraussetzung, daß alle Benutzer sowohl auf dem Client-Rechner als auch auf dem Server existieren und auf dem Server ein IMAP-Postfach besitzen, kann man mit einem kleinen Trick auch alle lokalen Mails vom Client-Rechner auf den Server umleiten. Dazu läßt man einfach vom localuser-Router den
Adressaten von benutzername[at]client umschreiben in benutzername[at]server
und die Mail wird entsprechend umgeleitet. In der Konfigurationsdatei sieht das dann konkret
folgendermaßend aus:
localuser:
driver = redirect
check_local_user
data = ${quote:$local_part}@lokaler-server.subdomain.dyndns.org
cannot_route_message = Unknown user
Wichtig ist dabei zum einen, daß auch alle Benutzer der Clients auf
dem Server existieren. Zum anderen ist aber auch wichtig, daß die Einträge
primary_hostname = lokaler-server.subdomain.dyndns.org domainlist local_domains = @auf dem Server korrekt gesetzt sind! Denn sonst erkennt der Server nicht, daß diese Mails lokal in die IMAP-Postfächer einsortiert werden sollen und versucht, sie ins Internet zu versenden. Weiter mit der Konfiguration des Exim-Clients geht es im Abschnitt Sendmail durch Exim ersetzen; die weiteren Schritte unterscheiden sich nicht von der Server-Konfiguration. -> Nach oben Mutt - ein Beispiel für einen IMAP-ClientEs 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 ServerDie 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:
# Persoenliche 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/pkg/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/pkg/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/pkg/bin/bogofilter -Sn -v"
# Fuer 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/pkg/bin/sa-learn --spam"
#
# Mails als "Ham" klassifizieren
macro index H "| ssh 192.168.1.1 /usr/pkg/bin/sa-learn --ham --no-sync"
#
# Mails zur Whitelist hinzufügen
macro index W "| ssh 192.168.1.1 /usr/pkg/bin/spamassassin -W"
#
# Datenbank des Bayes-Filters neu erzeugen
macro index R "| ssh 192.168.1.1 /usr/pkg/bin/sa-learn --sync"
# 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. Läßt man sich alle lokalen Mails wie weiter
oben beschrieben in sein IMAP-Postfach weiterleiten, kann man diesen Eintrag auch auf
mailboxes +INBOX verkürzen.
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, oder man untrusted_set_sender = *
gesetzt hat, 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 |
| Zugriffe auf diese Seite |
Letzte Änderung: 16.5.2005 by Hans-Michael Gerhards (HM-Gerhards@gmx.de)