Ein eigener Webmailer ist nicht nur schick, sondern macht im Firmenbereich und auch für private Anwender Sinn. Zum Beispiel könnte man Mitarbeitern, die sich nicht im Firmennetz befinden, Zugriff auf Mails geben. Bei nicht fixen IP-Adressen ist auch ein Einsatz mit dyndns denkbar.
Die Konfiguration unserer Lösung haben wir erfolgreich mit SuSE Linux 9.2 getestet. Squirrelmail wird aber auch auf anderen Distributionen mitgeliefert, die Konfiguration sollte hier ähnlich ablaufen.
Das Prinzip des eigenen Webmailers ist denkbar einfach. Der Rechner holt die E-Mails der verschiedenen Accounts über IMAP oder POP3 ab und stellt sie ins Postfach des lokalen Benutzers. Das PHP-basierte Frontend Squirrelmail greift über das IMAP-Protokoll auf das lokale Postfach zu. Zum Versenden von E-Mails wird der lokale Mail Transfer Agent (MTA) genutzt. In diesem Workshop dient fetchmail zum Abholen der Mails, Dovecot als IMAP-Server, Apache2 als Webserver und Postfix als MTA.
Vorarbeiten
Zunächst ist es notwendig, einige Zusatzpakete zu installieren und zu konfigurieren.
apache2-2.0.50-7.3.i586.rpm
apache2-mod_php4-4.3.8-8.2.i586.rpm
apache2-prefork-2.0.50-7.3.i586.rpm
dovecot-0.99.11-2.1.i586.rpm
fetchmail-6.2.5-54.1.i586.rpm
libapr0-2.0.50-7.3.i586.rpm
mysql-shared-4.0.21-4.2.i586.rpm
php4-4.3.8-8.2.i586.rpm
php4-gettext-4.3.8-8.2.i586.rpm
php4-session-4.3.8-8.2.i586.rpm
postgresql-libs-7.4.6-0.1.i586.rpm
squirrelmail-1.4.2-59.1.noarch.rpm
Wir haben diese Dateien in einem Archiv für Sie hier zum Download bereitgestellt. Bei Suse 9.2 Professional sind diese Pakete auch im Lieferumfang erhalten und müssen eventuell nachinstalliert werden.
Mit
/etc/init.d/apache2 start
lässt sich der Webserver hochfahren.
Da das Webmail-Frontend via IMAP auf die Mails zugreift, ist mit
/etc/init.d/dovecot start
der IMAP-Daemon zu starten.
Bei einem Neustart des Rechners ginge die Daemon-Starterei von vorne los. Um diese lästige Prozedur zu vermeiden, trägt man die benötigten services mit
chkconfig apache2 35 dovecot 35
in die Runlevel 3 und 5 ein. Die Runlevels lassen sich alternativ auch über Yast konfigurieren.
User- und Firewall-Konfiguration
Der letzte vorbereitende Schritt ist, einen neuen User anzulegen, wenn das nicht bereits bei der Installation geschehen ist. Mit
useradd -m muster
wird der Benutzer muster dem System hinzugefügt. Mit
passwd muster
bekommt dieser nun ein Passwort. Schon jetzt funktioniert der Webmailer prinzipiell. Das in PHP geschriebene Frontend lässt sich in einem Browser über http://localhost/squirrelmail aufrufen oder wahlweise von einem anderen Rechner über http://IP-Adresse-des-Linux-Rechners/squirrelmail. Bei Letzterem ist darauf zu achten, dass die Firewall HTTP- und HTTPS-Zugriffe von anderen Rechnern zulässt. Das heißt, Port 80 und 443 müssen freigeschaltet sein. Der HTTPS-Zugriff funktioniert allerdings jetzt noch nicht, da wir ihn erst im späteren Verlauf konfigurieren.
Die Firewall-Konfiguration lässt sich bei SuSE über YAST realisieren. Aktivieren Sie in den Firewall-Einstellungen wie im Bild gezeigt unter "Webdienste" die Optionen "HTTP" und "HTTPS".
Fetchmail
Nun widmen wir uns dem Abholen der Mails von Fremd-Accounts. Wie erwähnt erledigt dies Fetchmail. Das Programm loggt sich via POP3 oder IMAP beim Provider ein, holt alle E-Mails und übermittelt diese einem lokalen Benutzer. Dazu legen wir erst einmal die Konfigurationsdatei .fetchmailrc an mit
vi .fetchmailrc
Diese Datei muss so heißen und im Home-Verzeichnis liegen. Das Home-Verzeichnis von root ist in der Regel /root. Jeder Account, der abgefragt werden soll, fängt mit
poll Mailserver-Provider
an. Als Nächstes wird dem Programm das zu benutzende Mail-Protokoll mitgeteilt
proto pop3 oder proto imap
Es besteht auch die Möglichkeit, ein
proto auto
anzugeben. Fetchmail würde dann über POP3, POP2 und IMAP versuchen, die Mails zu holen. Allerdings ist es sinnvoll, das richtige Protokoll anzugeben, wenn es bekannt ist. Welche Protokolle Fetchmail außerdem unterstützt, können Sie in der Man-Page mit
man fetchmail
nachlesen.
Konfiguration von fetchmail
Eine Beispielkonfiguration in .fetchmailrc könnte so aussehen:
poll post.strato.de # fragt den Mail-Server von Strato ab
proto pop3 # benutzt das POP3-Protokoll
user "testuser@strato.de" # übergibt den Benutzernamen testuser
pass "test123" # übergibt das Passwort test123
is muster # der lokale Benutzer, dem die Mails vom Account testuser@strato.de zugestellt werden
fetchall # holt ALLE Mails, egal ob bereits gelesen oder nicht
forcecr # erzwingt ein Carriage Return am Ende jeder Zeile
poll pop.example.com # fragt den Mail-Server von example.com
proto imap # nutzt ein IMAP-Protokoll
user "testuser"
pass "test123"
is tecchannel
fetchall
forcecr
Prinzipiell ist es möglich, die Datei .fetchmailrc für jeden einzelnen Benutzer anzulegen. Allerdings muss sichergestellt sein, dass fetchmail für jeden User aufgerufen wird. Der Verwaltungsaufwand wäre wesentlich geringer, wenn nur ein Benutzer die Konfigurationsdatei pflegt. Der Nachteil hierbei ist, dass der Administrator sämtliche Passwörter aller externen Accounts kennen muss.
Da diese Datei Passwörter im Klartext enthält, sollte sie nur für den Benutzer zugänglich sein, der das Fetchmail-Programm aufruft. Mit
chmod 600 .fetchmailrc
wird dies realisiert.
Vorsicht: Verwenden Sie die fetchall-Funktion mit Bedacht. Der Aufruf von fetchmail mit dem Parameter -k (Mails auf dem Server belassen) führt dazu, dass bei jedem Lauf alle Mails erneut geholt und nochmals gespeichert werden. Das kann dazu führen, dass die in der Datei /etc/php.ini voreingestellte 8-MByte-Speichergrenze für PHP überschritten wird.
Schalter | Funktion |
|---|---|
| |
-v | Verbose-Modus |
-a | holt alle E-Mails (äquivalent zu fetchall in der .fetchmailrc) |
-p <protocol> | Protokoll angeben (äquivalent zu proto in der .fetchmailrc) |
-k | belässt Mails auf dem Remote-Mail-Server, voreingestellt ist "nach erfolgreicher Übertragung löschen" |
-L </Pfad/Datei> | setzt eine Logdatei |
-f </Pfad/Datei> | Konfiguration nicht aus .fetchmailrc lesen |
Die Tabelle zeigt die wichtigsten Steuerparameter von fetchmail. Weitere Schalter finden Sie in der ManuaL Page von fetchmail mit
man fetchmail
Aufruf von fetchmail
Jetzt gibt es zwei Möglichkeiten, die Mails abzurufen:
Entweder Fetchmail wird als Daemon gestartet oder über einen Cronjob aufgerufen. Als Daemon kann Fetchmail mit der Option -d aufgerufen werden. Ein
/usr/bin/fetchmail -d 600 -L /var/log/fetchmail.log
bewirkt, dass die Mails alle 10 Minuten (600 Sekunden) abgeholt werden und eine Logdatei nach /var/log/fetchmail.log geschrieben wird. Logdateien sind grundsätzlich sinnvoll, denn sie erleichtern die Fehlersuche ungemein.
Nach einem Rechnerneustart läuft der Daemon allerdings nicht mehr. Man könnte ein Fetchmail-Script in die Runlevels mit eintragen.
Die zweite Möglichkeit besteht darin, Fetchmail über einen Cronjob zu steuern. Mit
crontab -e
öffnet sich die crontab des gerade eingeloggten Benutzers. Das Ändern der crontab erfolgt wie vom vi gewohnt. Der Eintrag
0,10,20,30,40,50 * * * * /usr/bin/fetchmail -v -L /var/log/fetchmaillog -f '/root/.fetchmailrc'
oder andere Schreibweise
*/10 * * * * /usr/bin/fetchmail -v -L /var/log/fetchmaillog -f '/root/.fetchmailrc'
bewirkt, dass Fetchmail alle zehn Minuten startet, ein Logfile nach /var/log/fetchmaillog schreibt und die Konfigurationsdatei /root/.fetchmailrc benutzt. Der Schalter -f ist eigentlich obsolet, da .fetchmailrc Standardeinstellung ist, aber es dient der Übersichtlichkeit. Sollte nicht root die Mails abholen, ist darauf zu achten, die Datei fetchmaillog für den Ausführenden beschreibbar zu machen oder an eine andere Stelle zu legen.
Fetchmail über einen Daemon zu starten und zu stoppen, bietet sich bei einer Einwählverbindung an. Bei einer Standverbindung ist ein Eintrag in der crontab praktikabler. Bei obigen Einträgen würde der cron daemon nach jedem Lauf eine E-Mail versenden. Das kann zur Fehlersuche dienlich sein, nervt aber auf Dauer. Eine Umlenkung nach /dev/null unterdrückt dies.
*/10 * * * * /usr/bin/fetchmail -v -L /var/log/fetchmaillog -f '/root/.fetchmailrc' >/dev/null 2>&1
Postfix
Postfix ist ein Mail Transfer Agent (MTA), also der eigentliche Mail-Server. Mail-Server sind sehr komplex. Wir gehen daher nur auf die für den Webmailer notwendige Konfiguration ein. Der aufgesetzte Webmailer ist bereits in der Lage, Mails zu verschicken.
Das Problem ist, dass viele Provider die Mail als Spam deklarieren werden, da Sie wahrscheinlich von einer unbekannten Domain beziehungsweise von einer dynamischen IP-Adresse senden. Manche Provider gehen sogar so weit, die Mail gar nicht anzunehmen. Abhilfe schafft ein Provider, der sich als Relay nutzen lässt, also das Versenden einer Mail mit einer anderen Absender-Domain. Das muss der Provider aber erlauben. Fragen Sie nach oder suchen Sie im Internet nach der entsprechenden Adresse.
Die meisten Mail-Anbieter arbeiten in der Regel mit der POP before SMTP-Technik. Das bedeutet, der Client loggt sich beim POP3-Server ein. Der Server speichert die IP-Adresse und den Zeitpunkt des Einloggens. Sobald eine Mail gesendet werden soll, prüft der SMTP-Server des Anbieters, ob die IP-Adresse gültig ist und lässt den Versand zu. Die Gültigkeit der IP-Adresse beträgt häufig 30 Minuten. Holt der Server die Mails alle 10 Minuten, hat der Webmailer immer eine gültige IP-Adresse.
Selbst wenn der Mail-Server des Providers einmal nicht erreichbar ist, gehen zu sendende Mails nicht verloren, da der lokale MTA diese in eine Queue legt und versendet, sobald der Relay wieder erreichbar ist. Gewöhnlich steuert der Parameter relayhost in der Datei /etc/postfix/main.cf, welcher SMTP-Server der Relay ist. Bei SuSE ist der Parameter POSTFIX_RELAYHOST="" in der Datei /etc/sysconfig/postfix einzutragen.
Nach einer Modifizierung der Datei postfix oder main.cf ist ein Neustart von Postfix mit
/etc/init.d/postfix restart
oder wenn Postfix bereits gestartet ist, wahlweise mit
postfix reload
notwendig.
Eigenheiten der Provider
Die beschriebene Vorgehensweise funktioniert beispielsweise beim Anbieter Strato - wenn Sie dort einen Account besitzen. Es sei noch einmal ausdrücklich darauf hingewiesen, dass jeder Provider oder Mail-Anbieter seine Eigenheiten mitbringt. GMX oder Web.de kann man zum Beispiel nur als Relay verwenden, wenn der Absender mit dem des Mail-Accounts übereinstimmt (zum Beispiel muster@gmx.net). Um den Arcor-Relay zu verwenden, müssen Sie bei Arcor angemeldet sein. Der T-Online-Relay ist dagegen sogar zusätzlich kostenpflichtig.
Der Vollständigkeit wegen soll die Authentifizierung per SMTP-Auth kurz angesprochen werden. Bei dieser Authentifizierungsmethode ist kein Einloggen via POP3 erforderlich, bevor Mails über den Relay geschickt werden dürfen. Dazu sind folgende Zeilen in der Datei main.cf notwendig:
smtp_sasl_auth_enable = yes die Datei sasl_passwd im Verzeichnis /etc/postfix hält die Zugangsdaten in folgender Form.
relayhost user:passwd
zum Beispiel
post.strato.de mustermann:strenggeheim
mit
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
postmap /etc/postfix/sasl_passwd
ist die Konfiguration via SMTP-Auth abgeschlossen. Bei SuSE gibt es auch die Möglichkeit, die Einstellungen über die Datei postfix in /etc/sysconfig vorzunehmen. Die Parameter hierfür heißen POSTFIX_SMTP_AUTH und POSTFIX_SMTP_AUTH_OPTIONS. Wollen Sie SMTP-Auth nutzen, muss der Provider diese Art von Authentifizierung unterstützen.
Apache
Wenden wir uns nun dem Apache-Webserver zu. Hier gibt es zwei Hauptaspekte: Zum einen soll der Webmailer vielleicht unter einer anderen URL angesprochen werden. Hierfür ist ein Alias in der Datei squirrelmail.conf im Verzeichnis /etc/apache2/vhosts.d/ notwendig. Legen Sie die Datei dort mit
vi squirrelmail.conf
an. Die Namensgebung ist beliebig, jedoch bietet sich diese "sprechende" Bezeichnung zur leichteren Administration an. Ein Beispieleintrag könnte so aussehen
Alias /webmail /srv/www/htdocs/squirrelmail/
Der Eintrag /webmail gibt den Alternativnamen an, während /svr/www/htdocs/squirrelmail/ den Pfad der Squirrelmail-Installation beschreibt. Hier besteht die Möglichkeit, mehrere Aliase zu setzen.
Damit ist der Webmailer unter http://localhost/squirrelmail, http://localhost/webmail sowie http://localhost/mail zu erreichen.
Verschlüsselung
Der zweite wichtige Punkt ist eine verschlüsselte Verbindung über HTTPS. Vor allem wenn der Webmailer vom Internet aus erreichbar ist, sollte das Passwort nicht im Klartext übergeben werden. Hierzu ist wieder etwas Handarbeit nötig. Als Erstes wird ein selbstsigniertes Zertifikat erzeugt.
Die Befehlszeile
openssl req -new > eigen.cert.csr
generiert einen so genannten "privat key". Die angeforderte "pass phrase" merken Sie sich, da diese noch einmal gebraucht wird. Danach besteht die Möglichkeit, dem Zertifikat seinen Stempel aufzudrücken. Die Befehle
openssl rsa -in privkey.pem -out eigen.cert.key
openssl x509 -in eigen.cert.csr -out eigen.cert.cert -req -signkey eigen.cert.key -days 999
generieren nun ein fertiges Zertifikat - in diesem Fall mit einer Gültigkeit von 999 Tagen.
Nun kopiert man die Dateien eigen.cert.key und eigen.cert.cert in die entsprechenden Verzeichnisse. Die Namensgebung ist nicht relevant, da diese in der Apache-Konfiguration festgelegt wird.
cp eigen.cert.key /etc/apache2/ssl.key/server.key
cp eigen.cert.cert /etc/apache2/ssl.crt/server.crt
Danach wird der Webserver dazu gebracht, auf HTTPS zu reagieren. In der Datei apache2 im Verzeichnis /etc/sysconfig/ setzen Sie den Parameter APACHE_SERVER_FLAGS="SSL". Mit dem Befehl cd /etc/apache2/vhosts.d/
beginnt der letzte Schritt. Ein
cp vhosts-ssl.template vhosts-ssl.conf
schließt die Konfiguration ab. Vergessen Sie bitte den Neustart nicht, der nach jeder Apache-Konfigurationsänderung erforderlich ist:
/etc/init.d/apache2 restart
Jetzt ist es möglich, mit https://localhost/squirrelmail eine verschlüsselte Verbindung aufzubauen. Das Zertifikat muss allerdings bei jedem Aufruf bestätigt werden, da es selbstsigniert ist. Eine Detailansicht des Zertifikats bestätigt aber, durch wen es erstellt wurde.
Squirrelmail
Allerdings ist es dringend anzuraten, zuvor den Parameter $domain in der Datei config.php im Verzeichnis /srv/www/htdocs/squirrelmail/config/ zu editieren. Bei der Grundinstallation steht dieser auf suse.de. Wenn Sie das vergessen, wird bei jeder ausgehenden Mail-Adresse "@suse.de" angehängt. Um ganz sicher zu gehen, wird der Parameter zunächst auf "localhost" gesetzt. Alle anderen Konfigurationsparameter lassen sich in dieser Datei verändern. So ist es auch denkbar, das Frontend für bereits bestehende IMAP- oder SMTP-Server zu nutzen. Die config.php lässt sich entweder manuell mit vi oder mit Hilfe von
perl conf.pl
im gleichen Verzeichnis verändern.
Vorbemerkung: Außer der Standard-Linux-Inbox, die sich in der Datei username in /var/spool/mail/ befindet, liegen alle von Squirrelmail angelegten Ordner in /home/"username"/mail/. Die Bezeichnung "username" steht grundsätzlich für Ihr Login, also beispielsweise /home/muster/mail/
Wundern Sie sich nicht, wenn diese Dateien und Ordner nicht vorhanden sind. Sie werden beim ersten Gebrauch angelegt. Manchmal kommt nach dem ersten Einloggen eine Fehlermeldung. Das liegt daran, dass die /var/spool/mail/"inbox" eines neu erstellten Users nicht angelegt werden kann. Mit
touch /var/spool/mail/"username"
chown "username" /var/spool/mail/"username"
chmod 600 /var/spool/mail/"username"
wird das von root erledigt.
Persönliche Einstellungen
Nach erfolgreichem Einloggen bekommt man ein schlankes übersichtliches Mail-Frontend zu Gesicht, in dem sich einiges einstellen lässt. Sie können zum Beispiel die Sprache im Menü "Options-Display Preferences" auf Deutsch umstellen. Auch die E-Mail-Sortierung, das Erscheinungsbild und zahlreiche andere Optionen sind wählbar. Beim nächsten Aktualisieren der Seite werden die Änderungen wirksam.
Der nächste Schritt sollte in den Ordner "Optionen/Persönliche Informationen" führen. Hier konfigurieren Sie Ihren Namen, Absenderadresse, Zitierungsstil und ob eine Signatur verwendet werden soll.
Auf http://squirrelmail.org können Sie zusätzlich eine Vielzahl an Plug-ins für Squirrelmail herunterladen. So lässt sich der Webmailer zum Beispiel mit einem kleinen Kalender erweitern. CSV-Import/Export-Funktionen, To-do-Reminder, LDAP-Anbindungen und Schnickschnack wie Wetteranzeigen finden sich dort. Einbinden lassen sich Plug-ins wie alle Konfigurationsangelegenheiten in der config.php.
Hier sind der Fantasie nur durch die Anzahl der Plug-ins Grenzen gesetzt.
Fazit
Squirrelmail ist eine ausgereifte und durchdachte Webmailer-Lösung, die sich sowohl für den Firmen- als auch den Privatbereich eignet. Eine DSL-Flatrate reicht bereits aus, um zirka fünf Nutzern gleichzeitig flotten Zugriff auf ihre E-Mails zu gewähren.
Die plattformunabhängige Bereitstellung von E-Mails könnte ein weiterer Antrieb sein. Ein Browser findet sich eigentlich auf jedem Betriebssystem. Bemühungen, aus der Software einen Groupware-tauglichen Client zu machen, lassen sich in einigen Plug-ins erkennen. Somit ist für Firmen wohl eher interessant, externen Mitarbeitern schnörkellos und ohne viel Konfigurationsaufwand E-Mails zur Verfügung zu stellen. (jdo)