Mail Server [HowTo] Mail-Server (IMAP/POP3) mit SpamAssassin

[Purzel]

Moin zusammen!

Wie versprochen gibts hier die HowTo für die Einrichtung eines Mail-Servers auf der DiskStation. Ein Eintrag ins Wiki folgt...

Schöne Grüße,
Purzel

 

[Purzel]

Warum einen Mail-Server?
Die Gründe für die Einrichtung eines eigenen lokalen Mail-Servers können sehr vielfältig sein, daher möchte ich an dieser Stelle kurz erläutern, was mich dazu bewogen hat.

Ich habe mehrere EMail-Konten - u.a. zwei "private" Adressen und verschiedene Adressen für diverse Mailinglisten und Foren - die ich regelmäßig über POP3 auf meinem PC zu Hause abgerufen habe. IMAP kam nicht in Frage, da der Speicherplatz bei meinen Providern stark begrenzt ist und einige IMAP garnicht erst anbieten. Die Mails wurden nach dem Abrufen von den Servern gelöscht und sind dann auf dem PC gespeichert. Damit fangen aber die Probleme schon an: Vom PC im Büro komme ich an die Mails nur ran, wenn diese noch auf den Servern liegen. Bin ich mit dem Notebook unterwegs, fehlen mir ebenfalls die Mails. Muss ich meinen PC neu installieren, müssen vorher erst alle Mails gesichert werden, in der Hoffnung, sie anschließend auch wieder zurück spielen zu können. Und nicht zuletzt muss ich mir für jedes einzelne Postfach den Server und die Zugangsdaten merken und die Konten wieder neu im Mail-Client eingeben.


Was soll unserer Mail-Server können?

• Verwaltung mehrer Benutzer-Accounts
• Bereitstellung von Mails über IMAP (und POP3)
• Zeitgesteuertes Abrufen von mehreren externen POP3 und/oder IMAP-Accounts
• SPAM-Filter auf dem Server
• Serverseitige Filterung und Sortierung von Mails nach eigenen Regeln
• Bereitstellung eines Webmailers

Vorraussetzungen
Ich gehe im folgenden davon aus, dass die ipkg-Verwaltung der DS installiert und funktionsbereit ist. Außerdem setze ich voraus, dass der Anwender über ein Grundmaß an Linux-Kenntnissen verfügt und in der Lage ist, auch über SSH (Konsole) auf seine DS zuzugreifen und Dateien mit einem Texteditor zu bearbeiten.

Leider ist es schon ein paar Tage her, dass ich damit angefangen habe, den Mail-Server auf meiner DS einzurichten. Ich hoffe zwar, dass ich noch alles zusammen bekomme, aber wenn doch mal etwas fehlen sollte, so teilt mir das bitte mit!


Benutzer-Accounts vorbereiten
Standardmäßig erhalten neu angelegte Benutzer auf der DiskStation kein eigenes Home-Verzeichnis und keine Login-Shell. Da wir für unseren Mail-Server jedoch die Benutzer für die Logins und Accounts verwenden wollen, ist beides notwendig.

Ich gehe davon aus, dass die Benutzer - ich nenne sie einfach mal Hans und Karl ("...wie die bösen Riesen im Märchen." ) - bereits angelegt wurden, beispielsweise über den Station Manager von Synology. Ansonsten lässt sich ein Benutzer auch mit adduser und passwd direkt auf der Konsole anlegen.

Loggt euch also zuerst als root über SSH auf eurer DS ein und öffnet die Datei /etc/passwd mit einem Texteditor. Dort findet ihr dann eine Zeile, die in etwa so aussehen sollte:

Hans:x:1027:100:Hans Muster:/nonexist:/sbin/nologin

Wichtig sind /noexist (das Home-Verzeichnis von Hans) und /sbin/nologin (die Login-Shell von Hans). Ändert /noexist in /home/Hans und /sbin/nologin in /bin/ash um. Wer es kompfortabler will kann die bash installieren und statt /bin/ash auch /opt/bin/bash eingeben und die Konsole nach seinen Wünschen anpassen.

Prüft jetzt, ob das Verzeichnis /home/Hans vorhanden ist und legt es gegenenfalls mit mkdir /home/Hans an. Mit chown Hans:users /home/Hans legt ihr fest, dass dieses Verzeichnis auch wirklich Hans gehört.

Wechselt anschließend mit su Hans den Benutzer und legt noch folgende Verzeichnisse an:
/home/Hans/mailbox
/home/Hans/.getmail

Mit exit könnt ihr jetzt wieder zurück zu root wechseln und das ganze noch einmal für Karl durchführen.


Server installieren und einrichten
Nachdem nun die Vorbereitungen abgeschlossen sind, geht es an die Installation der Programmpakete. Auch dazu solltet ihr wieder als root eingeloggt sein.

Jetzt müssen folgende Pakete mit ipkg installiert werden:

• dovecot
• dovecot-doc
• py25-getmail
• py-getmail-common
• python25
• cron

