Antworten
Seite 1 von 9 1 2 3 ... LetzteLetzte
Ergebnis 1 bis 10 von 84

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

  1. #1
    Anwender Syno-Entdecker
    Registriert seit
    07.07.2008
    Beiträge
    40

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

    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
    @Work
    RackStation RS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5
    CubeStation CS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5

  2. #2
    Anwender Syno-Entdecker
    Registriert seit
    07.07.2008
    Beiträge
    40

    Standard

    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:
    Code:
    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:
    Code:
    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:
    Code:
    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:
    Code:
    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:
    Code:
    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:
    Code:
    [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:
    Code:
    #!/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.
    Geändert von Purzel (05.09.2008 um 19:57 Uhr)
    @Work
    RackStation RS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5
    CubeStation CS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5

  3. #3
    Anwender Syno-Entdecker
    Registriert seit
    07.07.2008
    Beiträge
    40

    Standard

    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:
    Code:
    */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:
    Code:
    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:
    Code:
    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:
    Code:
    #!/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:
    Code:
    [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.
    @Work
    RackStation RS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5
    CubeStation CS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5

  4. #4
    Anwender Syno-Entdecker
    Registriert seit
    07.07.2008
    Beiträge
    40

    Standard

    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:
      Code:
      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:
    Code:
    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
    Code:
    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 [b]/home/Hans/.getmail/gmx.rc[i] und ändern die Eiträge:
    Code:
    [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:
    Code:
    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!
    @Work
    RackStation RS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5
    CubeStation CS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5

  5. #5
    Anwender Syno-Entdecker
    Registriert seit
    07.07.2008
    Beiträge
    40

    Standard

    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
    Code:
    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
    @Work
    RackStation RS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5
    CubeStation CS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5

  6. #6
    Moderator Syno-Gott Avatar von itari
    Registriert seit
    15.05.2008
    Beiträge
    21.956
    Blog-Einträge
    25

    Standard

    Wow - super - was eine Leistung !!!!

    Danke

    itari
    207+ Basic(2x500) [1618] | 509+ Basic(1x500,4x2000) [2166] | 2411+ Basic-SSD(50), Raid-5(4x2000), SHR(3x750+1x1000+2x1500) [2166]

    Synology-Kontakt-Formular
    Come to the dark side, we have cookies!

  7. #7
    Anwender Syno-Coder
    Registriert seit
    14.11.2007
    Beiträge
    571

    Standard

    Respekt!

    Sobald ich Zeit habe....
    DiskStation 207+ | FW: DSM 3.1-1594
    2 x 230GB Seagate ST3320620AS | RAID 1 | Hibernate
    Epson Stylus Photo 870


    Regel #1: Immer ein Backup machen
    Regel #2: Immer ein Backup machen (Backup von Regel #1)

  8. #8
    Anwender Syno-Entdecker
    Registriert seit
    07.07.2008
    Beiträge
    40

    Standard

    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
    @Work
    RackStation RS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5
    CubeStation CS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5

  9. #9
    Moderator Syno-Gott Avatar von jahlives
    Registriert seit
    19.08.2008
    Beiträge
    17.251
    Blog-Einträge
    18

    Standard

    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.
    Code:
    */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
    Code:
    # 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
    Was im Leben zählt, ist nicht, dass wir gelebt haben. Sondern, wie wir das Leben von anderen verändert haben (Rolihlahla "Nelson" Mandela 1918-2013)

  10. #10
    Anwender Syno-Entdecker
    Registriert seit
    07.07.2008
    Beiträge
    40

    Standard

    Moin!

    Zitat Zitat von jahlives Beitrag anzeigen
    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.
    Code:
    */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"?


    Zitat Zitat von jahlives Beitrag anzeigen
    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
    @Work
    RackStation RS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5
    CubeStation CS-406 (2.0.3 - 0428) / 4x WDC WD4000YS-01MPB1 380GB RAID5

Antworten
Seite 1 von 9 1 2 3 ... LetzteLetzte

Ähnliche Themen

  1. 3rd Party HowTo mit Fehler..
    Von crick im Forum Andere 3rd Party Anwendungen
    Antworten: 17
    Letzter Beitrag: 22.09.2009, 12:08
  2. Mailserver IMAP/POP3 auf DS207+
    Von Purzel im Forum IPKG
    Antworten: 9
    Letzter Beitrag: 08.05.2009, 17:48
  3. Mail Server
    Von Nerowulf im Forum IPKG
    Antworten: 79
    Letzter Beitrag: 10.02.2009, 23:17
  4. Kalender mit Mail Funktion
    Von com-cat im Forum Andere 3rd Party Anwendungen
    Antworten: 3
    Letzter Beitrag: 03.09.2008, 11:46
  5. mail() mit der DS ?
    Von masterblob im Forum Webserver
    Antworten: 0
    Letzter Beitrag: 10.04.2007, 18:58

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein