AndreasStricker

rapidmax@gmx.net

2006-01-23 1.0 2006-01-23 andy first official release Installation eines full-featured Mailserver basierend auf Debian/Sarge Debian Sarge Postfix Sieve Cyrus IMAP SASL SMTP AUTH Bogofilter Webmail Dieses HOWTO ist noch nicht offiziell freigegeben. U.a. sind noch sehr viele Rechtschreibfehler enthalten. Im Folgenden ist ein Rezept für einen SOHO Mailserver basierend auf Debian Sarge konfiguriert wird. Folgende Ziele wurden gesetzt: Der Mailserver sollte vom Internet aus mit SMTP erreichbar sein Relaying wird über SASL SMTP AUTH Authentizierung erlaubt Die Mails bleiben auf dem Server in einem Maildir und müssen über IMAP zur Verfügung gestellt werden Der Server braucht eine Schnittstelle um eingehende Mails auf Viren und Spam zu überprüfen Jeder User soll in der Lage sein, Filter zu definieren, welche direkt beim Empfang angewendet werden, wenn möglich über ein konfortables Web-Interface Zusätzlich soll ein Web-Mail-Interface Intra- und Internet-seitig vorhanden sein. Alternativ sollte es auch möglich sein Internetseitig auf den IMAP-Server zuzugreiffen Sämtliche Internet-seitige Kommunikation sollte mit TLS vor Abhörversuchen gesichert sein Nur offizielle Debian-Pakete aus dem Sarge-Zweig verwenden, um eine einfache Pflege sicherzustellen Der Author schlägt vor, Schritt-für-Schritt vorzugehen. Zuerst ein einfacher Server einrichten und sukzsessiv neue Funktionen hinzufügen und Testen. Aufgrund des Risiko, von einem Spammer als Spam-Schleuder missbraucht zu werden, sollte alles in einem geschützen Netzwerk konfiguriert werden. Die Öffnung gegenüber dem Internet soll erst dann erfolgen, wenn man sich (durch Tests) sicher ist, dass der Server nicht als open Relay missbraucht werden kann. Vielen Dank für die Beiträge von Ranko Veselinovic rvjunior(at)gmx(dot)net Bjoern Schiessle bes(at)schiessle(dot)org This work is licensed under the Creative Commons Attribution-ShareAlike 2.0 Germany License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.0/de/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. Namensnennung-Weitergabe unter gleichen Bedingungen 2.0 Deutschland den Inhalt vervielfältigen, verbreiten und öffentlich aufführen Bearbeitungen anfertigen den Inhalt kommerziell nutzen Namensnennung. Sie müssen den Namen des Autors/Rechtsinhabers nennen. Weitergabe unter gleichen Bedingungen. Wenn Sie diesen Inhalt bearbeiten oder in anderer Weise umgestalten, verändern oder als Grundlage für einen anderen Inhalt verwenden, dann dürfen Sie den neu entstandenen Inhalt nur unter Verwendung identischer Lizenzbedingungen weitergeben. Im Falle einer Verbreitung müssen Sie anderen die Lizenzbedingungen, unter die dieser Inhalt fällt, mitteilen. Jede dieser Bedingungen kann nach schriftlicher Einwilligung des Rechtsinhabers aufgehoben werden. Die gesetzlichen Schranken des Urheberrechts bleiben hiervon unberührt. Das Commons Deed ist eine Zusammenfassung des Lizenzvertrags in allgemeinverständlicher Sprache. Die Installation ist schnell beschrieben, verlassen wir uns doch ausschliesslich auf Debian/Sarge Pakete. Ich liste hier nur die Paket, welche zu installieren sind, und nicht alle, welche automatisch durch die Abhängigkeiten nachgezogen werden. postfix, postfix-tls, postfix-doc Der eigentliche MTA, zwingend notwendig. Die TLS Version ist für SMTP mit Starttls notwendig, das Documentations-Paket empfielt sich zusätzlich zu diesem Dokument hier. cyrus21-admin, cyrus21-imapd, cyrus21-doc, cyrus21-clients Der IMAP4 Server. Auch hier empfiehlt sich das Dokumentationspaket. Das clients-Paket enthält Test-Werkzeuge, die bei Problemen nützlich sein können. Im Admin-Paket sind neben cyradm (Sir-Adam) auch die sieveshell für die Verwalung der Filter auf der Kommandozeile. Das Sieve wird durch Cyrus automatisch mitinstalliert sasl2-bin, libsasl2, libsasl2-modules, libsasl2-modules-gssapi-heimdal, libsasl7 Das Authentizierungsmodul für Cyrus und auch Postfix, falls SMTP AUTH gewünscht ist. Die Module enthalten verschiedenen Authentizierungs-Backends, das bin-Paket den saslauthd Daemon und einige nützliche Test-Werkzeuge fetchmail, fetchmail-ssl Diese Pakete empfehlen sich für das Abholen von Mails von Accounts, welche keine Weiterleitung ermöglichen. ssl-cert, ca-certificates Empfehlen sich, wenn man TLS einsetzen will. bogofilter Erspart uns haufenweise Spam procmail Obwohl für das Verteilen der Mails auf die Postfächer Sieve zuständig ist, kann procmail eingesetzt werden kompliziertere Filterung der Mail vorzunehmen apache2, apache2-utils Notwendig wenn die Filteregeln über das Web angepasst werden sollen, oder Web-Mail gewünscht ist. libapache2-mod-php4 Das Horde-Framework basiert auf PHP. horde3, imp4, ingo1 Das Horde Framework, mit dem Webmailer IMP und der Web-Mailfilter-Verwaltung Ingo postgresql, postgresql-client, postgresql-doc Wird als Datenbank-Backend für Horde verwendet phppgadmin Vereinfacht die Administration der Datenbank durch ein konfortables Web-GUI Hier nochmal eine Liste mit den relevanten Paketen für die Installation: apache2 install apache2-common install apache2-mpm-prefork install apache2-utils install bogofilter install ca-certificates install cyrus21-admin install cyrus21-clients install cyrus21-common install cyrus21-doc install cyrus21-imapd install fetchmail install fetchmail-ssl install horde3 install imp4 install ingo1 install libapache2-mod-php4 install libgssapi1-heimdal install libsasl2 install libsasl2-modules install libsasl2-modules-gssapi-heimdal install libsasl7 install openssl install php-date install php-file install php-mail-mime install php-net-sieve install php4-cli install php4-common install php4-domxml install php4-gd install php4-imap install php4-mcrypt install php4-mhash install php4-pgsql install phppgadmin install postfix install postfix-doc install postfix-tls install postgresql install postgresql-client install postgresql-doc install procmail install sasl2-bin install tnef install vacation install Ich fange mit einer Minimal-Konfiguration an und baue diese dann laufend aus. Im ersten Schritt wird die Konfiguration für Postfix unter /etc/postfix für den ersten Schritt angepasst. Ich empfehle die dort vorhandene main.cf umzubenennen und durch den im Folgenden vorgestellen Inhalt zu ersetzen. Die master.cf wird nur minimal geändert, daher hier eine Sicherheitskopie erstellen. Nehmen wir uns also die main.cf vor: # ---------------------------------------------------------------------------- # Network specific settings # ---------------------------------------------------------------------------- # We say hello by presenting this banner (but not too much!) smtpd_banner = $myhostname ESMTP $mail_name # appending .domain is the MUA's job. append_dot_mydomain = no # group for mail submission an queue management commands setgid_group = postdrop # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h myhostname = sirius.hogwarts.local mynetworks_style = host #mynetworks = 127.0.0.0/8, 192.168.99.0/24 mynetworks = 127.0.0.0/8 myorigin = /etc/mailname mydestination = $myhostname, sirius, localhost.$mydomain, localhost inet_interfaces = all # Database locations alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases #sender_canonical_maps = hash:/etc/postfix/sender_canonical #smtpd_sender-restrictions = hash:/etc/postfix/access # ---------------------------------------------------------------------------- # Transport settings # ---------------------------------------------------------------------------- # we can't send directly to some mail server because our typical dynamic # revers lookup-address, so we relay mails over our ISP relayhost = [mail.shinternet.ch] mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp #mailbox_transport = cyrus #local_transport = procmail #mailbox_command = procmail -t -a "$EXTENSION" mailbox_command = mailbox_size_limit = 0 recipient_delimiter = + # no mail notification biff = no myhostname: Setzen wir auf den FQDN des Server, sinnvollerweise den internen Hostname. mynetworks: Wird hier nur auf das Loopback Netz gesetzt, da wir uns grundsätzlich für das Relaying authentizieren wollen. Für den ersten Test sollte hier aber zumindest noch das lokale Netz hinzugefügt werden, wie im auskommentieren Teil. myorigin: Muss auf den Hostnamen gesetzt werden. Hier wird er aus der Datei /etc/hostname gelesen, welche natürlich angelegt werden muss! (echo "sirius.hogwarts.local" > /etc/mailname mydestination: Bestimmt für welche Domains sich der Mailserver als Empfänger sieht. Sollte bei Virtual Hosts auf keinen fall einen Host enthalten, welcher als Virtual Host gelistet sein wird. Ich empfehle hier wirklich nur localhost und die lokale Domain einzutragen. inet_interfaces: Damit wird der Server auf bestimmte Interfaces gebunden, auf denen er hören soll (oder auch eben nicht), Hier wird der Server an alle Interfaces gebunden. alias_maps: Zeigt auf /etc/aliases.db, welche im Minimum root: localuser enthalten sollte relayhost: Wenn diese Option leer ist, versendet Postfix alle Mails direkt. Wird ein SMTP Server angegeben, so wird dieser Server als Relayhost verwendet. Die eckigen Klammern verhindern das auflösen der MX Records mailbox_transport: Bestimmt die Art der lokalen Mail Auslieferung. In diesem Beispiel hier wird direkt auf ein LMTPSocket geschrieben. Oft wird hier aber nur ein Name angegeben, welcher auf einen Eintrag (Transport) in der master.cf passt. Noch ein paar Anmerkungen: relayhost kann für Testzwecke leer gelassen werden, damit verschickt der Server die Mails direkt. Ist der Mailserver nicht an einer statischen Adresse und hat er womöglich auch noch einen Reverse-DNS-Lookup der auf dynamische Bereiche schliessen lässt, so empfehle ich hier den SMTP Server des Providers einzutragen. Sonst kann es vorkommen, dass gewisse Server die Annahme von Mails grundsätzlich verweigern, da sie einen Spam-Bot-Rechner vermuten. Besitzer von Statischen IPs mit korrekt eingerichtetem Reverse-Lookup sind hier fein raus. Ein weiterer Punkt, der Schwierikeiten macht, ist der LMTP Socket, spezifiziert mit mailbox_transport. Hier müssen die Rechte angepasst werden, sonst kann Postfix, welcher unter einer anderen UID als Cyrus läuft nicht in den Socket schreiben. Wichtig ist, dass nicht die Rechte des Socket zum tragen kommen, sondern die des Verzeichnis /var/run/cyrus/socket. Dieses gehört dem User Cyrus und der Gruppe lmtp. Postfix ist zu dieser Gruppe hinzuzufügen: useradd postfix lmtp. Für den Test empfehle ich direkt mit netcat oder telnet auf den SMTP Port zu verbinden. Dazu ist ein kleines Studium von RFC821 zu empfehlen, aber es geht auch ohne. 220 sirius.hogwarts.local ESMTP Postfix HELO andy.hogwarts.local 250 sirius.hogwarts.local MAIL FROM: <> 250 Ok RCPT TO: <andy@sirius.hogwarts.local> 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> Subject: Test from netcat Body . 250 Ok: queued as 04C43D3CA QUIT 221 Bye In diesem Beispiel stellte man sich mit einem einfachen HELO mit seinem Hostname vor (wird verlangt!). Als nächstes leitet man eine neue Mail ein mit MAIL FROM. Hier kann die eigenen Mail-Adresse angegeben werden oder auch nicht. Gewisse Server verlangen zwar mittlerweile aus Spam-Schutz-Gründen hier eine Mail-Adresse, unser Server ist aber noch nicht so streng konfiguiert. Schliesslich teilen wir dem Mailserver mit RCPT TO mit, welchen Empfänger wir kontaktieren wollen, worauf der Server mit 250 Ok und einem darauf folgenden DATA antworten soll, wenn eine lokale Adressen angegeben wurde. Oder der Server antwortet mit mit 554 <foo.bar@spam.baz>: Relay access denied, falls eine externe Adresse angegeben wurde und es dem Client nicht erlaubt ist zu Relayen. Viel interessanter als ein simples HELO ist das etwas nach Vertipper aussehende EHLO. Dieses listet alle Features auf, welcher der Server unterstützt. 220 sirius.hogwarts.local ESMTP Postfix EHLO andy.hogwarts.local 250-sirius.hogwarts.local 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250 8BITMIME In diesem Beispiel aus der finalen Konfiguration (ja, ich will es etwas schmackhaft machen...), erkennt man, dass der Server TLS (SSL), SMTP AUTH und ETRN unterstützt, die maximale Grösse auf 10MB festgelegt hat und zudem 8-bittige Mails unterstützt. (Was man auch sieht, ist dass der Server keine vermurkste Outlook Syntax für SMTP AUTH unterstützt, aber nicht, dass dies Absicht ist }-> ) In diesem Moment wird es möglich sein, Mails abzuschicken, aber sie werden noch nicht bei Cyrus landen. Die Mail Queue postqueue -p wird noch einige hängen gebliebene Mails anzeigen. Weitere Informationen sind im Logfile /var/log/mail.log zu entdecken. Der Grund ist, dass noch keine Mailboxen in Cyrus angelegt wurden. Erfreulicherweise ist die master.cf bereits vorkonfiguriert, so dass für die ersten Experimente keine Änderungen notwendig sind. Hier dennoch ein Auszug der wichtigsten Transporte, ohne die per default vorhandenen Einträge für externe Software. smtp inet n - n - - smtpd pickup fifo n - - 60 1 pickup cleanup unix n - - - 0 cleanup qmgr fifo n - - 300 1 qmgr rewrite unix - - - - - trivial-rewrite bounce unix - - - - 0 bounce defer unix - - - - 0 bounce trace unix - - - - 0 bounce verify unix - - - - 1 verify flush unix n - - 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - - - - smtp relay unix - - - - - smtp showq unix n - - - - showq error unix - - - - - error local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil Noch ein Wort zu diesen Einträgen: Diese werden als Transports bezeichnet. Die oben gelisteten Transporte sind Postfix-Intern und sollten nur verändert werden, wenn man genau weiss, was man tut (zumindest bei einem werden wird das später machen). Die Einträge für externe Software sind inaktive, da diese explizit ausgewählt werden müssen. Das geschieht über die Parameter mailbox_transport und local_transport in der main.cf. Wie wir oben gesehen haben, verwenden wir nur den Parameter mailbox_transport und referenzieren dort nicht auf einen der Transporte, sondern direkt auf einen LMTP Unix Socket. Das ist die empfohlene Variante für die Übergabe der Mails an Cyrus. In vielen Älteren Dokumenten sieht man häufig die Verwendung eines Transports der etwas so ausschaut: cyrus unix - n n - - pipe flags=R user=cyrus argv=/usr/sbin/cyrdeliver -e -m ${extension} ${user} Das ist aber sinnlos, da cyrdeliver nichts anderes macht, als die Mails in den LMTP Socket zu schreiben. Will man procmail einsetzen, so wendet man einen Transport an, der etwa so aussieht: procmail unix - n n - - pipe flags=R user=cyrus argv=/usr/bin/procmail -p /etc/procmailrc USER=${user} EXTENSION=${extension} procmail wird dann so konfiguriert, dass es zur Auslieferung cyrdeliver einsetzt. Wie wir später sehen werden, ist es viel konfortabler auf Sieve zu setzen um die Mails auf die einzelnen Unterverzeichnisse zu verteilen. Zudem ist es auch ineffizient, für jede Mail zwei Prozesse zu spawnen. Allerding gibt es durchaus sinnvolle Möglichkeiten procmail hier einzusetzen. Ich denke da an einen Filter für benutzerunabhängige Filterung der Mails auf Spam, Vieren und eigenen Regeln. Wir haben in Unserem SOHO-Szenario zwei DNS-Namen für unseres System. Den bisher konfigurierten und verwendeten Internen Namen sirius.hogwarts.local und eine externe Domain rapidmax.homelinux.net. Diese soll nun als virtueller Host hinzugefügt werden. Wichtig ist vor allem, dass der Name nicht in mydestination aufgeführt ist. virtual_alias_domains = rapidmax.homelinux.net virtual_alias_maps = hash:/etc/postfix/virtual In der Option virtual_alias_domains werden einfach die Domains gelistet. In der Datei /etc/postfix/virtual werden schlussendlich die Namen auf die internen Usernamen gemappt. Man soll darauf achten, entweder eine Catch-All Regel einzurichten, oder sonst zumindest die nach RFC 2142 vorgeschriebenen Namen. Nachdem das erledigt ist, mittels postmap /etc/postfix/virtual eine Hash-Tabelle generieren. Bei Änderungen nicht vergessen das zu wiederholen! Diese Konfigurationsdatei ist direkt in /etc/imapd.conf zu finden. Auch diese Datei ist sinnvoll vorkonfiguriert, so dass es hier für erste Experimente nicht viel zu ändern gibt. Hier zuerst mal die Konfigurationsdatei: configdirectory: /var/lib/cyrus defaultpartition: default partition-default: /var/spool/cyrus/mail partition-news: /var/spool/cyrus/news newsspool: /var/spool/news altnamespace: no unixhierarchysep: no admins: cyrus allowanonymouslogin: no popminpoll: 1 autocreatequota: 0 umask: 077 sieveusehomedir: false sievedir: /var/spool/sieve hashimapspool: true allowplaintext: yes sasl_pwcheck_method: auxprop sasl_auto_transition: no lmtpsocket: /var/run/cyrus/socket/lmtp idlesocket: /var/run/cyrus/socket/idle notifysocket: /var/run/cyrus/socket/notify Es scheint langsam langweilig zu werden, trotzdem muss ich auch hier auf die bereits vorhandene Default-Konfguration verweisen, welche fast im Urzustand gelassen werden kann. START { recover cmd="/usr/sbin/ctl_cyrusdb -r" delprune cmd="/usr/sbin/ctl_deliver -E 3" tlsprune cmd="/usr/sbin/tls_prune" } SERVICES { imap cmd="imapd -U 30" listen="imap" prefork=0 maxchild=100 #pop3 cmd="pop3d -U 30" listen="pop3" prefork=0 maxchild=50 lmtpunix cmd="lmtpd" listen="/var/run/cyrus/socket/lmtp" prefork=0 maxchild=20 sieve cmd="timsieved" listen="localhost:sieve" prefork=0 maxchild=100 notify cmd="notifyd" listen="/var/run/cyrus/socket/notify" proto="udp" prefork=1 } EVENTS { checkpoint cmd="/usr/sbin/ctl_cyrusdb -c" period=30 delprune cmd="/usr/sbin/ctl_deliver -E 3" at=0401 tlsprune cmd="/usr/sbin/tls_prune" at=0401 } Man beachte das ausgeklammerte pop3. Damit Cyrus funktioniert, musst mit saslpasswd ein Benutzer zur SASL-eigenen Benutzerdatenbank /etc/sasldb2 hinzugefügt werden: # saslpasswd -c cyrus Password: Again (for verification): # saslpasswd -c myself Password: Again (for verification): Für diesen Benutzer muss natürlich auch eine Mailbox erstellt werden. Das kann mit dem cyrus-Login geschehen: # cyradm -u cyrus localhost IMAP Password: localhost> help ... localhost> lm localhost> cm user.myself localhost> lm user.myself (\HasNoChildren) localhost> exit Man achte auf den Prefix user: Es ist wichtig, alle Benutzer-Mailboxen unterhalb des Namespace user anzulegen. Im nächsten Schritt versuchen wir eine Mail durch Postfix an Cyrus auszuliefern. Im folgenden sehen wir das Testmail, vom Postfix Test, wie es im Cyrus angekommen ist. Return-Path: <> Received: from sirius.hogwarts.local ([unix socket]) by sirius (Cyrus v2.1.18-IPv6-Debian-2.1.18-1) with LMTP; Mon, 23 Jan 2006 23:54:43 +0100 X-Sieve: CMU Sieve 2.2 Received: by sirius.hogwarts.local (Postfix, from userid 103) id 1DCA8D416; Mon, 23 Jan 2006 23:54:43 +0100 (CET) Received: from andy.howarts.local (andy.hogwarts.local [192.168.1.8]) by sirius.hogwarts.local (Postfix) with SMTP id 04C43D3CA for <andy@sirius.hogwarts.local>; Mon, 23 Jan 2006 23:54:04 +0100 (CET) Subject: Test from netcat Message-Id: <20060123225404.04C43D3CA@sirius.hogwarts.local> Date: Mon, 23 Jan 2006 23:54:04 +0100 (CET) From: MAILER-DAEMON@sirius.hogwarts.local To: undisclosed-recipients: ; X-Bogosity: Unsure, tests=bogofilter, spamicity=0.530418, version=0.94.4 Body Um das Mail abzuholen konfigurieren wir einen belieben Mail-Client auf IMAP4 über den Server auf Port 143. Wie immer sind Fehlermeldungen in /var/log/mail.log zu finden: postfix/smtpd: connect from andy.hogwarts.local[192.168.1.8] postfix/smtpd: 20B0ED3CA: client=andy.hogwarts.local[192.168.1.8] postfix/cleanup: 20B0ED3CA: message-id=<20060125235602.20B0ED3CA@sirius.hogwarts.local> postfix/qmgr: 20B0ED3CA: from=<>, size=406, nrcpt=1 (queue active) postfix/pipe: 20B0ED3CA: to=<andy@sirius.hogwarts.local>, relay=bogofilter, delay=58, status=sent (sirius.hogwarts.local) postfix/qmgr: 20B0ED3CA: removed postfix/pickup: BCBDBD416: uid=103 from=<MAILER-DAEMON@sirius.hogwarts.local> postfix/cleanup: BCBDBD416: message-id=<20060125235602.20B0ED3CA@sirius.hogwarts.local> postfix/qmgr: BCBDBD416: from=<>, size=620, nrcpt=1 (queue active) cyrus/master: about to exec /usr/lib/cyrus/bin/lmtpd cyrus/lmtpunix: executed cyrus/lmtpd: accepted connection cyrus/lmtpd: lmtp connection preauth'd as postman cyrus/lmtpd: duplicate_check: <20060125235602.20B0ED3CA@sirius.hogwarts.local> user.andy 0 cyrus/lmtpd: mystore: starting txn 2147483687 cyrus/lmtpd: mystore: committing txn 2147483687 cyrus/lmtpd: duplicate_mark: <20060125235602.20B0ED3CA@sirius.hogwarts.local> user.andy 1138233421 cyrus/lmtpd: mystore: starting txn 2147483688 cyrus/lmtpd: mystore: committing txn 2147483688 cyrus/lmtpd: duplicate_mark: <20060125235602.20B0ED3CA@sirius.hogwarts.local> .andy+.sieve. 1138233421 postfix/lmtp: BCBDBD416: to=<andy@sirius.hogwarts.local>, relay=/var/run/cyrus/socket/lmtp[/var/run/cyrus/socket/lmtp], delay=1, status=sent (250 2.1.5 Ok) postfix/qmgr: BCBDBD416: removed postfix/smtpd: disconnect from andy.hogwarts.local[192.168.1.8] Besondere Beachtung sollte der drittletzten Zeile geschenkt werden. Im Parameter relay steht oft der Grund, weshalb das Mail nicht an Cyrus übergeben werden konnte: Hier ein Beispiel bei dem es nicht geklappt hat, weil postfix noch keine Rechte gegeben wurden, auf den Socket zuzugreiffen: postfix/lmtp: 96860D3FC: to=<andy@sirius.hogwarts.local>, relay=none, delay=3769, status=deferred (connect to /var/run/cyrus/socket/lmtp[/var/run/cyrus/socket/lmtp]: Permission denied) Zuerst am Anfang: Das in einigen Dokumenten erwähnte pwcheck ist veraltet und wurde durch saslauthd ersetzt. Damit haben wir die Wahl zwischen auxprop und saslauthd. Während ersteres mit einer eigenen Passwort-Datenbank arbeitet, lässt sich bei saslauthd zwischen pam, shadow und der sasldb wie bei auxprop wählen. Nun mag man sich Fragen, wieso auxprop überhaupt noch notwendig ist. Die Notwendigkeit liegt darin, dass in derSASL-eigenen Datenbank die Passwörter im Klartext liegen und daher Authentizerungsmechanismen zur Verfügung stehen, welche das Passwort nicht im Klartext über die Leitung schicken, während saslauthd nur Plaintext-Mechanismen unterstützt. In diesem Beispiel werden wir saslauthd einsetzen, um die normalen Systemaccounts einzusetzen. Das vereinfacht Verwaltung, die Passwörter sind nur einmal einzugeben für Remote-Login, IMAP und SMTP AUTH. Den Nachteil mit der Beschränkung auf Plaintext Mechanismen gleichen wir dann später aus, indem wir den Kanal mit TLS verschlüsseln. Um in Debian den saslauthd als Daemon laufen zu lassen, muss die Datei /etc/default/saslauthd editiert werden: START=yes MECHANISM="shadow" Zum Schluss kann die korrekte Funktion des Daemon mit dem Befehl testsaslauthd verifiziert werden: testsaslauthd -u myself -p secret worauf eine Meldung wie 0: OK "Success." im Erfolgsfall und 0: NO "authentication failed" im Fehlerfall erscheinen soll. Vorausgesetz der saslauthd läuft, kann Cyrus auf diesen Umgestellt werden. Dazu passen wir die Konfigurationsdatei /etc/imapd.conf wie folgt an: sasl_mech_list: PLAIN sasl_pwcheck_method: saslauthd sasl_auto_transition: no Damit sollte man sich bei Cyrus bereits mit dem Systemaccount anmelden können. Oh, halt, etwas haben wir noch vergessen! Weisen wir erst noch Cyrus an, die Konfiguration neu einzulesen: invoke-rc.d cyrus21 reload. Auch hier sind nützliche Fehlermeldungen im Logfile zu finden. Es gilt zu beachten, dass es zwei Gruppen von Optionen hat, die sich sehr ähnlich sehen: smtpd_sasl_* und smtp_sasl_*. Die Variant ohne das Daemon-d nach smtp ist für den SMTP Client, als den Teil der Verbindung zu fremden Server aufnimmt und sich dort ev. authentizieren muss. Dementsprechend ist die andere smtpd-Variante für unser gewünschter SMTP AUTH zuständig. Das sehen wir uns zuerst an. In der Datei main.cf müssen folgende Einträge hinzugefügt werden: smtpd_sasl_auth_enable = yes smtpd_sasl_application_name = smtpd #broken_sasl-auth_clients = yes smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous smtpd_sasl_application_name definiert den Namen für die SASL-Konfiguration-Datei. Die auskommentierte Option broken_sasl_auth_clients kann dann einkommentiert werden, wenn aus unvermeidbaren Gründen Microsoft Outlook eingesetzt werden soll. Schliesslich die Option smtpd_sasl_security_options auf noanonymous gesetzt stellt sicher, dass keine Anonyme Logins möglich sind. Noch ist SASL SMTP AUTH nicht aktiv. Es wird durch hinzufügen der Option permit_sasl_authenticated zur Option smtpd_recipient_restrictions aktiviert. Diese Option ist momentan noch nicht präsent, daher hier in kompletter Form: smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination Diese Konfiguration bewirkt, dass sich nicht an RFC haltende Clients rejected werden, alle in mynetworks eingetragenen Ranges erlaubt werden, als nächstes erfolgreich mit SMTP AUTH authentizierte Clients abenfalls erlaubt werden und zum Schluss alles abgelehnt wird, was nicht an lokale Domains gerichtet ist und nicht in den Relay Domain gelistet wurde. Damit ist die Konfiguration noch nicht abgeschlossen. Als nächstes erstellen wir ein Unterverzeichnis im Postfix Ordner /etc/postfix/sasl. Wir haben oben den Wert der Option smtpd_sasl_application_name auf den Wert smtpd gesetzt. Daher ist eine Konfigurationsdatei mit den Namen /etc/postfix/sasl/smtpd.conf mit folgendem Inhalt zu erstellen: log_level: 5 pwcheck_method: saslauthd mech_list: PLAIN LOGIN Wie schon bei Cyrus haben wir hier die Auswahl zwischen saslauthd und auxprop für die Option pwcheck_method. Man beachte das beim Einsatz von saslauthd nur Plain-Mechanismen Funktionieren und daher die Option mech_list entsprechend eingegrenzt werden muss. Nun schauen wir noch kurz die smtp_sasl_* Optionen an. Diese wird man vermutlich nur in dem Fall anwenden, wenn die Mail an den Mailserver des Providers zum Relaying weitergereicht werden und dieser eine Authentizierung verlangt. In diesem Fall fügt man die folgenden Optionen zur main.cf hinzu. smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd In der Datei /etc/postfix/sasl_passwd trägt man Benutzername, Tab und Passwort ein. Danach ist mit postmap /etc/postfix/sasl_passwd die Hashtabelle zu generieren. Aus sicherheitsgründen sollen diese Dateien root gehören und mit den Rechten 0600 (-rw-------) ausgestattet sein. Einmal eingerichtet folgt der Test der Konfiguration. Dieser wird am besten wieder direkt mit dem Server im Dialog getestet. 220 sirius.hogwarts.local ESMTP Postfix EHLO andy.hogwarts.local 250-sirius.hogwarts.local 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250 8BITMIME AUTH PLAIN dXNlcgB1c2VyAHBhc3N3b3Jk 535 Error: authentication failed AUTH PLAIN dXNlcgB1c2VyAGdlaGVpbQ== 235 Authentication successful Einige mögen sich nun wundern, wass der Zeichensalat nach AUTH PLAIN zu bedeuten hat. Dieser Teil ist der Base64-codierte Benutzername und Passwort in der Form: username ZERO username ZERO password wobei ZERO das Null-Zeichen mit ASCII-Wert 0x00 ist, welches üblichweise in der Form '\0' in Strings geschrieben wird. Die Kodierung in Base64 kann mit Python oder Perl erfolgen: $ python >>> from base64 import * >>> print encodestring('user\0user\0password') dXNlcgB1c2VyAHBhc3N3b3Jk >>> $ perl -MMIME::Base64 -e 'print encode_base64("user\0user\0password");' dXNlcgB1c2VyAHBhc3N3b3Jk Fehlermeldungen sind in den Logfiles zu finden. Der Spamfilter wird auf jede Mail angewendet, bevor diese an Cyrus weitergeleitet wird. Postfix bietet dazu den After-Queue Content Filter an. Die Mail wird dabei durch einen externen Filter-Prozess geschickt und danach wieder in die Queue zurückgeleitet. #!/bin/bash PATH=/bin:/usr/bin HOME=/var/run/bogofilter export PATH HOME SENDMAIL="/usr/sbin/sendmail" BOGOFILTER="/usr/bin/bogofilter" EX_TEMPFAIL=75 EX_UNAVAILABLE=69 cd $HOME $BOGOFILTER -p | $SENDMAIL -i "$@" exit $? echo $(pwd)/hambox | bogofilter -n -v -b echo $(pwd)/spambox | bogofilter -s -v -b Dieser Punkt sollte nicht ausser Acht gelassen werden. Schliesslich will man seine E-Mail nicht verlieren. Es stellt sich also die Frage was alles zu sichern ist. Um den Kompletten Status zu sichern, reicht es nicht das cyrus-Spoolverzeichnis zu sichern. Damit hat man zwar alle E-Mails, aber es fehlen Informationen zu den Mailboxen, den Abonnierlisten etc. Trotzdem ist es möglich, mit diesem Verzeichniss allein alle Mails wiederherzustellen. Mit Hilfe von reconstruct - unter Debian /usr/sbin/cyrreconstruct - kann die Datenbank wiederhergestellt werden. Default-Partition /var/spool/cyrus Weitere Partitionen Datenbank /var/lib/cyrus Sieve Scripts /var/spool/sieve Um Inkonsitenzen im Backup auszuschliessen, sollte Cyrus zuvor ausgeschaltet werden. Hier ein Beispiel für ein Backup-Script. #!/bin/bash if [ -z "$1" ]; then echo -e "Usage: $0 DIRECTORY" exit 1 fi BACKUPDIR="$1" if [ ! -d "$BACKUPDIR" ]; then echo -e "!!! $BACKUPDIR must be a directory" exit 1 fi TODAY=$(date -I) echo -e "*** Backup using ${BACKUPDIR}" su - cyrus -c "/usr/sbin/ctl_mboxlist -d" > $BACKUPDIR/mboxlist-$TODAY.txt cp /etc/imapd.conf $BACKUPDIR/imapd.conf.$TODAY cp /etc/cyrus.conf $BACKUPDIR/imapd.conf.$TODAY echo -e "*** Maildirs" tar --create --bzip2 \ --directory /var/spool \ --file $BACKUPDIR/cyrus-mail-$TODAY.tar.bz2 \ cyrus echo -e "*** Database directory" tar --create --bzip2 \ --directory /var/lib \ --file $BACKUPDIR/cyrus-lib-$TODAY.tar.bz2 \ cyrus echo -e "*** Sieve scripts" tar --create --bzip2 \ --directory /var/spool \ --file $BACKUPDIR/sieve-$TODAY.tar.bz2 \ sieve echo -e "*** Backup finished" Die Konfiguration und die Systemdateien sollte bereits mit dem Systembackup gesichert werden. Hier gibt es so viele Ansätze, dass ich gar nicht weiter darauf eingehen will. Geht es darum, die Konfiguration später wiederherzustellen, so sind folgende Dateien in Betracht zu ziehen: Postfix Konfiguration unter /etc/postfix, insbesondere main.cf und master.cf Cyrus Konfiguration, bestehend aus /etc/imapd.conf und /etc/cyrus.conf SASL Konfiguration, verteilt auf /etc/defaults/saslauthd und /etc/postfix/sasl