Dabei werden auch gleich noch ein paar andere Pakete mit installiert (ich bin mir auch nicht sicher, ob py-getmail-common nicht automatisch mitinstalliert wird). Da es sich bei getmail um ein Python-Programm handelt, muss auch das entsprechende Paket installiert werden - ich habe mich für die Version 2.5 entschieden. - Wer bereits Python 2.4 auf seiner DS laufen hat, sollte aber auch problemlos py24-getmail verwenden können.

Die Installation von cron ist notwendig, da der auf der DS vorinstallierte cron nur den Benutzer root für zeitgesteuerte Programmaufrufe zulässt. Für getmail müssen wir jedoch für jeden Benutzer einzeln cronjobs ausführen lassen.
Der vorinstallierte cron kann jedoch für System-Aufgaben weiterhin uneingeschränkt benutzt werden, da der neue eigene (andere) Verzeichnisse und Dateien benutzt.

Nach der Installation geht es an die Konfiguration des Mail-Servers. Dovecot bezieht alle Einstellungen aus /opt/etc/dovecot/dovecot.conf. Diese sollte man mit einem Texteditor öffnen und die folgenden Einträge überprüfen und ggf. anpassen:

base_dir = /opt/var/run/dovecot
protocols = imap pop3
log_path = /var/log/dovecot.log
info_log_path = /var/log/dovecot-info.log
default_mail_env = maildir:/home/%u/mailbox

Damit wären die Arbeiten für dovecot auch schon abgeschlossen und der Mail-Server kann mit /opt/etc/init.d/S90dovecot gestartet werden.

Um dovecot zu beenden habe ich bisher nur die Möglichkeit gefunden, den Master-Prozess zu killen. Das kann durch folgenden Befehl erfolgen:

kill `cat /opt/var/run/dovecot/master.pid`

Soll der Server dagegen nur neu gestartet werden - zum Beispiel nachdem die dovecot.conf geändert wurde - geschieht das durch folgenden Befehl:

kill -HUP `cat /opt/var/run/dovecot/master.pid`

Nach einem (Neu-)Start des Mail-Servers müssen noch - wie von dovecot gewünscht - die Lese- und Schreibrechete für zwei Verzeichnisse angepasst werden:

chmod 777 /opt/var/run/dovecot
chmod 777 /opt/var/run/dovecot/login

Um zu prüfen, ob der Mail-Server läuft, kann man sich mit ps aux die laufendne Prozesse anschauen. Folgendes sollte dabei zu finden sein:

• /opt/sbin/dovecot - Der Master-Prozess, der alle anderen steuert
• dovecot-auth - Steuert die Authentifizierung
• imap-login - Verwaltet die Verbindungen zum IMAP-Server
• imap-pop3 - Verwaltet die Verbindungen zum POP3-Server

Damit ist die Konfiguration des Mail-Servers auch schon abgeschlossen und dovecot kann verwendet werden. Um das zu prüfen, kann man sich einfach mit telnet auf Port 110 (POP3) oder 143 (IMAP) mit seiner DiskStation verbinden. - In beiden Fällen sollte die Antwort ein "OK Dovecot ready" sein.

Im Prinzip wäre der Mail-Server jetzt schon einsatzbereit und wir könnten unseren Mail-Client (Thunderbird, Outlook, usw.) entsprechend einrichten (Wichtig: Beim Login auf Groß/Klein-Schreibung achten!). Doch solch ein Server wäre relativ nutzlos, was noch fehlt ist der Abruf der externen Postfächer und die Einsortierung der Mails in die lokalen Mailboxen. - Für diese Aufgabe ist getmail zuständig.

Wechselt mit su Hans zum Benutzer Hans und geht ins Verzeichnis /home/Hans/.getmail. Dort müsst ihr für jeden externen POP3-Account, der für Hans abgerufen werden soll, eine eigene Konfigurationsdatei anlegen, beispielsweise web.rc, gmx.rc oder mail.rc - der Name spielt hierbei keine Rolle.
Der Inhalt dieser Dateien könnte in etwa so aussehen:

[options]
delete = true
message_log = ~/.getmail/log

[retriever]
type = SimplePOP3Retriever
server = pop3.gmx.de
port = 110
username = Hans
password = StrengGeheim
use_apop = false
timeout = 180
delete_dup_msgids = false

[destination]
type = Maildir
path = ~/mailbox/
user = Hans
filemode = 0600

An dieser Stelle möchte ich auf die sehr ausführliche Dokumentation zu getmail verweisen, in der die einzelnen Parameter beschrieben sind. Hier daher nur eine kleine Zusammenfassung: Mit diesen Einstellungen wird getmail angewiesen, die Mails von Hans bei gmx über POP3 abzurufen und in den lokalen Posteingang von Hans zu schieben. Hat das geklappt, sollen die Mails bei gmx gelöscht werden. Die von getmail durchgeführten Aktionen sollen in /home/Hans/.getmail/log protokolliert werden.
Wichtig ist, dass hier das Passwort für den Mail-Account - im Beispiel also für gmx - in Klartext steht. Ihr solltet also darauf achten, wer diese Datei(en) zu lesen bekommt!

Jetzt muss getmail noch mitgeteilt werden, welche Konfigurationsdateien es verarbeiten soll. Dazu geht ihr einen Schritt zurück nach /home/Hans und legt dort die Datei getmail.sh an. Diese muss mit chmod 770 getmail.sh ausführbar gemacht werden. In getmail.sh muss nun getmail aufgerufen und die Konfiguratonsdatei übergeben werden. Das kann dann so aussehen:

#!/bin/sh
/opt/bin/getmail -q -d --recfile /home/Hans/.getmail/gmx.rc

Jetzt kann das erste Mal getestet werden, ob das Abrufen und Einsortieren der Mails klappt. Dazu startet als Hans einfach das gerade angelegte Script getmail.sh! Hat alles fehlerfrei geklappt, sollte getmail keine weitere Meldung ausgeben und die Mails in eurem Posteingang auftauchen. Andernfalls schaut auch in /home/Hans/.getmail/log nach, was schief gegangen ist.

 

[Purzel]

Nachdem das manuelle Abrufen geklappt hat, muss der DiskStation jetzt noch begebracht werden, die Mails auch automatisch abzurufen. Wie Eingangs erwähnt erlaubt das auf der DS vorinstallierte cron nur den Benutzer root für cronjobs. Tatsächilch wird ausschließlich /etc/crontab ausgelesen und die dort eingetragenen Aufgaben unabhängig vom eingestellten Benutzer (Spalte "who") immer als root ausgeführt. Für das Abholen unserer Mails ist es jedoch zwingend notwendig, dass dies unter dem jeweiligen Benutzer geschieht. Das bedeutet, wenn /home/Hans/getmail.sh ausgeführt werden soll, so muss das auch von Hans - und nicht root oder einem anderen Benutzer - durchgeführt werden.

Das neue cron kann genau das machen. Dazu legen wir unter /opt/var/cron/crontabs eine neue Datei mit dem Namen "Hans" an. - Das wird unsere crontab für den Benutzer Hans!
Dann öffnen wir "Hans" und tragen folgendes ein:

*/15 * * * * /home/Hans/getmail.sh &>/dev/null

*/15 am Anfang der Zeile weißt cron an, den Befehl alle 15 Minuten aufzurufen. Zu beachten ist, dass zwischen den einzelnen Spalten/Zeichen Leerzeichen stehen, keine Tabs!
Damit cron die Datei später auch einlesen und korrekt verarbeiten kann, müssen noch ein paar Berechtigungen gesetzt werden:

chown Hans:users /opt/var/cron/crontabs/Hans
chmod 0600 /opt/var/cron/crontabs/Hans

Anschließend kann mit /opt/etc/init.d/S10cron der cron daemon neu gestartet werden. Damit sollten alle Arbeiten abgeschlossen sein und der Mail-Server laufen. Ob alles geklappt hat, kann man sehen, wenn in /var/log/dovecot-info.log Zeilen mit "deliver(Hans):" auftauchen.

Noch ein Wort zum neuen cron. Der neue cron liest seine Einstellungen zunächst aus /opt/etc/crontab (Systemtabelle) und aus den Dateien in /opt/etc/cron.d. Die crontabs für die Benutzer liegen unter /opt/var/cron/crontabs.
Wichtig ist, dass für alle crontabs (System und Benutzer) die Rechte 0600 gesetzt sind, da cron diese sonst nicht verarbeitet.
Cron selbst schreibt auf der DiskStation leider keinerlei Log-Meldungen. Um zu prüfen, ob die Dateien korrekt verarbeitet und die Befehle zu den gewünschten Zeitpunkten ausgeführt werden, lässt sich cron mit /opt/sbin/cron -x test starten. Dann bekommt man nicht nur eine Meldung, welche crontabs eingelesen wurden, sondern sieht auch jeden von cron ausgeführten Befehl mit dem dazugehörigen Benutzer - das ganze aber nur in einer Simulation (-x test)!

Bei mir befand sich nach der Installation von cron in /opt/etc/cron.d noch eine Datei mit dem Namen vnstat. Diese kann gelöscht werden!


SpamAssassin installieren und einrichten
Nachdem unser Mail-Server nun läuft, können wir uns an die Feinarbeiten machen. Zu einem richtigen Mail-Server gehört heutzutage auch ein vernünftiger SPAM-Filter. Für die DiskStation scheint SpamAssassin eine gute Wahl zu sein, denn das Programm lässt sich leicht installieren und verrichtet seinen Dienst unkompliziert und zuverläassig.

Natürlich müssen auch hier wieder neue Programmpakete mit ipkg auf der DiskStation installiert werden:

• perl
• perl-io-socket-ssl
• spamassassin

Nach der Installation muss noch die Konfiguration in /opt/etc/spamassassin/local.cf mit einem Texteditor angepasst werden. Für die meisten Einstellungen gibt es eine hilfreiche Erklärung, so dass ich hier nur eine kurze Zusammenfassung liefere:

rewrite_header_Sibject *****SPAM*****
required_score 5.0
use_bayes 1
bayes_auto_learn 1
bayes_ignore_header X-Bogosity
bayes_ignore_header X-Spam-Flag
bayes_ignore_header X-Spam-Status
bayes_ignore_header X-getmail-filter-classifier

Wichtig ist für uns vor allem die letzte Zeile, denn damit wird verhindert, dass SpamAssassin beim Lernen die von getmail gelieferten Mails fälschlicherweise immer als SPAM einstuft.

Als nächstes kann der spamd daemon gestartet werden. Dazu sollten wir uns die Datei /opt/etc/init.d/S62spamd anschauen - und wenn diese nicht vorhanden ist, anlegen.
Der Inhalt von S62spamd sollte so aussehen:

#!/bin/sh
echo "Starting spamd"
/opt/bin/spamd -d -c -m 1 --max-con-per-child=100 --pidfile=/var/run/spamd.pid -p 783

Wichtig ist die Angabe des Ports mit "-p 783", über den sich mit SpamAssassin kommunizieren lässt. Ohne diese Angabe gab es bei mir immer wieder Fehlermeldungen.
Anschließend wird S62spamd noch mit chmod 777 S62spamd für alle ausführbar gemacht.

Jetzt müssen wir getmail beibringen, SpamAssassin auch zu verwenden. Dazu wechseln wir am Besten mit su Hans direkt zum Benutzer Hans und legen mit mkdir /home/Hans/.spamassassin ein neues Verzeichnis an. Solltet ihr sattdessen lieber mit root weiter arbeiten wollen, dürft ihr nicht vergessen, das neue Verzeichnis mit chown Hans:users /home/Hans/.spamassassin dem richtigen Benutzer zuzuordnen. Danach müssen die Konfigurationsdateien in /home/Hans/.getmail angepasst werden. Dort fügen wir in jeder Konfigurationsdatei - also für jeden externen Mail-Account - eine neue Sektion hinzu:

[filter-spamassassin]
type = Filter_external
path = /opt/bin/spamc
allow_root_commands = true
arguments = ("-s 250000", "-p 783", "-u Hans", )

Das war's schon! Jetzt solltet ihr testen, ob SpamAssassin auch funktioniert. Dazu könnt ihr einfach ein paar Mails abrufen und die Meldungen in /var/log/messages anschauen. Beim ersten Aufruf von SpamAssassin sollte hier stehen, dass Dateien in /home/Hans/.spamassassin angelegt wurden. Hat etwas nicht geklappt, könnt ihr den Grund dafür ebenfalls hier finden.
Hat SpamAssassin die Mail verarbeitet, findet ihr im Mail-Header u.a. einen Eintrag wie "X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on DiskStation".

Die korrekte Funktionsweise des Spam-Filters lässt sich übrigens mit einer GTUBE-Mail sehr leicht prüfen.

Wichtig: Sollte SpamAssassin nicht funktionieren, gehen die Mails nicht verloren, sondern werden einfach ohne Spam-Prüfung weiter verarbeitet.

 

[Purzel]

Mails auf dem Server filtern und sortieren
Richtig interessant wird ein IMAP-Mail-Server erst, wenn man seine Mails direkt auf dem Server automatisch sortieren und filtern lassen kann. Da alle Mails und Ordner sowieso auf dem Server liegen, bietet sich das natürlich auch an.

Der von uns eingesetzte Mail-Server dovecot bietet für diese Aufgabe ein eigenes PlugIn an, welches auf den Namen cmusieve hört und auf Sieve aufbaut, einer Programmiersprache für Mail-Filter.
Leider gehört dieses PlugIn nicht zum Standard-Lieferumfang von dovecot und muss daher erst noch auf bzw. für die DiskStation kompiliert werden - heraus kommen ein halbes Dutzend Dateien, die an die richtige Stelle im dovecot-Verzeichnis verschoben werden müssen.

Ich habe die Dateien zusammengepackt und zusammen mit den Sourcen auf meinem Server zum Download gestellt.

Wer das PlugIn dennoch selbst erstellen will, hier die Kurzanleitung:

• Installiert gcc und make auf der DS (ipkg install)
• Ladet euch dovecot-1.0.15.tar.gz und dovecot-sieve-1.0.3.tar.gz von der dovecot-Homepage
• herunter (Auf die Versionsnummern achten!)
• Entpackt beides in verschiedene Verzeichnisse
• Kompiliert dovecot (./configure und make aber NICHT installieren!)
• Kompiliert dovecot-sieve (./configure und make aber NICHT installieren!) - Als Pfad für die dovecot Config-Dateien müsst ihr mit --with-dovecot den Pfad zum frisch kompilierten dovecot angeben. Leider geht's nicht ohne!
• Sucht und kopiert dann folgende Dateien:
  

  lib90_cmusieve_plugin.la  -> /opt/lib/dovecot/
  lib90_cmusieve_plugin.lai -> /opt/lib/dovecot/lda/
  lib90_cmusieve_plugin.a   -> /opt/lib/dovecot/lda/
  lib90_cmusieve_plugin.la  -> /opt/lib/dovecot/lda/
  lib90_cmusieve_plugin.so  -> /opt/lib/dovecot/lda/
  sievec                    -> /opt/liebexec/dovecot/
  sieved                    -> /opt/liebexec/dovecot/

Achtet dabei bitte darauf, dass lib90_cmusieve_plugin.la in /opt/lib/dovecot auch wirklich die "echte" Datei ist. lib90_cmusieve_plugin.la im lda-Verzeichnis ist nur ein Link auf die gleichnamige Datei in /opt/lib/dovecot.
Jetzt muss dovecot auch noch mitgeteilt werden, dass der Filter vorhanden ist und verwendet werden soll. Dazu muss /opt/etc/dovecot/dovecot.conf ergänzt werden:

protocol lda {
  postmaster_address = root@localhost
  mail_plugins = cmusieve
}

Anschließend muss dovecot neu gestartet werden Damit sollte das PlugIn jetzt einsatzbereit sein.

Sämtliche Filter-Einstellungen werden in .dovecot.sieve - wieder mal eine Textdatei - im eigenen Home-Verzeichnis eingetragen. Werden die Filter das erste Mal benutzt oder geändert, erzeugt dovecot daraus die Datei .dovecot.sievec, eine kompilierte Binär-Version von .dovecot.sieve, was die Verarbeitung beim nächsten Zugriff beschleunigen soll.

Für den Aufbau von .dovecot.sieve solltet ihr euch die entsprechende Hilfe auf der dovecot-Homepage anschauen. Hier nur ein Beispiel für unseren Benutzer "Hans":
/home/Hans/.dovecot.sieve

require "fileinto";
if header :contains "subject" ["***** SPAM *****"] {
  fileinto "SPAM";
} else {
  keep;
}

Das Beispiel prüft, ob im Mail-Betreff "***** SPAM *****" steht. Ist das der Fall, wird die Mail in den Ordner "SPAM" (im Maildir) verschoben. Bitte prüft vorher, ob der entsprechende Mail-Ordner auch existiert und legt ihn ggf mit eurem Mail-Client an!

Damit unsere Mails nun direkt nach dem Abrufen gefiltert und sortiert werden, müssen unsere getmail-Einstellungen geändert werden. Dazu öffnen wir wieder unsere Konfigurationsdatei /home/Hans/.getmail/gmx.rc und ändern die Eiträge:

[destination]
type = MDA_external
path = /opt/libexec/dovecot/deliver
arguments = ("-e", )

Damit weisen wir getmail an, die abgeholten Mails nicht mehr selbst direkt ins Maildir zu legen, sondern den in dovecot eingebauten LDA (local delivery agent) zu benutzen. Dieser übernimmt die Mails von getmail und sortiert die Mails unter Beachtung der Sieve-Filter ins Maildir ein.

Webmailer einrichten
Zum Schluss soll unsere DiskStation noch einen eigenen Webmailer bekommen. Da dieser direkt auf der DS läuft, benötigt man später nur noch einen Internet-Browser, um Zugriff auf seine Mails zu bekommen - besonders nützlich, wenn man mal im Urlaub im Internet-Cafe sitzt.

Auf der DiskStation habe ich zwei Webmailer ausprobiert. Als erstes den Klassiker SquirellMail, der sich problemlos und einfach installieren ließ. SquirrelMail bietet vielfältige Funktionen und lässt sich über PlugIns erweiter, jedoch wirkt die Optik sehr antiquiert und es war mir nicht möglich, das Programm auf Deutsch umzustellen.

Als Alternative bietet sich das ebenfalls kostenlose RoundCube an. Dieses hat zwar nicht ganz so viele Funktionen wie SquirrelMail, punktet dafür aber mit einer sehr modernen und ansprechenden Optik - und es kann mehrere Identitäten (Absender-Adressen) für einen Account verwalten.

Ladet euch zuerst roundcubemail-0.1.1.tar.gz von der RoundCube-Homepage herunter und entpackt das Archiv. Wichtig ist, dass es Version 0.1.1 sein muss. Neuere Versionen verwenden eine PHP-Erweiterung, die es nicht für die DiskStation gibt und lassen sich daher nicht installieren!

Legt einen neuen Ordner mit mkdir /volume1/web/roundcube an und kopiert den Inhalt aus dem Archiv dort hinein.

Bevor ihr RoundCube starten könnt, müsst ihr noch eine neue Datenbank in MySQL auf der DiskStation anlegen. Dazu könnt ihr phpMyAdmin - sofern ihr das schon installiert habt - verwenden oder direkt die Konsole von MySQL. Legt also eine neue Datenbank mit dem Namen "roundcubemail" an und stellt die Berechtigungen ein:

CREATE DATABASE roundcubemail;
GRANT ALL PRIVILEGES ON roundcubemail.* TO username@localhost IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Ersetzt "username" und "password" durch eigene Angaben. Es wird dabei empfohlen, keinen bereits bestehenden Benutzer oder root zu verwenden - denkt euch also einfach was neues aus!

Als nächstes ruft ihr den RoundCube-Installer auf:
http://IP_der_DiskStation/roundcube/installer/

Ersetzt dabei "IP_der_DiskStation" durch die IP eurer DiskStation!

RoundCube führt euch durch die Installation und fragt dabei auch nach dem Benutzerdaten für den den Zugriff auf die Datenbank. Hier weden also die oben eingegeben Daten wieder benötigt. Anschließend sollte der Webmailer über http://IP_der_DiskStation/roundcube erreichbar sein.


Migration
Sucht man im Internet, findet man die verschiedensten Anleitungen, Programme und Scripte, um vorhandene Mails ins Maildir-Format umzuwandeln.

Zumindest für Thunderbird gibt es jedoch eine ebenso einfache wie geniale Lösung: Nachdem ich mein neues IMAP-Konto für die DiskStation eingerichtet hatte, konnte ich dort alle gewünschten Ordner anlegen. Außerdem waren noch alle Mails von meinen alten POP3-Konten vorhanden. Nun mußte ich diese Mails nur noch in die neuen IMAP-Ordner verschieben. Drag&Drop - Fertig!

 

[Purzel]

Was noch fehlt
Nichts ist so gut, dass man es nicht noch besser machen könnte - das gilt auch für unseren Mail-Server auf der DiskStation. Zwei Punkte stehen daher noch auf meiner ToDo:

• SSL-Zugriff
  Bis jetzt werden alle Daten von und zu unserem Mail-Server unverschlüsselt übertragen, auch die Passwörter. Das ist bei vielen Free-Mail-Anbieten auch nicht anders, aber wenn wir schon die Möglichkeit haben, unseren Mail-Server sicherer zu machen, sollten wir dies auch nutzen.
• SMTP-Server
  Bis jetzt kann unsere DiskStation nur Mails abholen und verwalten, zum Verschicken von Mails wird aber immer noch ein externer SMTP-Server benötigt. Zu einem "richtigen" Mail-Server gehört meiner Meinung nach jedoch auch die Möglichkeit, Mails versenden zu können - also ein SMTP-Server.

Ausblick
Neben SpamAssassin als Spam-Filter ließe sich auf der DiskStation auch noch ClamAV als Antiviren-Programm verwenden, welches neue Mails direkt nach dem Abholen durch getmail prüft. Nachdem ich im Synology-Forum jedoch einige wenig zufriedenstellende Beiträge bezüglich der Geschwindigkeit von ClamAV auf der DS gelesen habe, habe ich diese Möglichkeit nicht weiter verfolgt.

Mit getmail lassen sich noch wesentlich komplexere Dinge realisieren, als in dieser HowTo beschrieben. So ist es möglich, Mails nicht nur an einen Account weiter zu leiten. Ich habe mir beispielsweise neben meinem normalen Account (mit Unterordnern) noch einen reinen Mail-Backup-Account angelegt. Getmail leitet nun jede Mail einmal durch den dovecot-LDA und die Sieve-Filter in meinen Account und legt zusätzlich eine ungefilterte Kopie in den Backup-Account. Auf jeden Fall lohnt hier ein Blick in die umfangreiche Dokumentation zu diesem Programm.


Schematischer Aufbau

POP3 -->                                    --> maildir (INBOX)  <-->         <--> RoundMail
POP3 --> getmail --> SpamAssassin --> Sieve --> maildir (SPAM)   <--> dovecot  --> POP3
IMAP -->                                    --> maildir (Filter) <-->         <--> IMAP

Rechtliches
Ich übernehme keinerlei Haftung für Schäden oder Datenverlußte, die direkt oder indirekt auf die Nutzung dieser HowTo zurück zu führen sind. Auch wenn das Beschriebenen bei mir problemlos funktioniert hat, kann ich das nicht für andere garantieren.
Bitte prüft daher die Einstellungen und die Konfiguration eurer DiskStation BEVOR ihr mit der Umsetzung dieser HowTo beginnt!

Links für Dovecot-Sieve-Plugin
cmusieve-1.0.3-arm.tar.gz
dovecot-sieve-1.0.3.tar.gz

 

[itari]

Wow - super - was eine Leistung !!!!

Danke

itari

 

[a-jay]

Respekt!

Sobald ich Zeit habe....

 

[Purzel]

Mahlzeit!

Noch ein Wort zum Verschieben von Mails unter Thunderbird. Bei mir braucht TB ca. 1 Minute, um 150 Mails (im Schnitt 10KB groß) von einer lokalen mbox (TB-POP3-Konto) in ein maildir auf der DiskStation zu verschieben. Nicht unbedingt der Renner, aber für mich akzeptabel, in Anbetracht des Aufwands. Außerdem behalten die Mails sogar ihre Marker und ihren Status (gelesen / nicht gelesen, Priorität, usw.)!

Man kann auch ganze Ordner in TB auf die DS kopieren, dabei werden auch die Unterordner mit allen Mails übernommen. Allerdings ist so kein Verschieben möglich, die Original-Ordner (inkl. Mails) müssen danach manuell in TB gelöscht werden.

Jedoch gibt es beim Ordern-Kopieren eine Einschränkung: Ein Ordner lässt sich nicht direkt als Haupt-Ordner verschieben - zumindest unter WinXP. Dabei wird der Ordner zwar korrekt auf der DS angelegt, aber TB meldet dann einen Fehler und hängt sich auf. Anschließend muss man Thunderbird beenden und den Prozess im Taskmanager killen. Öffnet man TB danach wieder, ist der neue Ordner da, die Mails liegen aber noch an der alten Stelle und müssen nochmal verschoben werden. - Diesmal klappt es dann!
Hat man aber beispielsweise einen Ordner "Newsletter" lassen sich dort hinein andere Ordner verschieben - das geht wieder.

Schöne Grüße,
Purzel

 

[jahlives]

Hi Purzel

erstmal dickes Lob für diese Beiträge. Anhand dieser konnte ich mir Dovecot und Spamassassin ziemlich gut installieren. Zwei kleine Dinge habe ich aber noch und eines davon hat mich Stunden gekostet

gemail.sh
Manuell konnte ich das Script ganz einfach aufrufen und die Mails meiner externen Accounts lagen auf der DS. Sobald ich jedoch versucht habe den Job via cron laufen zu lassen, hatte ich das Problem, dass die Mail einfach nicht da waren. Sowohl Thunderbird als auch ein LIST Command direkt am Server zeigten 0 Mails an. Erst ein manuelles Aufrufen des Scripts auf der Konsole zeigte die Email in der inbox an. Ich habe Stunden mit htop verbracht und die Aufrufe von cron mit dem manuellen Aufrufen auf der Konsole verglichen. Ich konnte keinerlei Unterschiede feststellen. Bei beiden Arten der Aufrufe sah ich die nötigen Netzwerkzugriffe und die Prozessorlast. Es gab keinerlei Unterschiede in der Laufzeit!! Testweise habe ich mal 900 Spammails aus dem Spamordner bei meinem Provider in den Posteingang geschoben. Beide Arten der Aufrufe lasteten das System ca 3 Minuten aus, die Netzwerkaktivität war permanent vorhanden und doch waren die Emails nur bei der manuellen Methode im Postfach vorhanden. Dann habe ich zusätzlich den Verkehr auf Port 110 mit Whireshark gelesen und gesehen, dass alles klappt, die Server antworteten und sendeten ihre Daten bei beiden Methoden.

Kurz vor einem ipkg uninstall, schoss mir der Unterschied der beiden Methoden durch den Kopf. Bei der manuellen Methode bin ich ja als root angemeldet und führe das Script als user mit su user aus. Das war dann bei mir die Lösung:
Ich muss den cron job als root aufrufen.

*/15 * * * * root su user -c 'sh /path/to/home/user/getmail.sh'

Und flupps sind die Emails alle 15 Minuten im Eingang

spamassassin
Hier als kleine Ergänzung der Tipp, dass die statistischen Wortfilter trainiert werden müssen und zwar am besten mit tausenden von Emails. Dazu exportiere ich die Spams und Hams aus dem Client in zwei entsprechende Verzeichnisse auf der DS (mit Thunderbird kann ich dazu die Erweiterung SmartSave empfehlen, damit kann man ganze Verzeichnisse in einem Rutsch exportieren). Danach muss man auf der Konsole sa-learn aufrufen

# sa-learn --spam /path/to/folder/spam
# sa-learn --ham /path/to/folder/ham

Als Ergebnis dieser Aufrufe (und das kann dauern) gibt sa-learn die Anzahl der neugelernten Muster und die Anzahl analysierter Emails an.
Ohne dieses Training machen diese Filter keinen Sinn, denn ohne gelernte Muster kann man diese statistischen Filter auch gleich deaktivieren

Gruss

tobi

 

[Purzel]

Moin!

Bei der manuellen Methode bin ich ja als root angemeldet und führe das Script als user mit su user aus. Das war dann bei mir die Lösung:
Ich muss den cron job als root aufrufen.

*/15 * * * * root su user -c 'sh /path/to/home/user/getmail.sh'

Und flupps sind die Emails alle 15 Minuten im Eingang

Hm... also es stimmt schon, dass man beim getmail-Script auf die Rechte achten muss, aber bei mir funktioniert das auch ohne root...
Hast du mal geschaut, welche Rechte das Script und die Unterordner haben und wie die Einstellungen für Besitzer und Gruppe dafür aussehen?
Verwendest Du das "noramle" cron oder das "nachinstallierte"?

Hier als kleine Ergänzung der Tipp, dass die statistischen Wortfilter trainiert werden müssen und zwar am besten mit tausenden von Emails.

Ja, das stimmt. Allerdings gibt es auch die Möglichkeit, vordefinierte Regelsätze einzuspielen. Damit liefert bei mir der SA auch ohne Training schon sehr gute Ergebnisse.

Schöne Grüße,
Purzel

 

[jahlives]

Hast du mal geschaut, welche Rechte das Script und die Unterordner haben und wie die Einstellungen für Besitzer und Gruppe dafür aussehen?
Verwendest Du das "noramle" cron oder das "nachinstallierte"?

Ja, das stimmt. Allerdings gibt es auch die Möglichkeit, vordefinierte Regelsätze einzuspielen. Damit liefert bei mir der SA auch ohne Training schon sehr gute Ergebnisse.

Das Script gehört dem User. Der User und die Usergruppe dürfen zugreifen (chmod 0770). Könnte es ggf sein, dass es Probleme gibt mit mehreren Usern auf die gleiche Mailbox zuzugreifen. Die jeweiligen Benutzer sind in einer eigenen gemeinsamen Gruppe zusammengefasst und haben das gleich Homeverzeichnis. Ich verwende der ipkg Cron, also den nachinstallierten

Und wo kriegt man diese vordefinierten Regelsätze her? Weil bis jetzt habe ich schlicht zu wenig Spam, um die Filter genügend zu trainieren

Gruss

tobi

 

[Trolli]

...poste doch einfach mal Deine Mail-Adresse hier rein, dann bekommst Du bestimmt genug Spam zum Trainieren

 

[Purzel]

*lol*, Trolli, das ist gemein! Naja, ich bekomme so schon rund 500 SPAMs pro Tag auf meinen diversen Accounts, das reicht mir.

Rulesets:
Ein paar gibts schonmal direkt auf der SpamAssassin-Homepage. Da kann ich das "German Language Ruleset" empfehlen, das funktioniert bei mir sehr gut.
Ansonsten lohnt auch ein Blick auf Rules Emporium.

 

[itari]

...poste doch einfach mal Deine Mail-Adresse hier rein, dann bekommst Du bestimmt genug Spam zum Trainieren

Och, es reicht eigentlich, den Link seiner Homepage in der Signatur zu veröffentlichen

itari

 

[Azibi]

Hallo und danke für diese ausführliche Anleitung.

Bis jetzt bin ich gut durchgekommen. Was mir ein wenig Kopfschmerzen macht sind die Einstellungen in der .rc Datei. Und zwar habe ich ein IMAP und mehrere POP-Konten und jedes Konto bekommt seine eigene .rc-Datei. Soweit habe ich es verstanden. Ich bis jetzt aber noch keine Mails abgerufen, weil ich Angst habe das alle Mails vom imap bzw pop Server gelöscht werden. Das darf auf gar keinen Fall passieren! Kennst du die entscheidenden Zeilen die das verhindern würden?

Ich denke mal irgendwo hier so, oder?

[options]
delete = true
....

[retriever]
.
.

delete_dup_msgids = false

Gruß Azibi

 

[.:@rpy:.]

Danke...

Nachdem ich des alles aufgesogen habe;

HammerBeitrag.

Grossartig.

Danke...

 

[ac303id]

erst mal danke für dieses howto und die mühe die du dir gemacht hast.

ich stehe aber trotzdem vor einigen problemem bei der einrichtung und weder das forum noch google oder die handbücher konnten mir wirklich bisher helfen. also hoffe ich nun auf eure hilfe..

1. getmail kill jedesmal alle meine mails auf dem server, egal ob mir delete true oder false bzw day. egal welchen pop3retriever uich auch probiere.

2. sieve funktioniert irgendwie bei mir gar nicht ich weiß auch nicht wie ich den weiter konfigurieren bzw testen kann. einstellungen sind alle wie im howto.
sobald ich in der dovecot.conf lda aktiviere bzw in der rc datei den destination eintrag auf mda_external ändere komme keine mails mehr an.

3. gibt es eine beispiel config für sieve um mehrer accounts in unterordner zu sortieren bzw auch dort unter ordner... muss man diese vorher alle anlegen und wie werden diese dann angesprochen? mit dem unterordner direkt oder über INBOX.unterordner..

danke schon jeze für helfende oder rückfragende antworten.

 

[ac303id]

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ACHTUNG
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

vor einem firmware update auf die aktuelle .220 unbedingt den /home ordner sichern...

dieser wurde bei mir vom update komplett gelöscht.
(backup hat mich gerettet - man weiß ja nie ;-) )
ich habe noch nichts gefunden, was sonst noch zu opfer gefallen sein könnte.

trotzdem bleiben meine probleme s.o. bestehen.

 

[jahlives]

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ACHTUNG
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
vor einem firmware update auf die aktuelle .220 unbedingt den /home ordner sichern...
dieser wurde bei mir vom update komplett gelöscht.
(backup hat mich gerettet - man weiß ja nie ;-) )

Oder man legt die home-Verzeichnisse nicht in /home sondern in /volume1/home an Das wird dann auch beim Update ned überschrieben. Gerade gestern FW 7.22 draufgemacht und getmail.sh lief beim nächsten Aufruf durch Cron als ob nix gewesen wäre

 

[ac303id]

kann man die home verzeichiss enachträglich ohne problem nach volume1 home verscheiben... (ok conf dateien noch anpassen..)
aber sonst noch was beachten ?
gibt es eine globale variable wo home dir veknüpft ist?