Externe Accounts abrufen: Unterschied zwischen den Versionen

Aus
 
(6 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 23: Zeile 23:


== Dovecot einrichten ==
== Dovecot einrichten ==
Jeder Benutzer von getmail muss in seinem Homeverzeichnis ein Verzeichnis .getmail haben. Wechselt mit <i>su Hans </i> zum Benutzer Hans und geht ins Verzeichnis /volume1/homes/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.
Jeder Benutzer von getmail muss in seinem Homeverzeichnis ein Verzeichnis .getmail haben. Wechselt mit <i>su EUER_USER</i> zum Benutzer EUER_USER und geht ins Verzeichnis /volume1/homes/EUER_USER/.getmail. Dort müsst ihr für jeden externen POP3-Account, der für EUER_USER 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:
Der Inhalt dieser Dateien könnte in etwa so aussehen:
<pre>
<pre>
[options]
[options]
delete = true
delete = true
message_log = ~/.getmail/log
message_log = /volume1/homes/EUER_USER/.getmail/log


[retriever]
[retriever]
Zeile 42: Zeile 42:
[destination]
[destination]
type = Maildir
type = Maildir
path = ~/.Maildir/
path = /volume1/homes/EUER_USER/.Maildir/
user = Hans
user = EUER_USER
filemode = 0600
filemode = 0600
</pre>
</pre>
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 /volume1/homes/Hans/.getmail/log protokolliert werden.
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 /volume1/homes/EUER_USER/.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!
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!
<pre>
<pre>
Zeile 62: Zeile 62:
<pre>
<pre>
#!/bin/sh
#!/bin/sh
/opt/bin/getmail -q -d --rcfile /volume1/homes/Hans/.getmail/gmx.rc
/opt/bin/getmail -q -d --rcfile /volume1/homes/EUER_USER/.getmail/gmx.rc --getmaildir /volume1/homes/EUER_USER/.getmail
</pre>
</pre>
Die Option -d sollte jedoch nur gesetzt werden wenn die Mails auf dem Quell-Server nach dem Abholen gelöscht werden sollen, andernfalls nutzt man die Option -l.
Die Option <pre>-d</pre> sollte jedoch nur gesetzt werden wenn die Mails auf dem Quell-Server nach dem Abholen gelöscht werden sollen, andernfalls nutzt man die Option <pre>-l</pre>.
Hiernach 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 /homes/Hans/.getmail/log nach, was schief gegangen ist.
Nun müssen noch die folgenden Verzeichnisse angelegt werden:
<pre>
/volume1/homes/EUER_USER/.Maildir
/volume1/homes/EUER_USER/.Maildir/cur
/volume1/homes/EUER_USER/.Maildir/new
/volume1/homes/EUER_USER/.Maildir/tmp
</pre>
 
Hiernach kann das erste Mal getestet werden, ob das Abrufen und Einsortieren der Mails klappt. Dazu startet als EUER_USER einfach das gerade angelegte Script getmail.sh! Dies kann man mit folgendem Befehl in dem jeweiligen Verzeichnis der getmail.sh erreichen:
 
<pre>sh getmail.sh</pre>
 
Hat alles fehlerfrei geklappt, sollte getmail keine weitere Meldung ausgeben und die Mails in eurem Posteingang auftauchen. Andernfalls schaut auch in /homes/EUER_USER/.getmail/log nach, was schief gegangen ist.


== Automatisieren mit Cron ==
== Automatisieren mit Cron ==
Nachdem das manuelle Abrufen geklappt hat, muss der DiskStation jetzt noch beigebracht 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ächlich 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 /homes/Hans/getmail.sh ausgeführt werden soll, so muss das auch von Hans - und nicht root oder einem anderen Benutzer - durchgeführt werden.
Nachdem das manuelle Abrufen geklappt hat, muss der DiskStation jetzt noch beigebracht 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ächlich 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 /homes/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!
Das neue cron kann genau das machen. Dazu legen wir unter /opt/var/cron/crontabs eine neue Datei mit dem Namen EUER_USER an. - Das wird unsere crontab für den Benutzer EUER_USER!
Dann öffnen wir "Hans" und tragen folgendes ein:
Dann öffnen wir EUER_USER und tragen folgendes ein:
<pre>
<pre>
*/15 * * * * /volume1/homes/Hans/getmail.sh &>/dev/null
*/15 * * * * /volume1/homes/EUER_USER/getmail.sh &>/dev/null
</pre>
</pre>
<nowiki>*</nowiki>/15 am Anfang der Zeile weist cron an, den Befehl alle 15 Minuten aufzurufen. Zu beachten ist, dass zwischen den einzelnen Spalten/Zeichen Leerzeichen stehen, keine Tabs!
<nowiki>*</nowiki>/15 am Anfang der Zeile weist 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:
Damit cron die Datei später auch einlesen und korrekt verarbeiten kann, müssen noch ein paar Berechtigungen gesetzt werden:
<pre>
<pre>
chown Hans:users /opt/var/cron/crontabs/Hans
chown EUER_USER:users /opt/var/cron/crontabs/EUER_USER
chmod 0600 /opt/var/cron/crontabs/Hans
chmod 0600 /opt/var/cron/crontabs/EUER_USER
</pre>
</pre>
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.
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(EUER_USER):" 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.
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.
Zeile 119: Zeile 131:
Anschließend wird S62spamd noch mit chmod +x S62spamd für alle ausführbar gemacht.
Anschließend wird S62spamd noch mit chmod +x 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 /volume1/homes/Hans/.spamassassin ein neues Verzeichnis an. Solltet ihr satt dessen lieber mit root weiter arbeiten wollen, dürft ihr nicht vergessen, das neue Verzeichnis mit chown Hans:users /volume1/homes/Hans/.spamassassin dem richtigen Benutzer zuzuordnen. Danach müssen die Konfigurationsdateien in /volume1/homes/Hans/.getmail angepasst werden. Dort fügen wir in jeder Konfigurationsdatei - also für jeden externen Mail-Account - eine neue Sektion hinzu:
Jetzt müssen wir getmail beibringen, SpamAssassin auch zu verwenden. Dazu wechseln wir am Besten mit su EUER_USER direkt zum Benutzer EUER_USER und legen mit mkdir /volume1/homes/EUER_USER/.spamassassin ein neues Verzeichnis an. Solltet ihr satt dessen lieber mit root weiter arbeiten wollen, dürft ihr nicht vergessen, das neue Verzeichnis mit chown EUER_USER:users /volume1/homes/EUER_USER/.spamassassin dem richtigen Benutzer zuzuordnen. Danach müssen die Konfigurationsdateien in /volume1/homes/EUER_USER/.getmail angepasst werden. Dort fügen wir in jeder Konfigurationsdatei - also für jeden externen Mail-Account - eine neue Sektion hinzu:
<pre>
<pre>
[filter-spamassassin]
[filter-spamassassin]
Zeile 125: Zeile 137:
path = /opt/bin/spamc
path = /opt/bin/spamc
allow_root_commands = true
allow_root_commands = true
arguments = ("-s 250000", "-p 783", "-u Hans", )
arguments = ("-s 250000", "-p 783", "-u EUER_USER", )
</pre>
</pre>
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 /homes/Hans/.spamassassin angelegt wurden. Hat etwas nicht geklappt, könnt ihr den Grund dafür ebenfalls hier finden.
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 /homes/EUER_USER/.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".
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".
[[Category:PHP_Codes]]
[[Category:Mailstation]]
[[Category:Code_Schnippels]]
[[Category:Spamassassin]]
[[Category:PHP]]
[[Category:getmail]]

Aktuelle Version vom 10. Februar 2012, 14:55 Uhr

Emails mit Dovecot und getmail abholen

purzel hat im Forum noch für die alte Firmware (ohne Mailstation) einen Beitrag geschrieben, wie man Emails von externen Accounts abholen und in den Mailboxen zur Verfügung stellen kann. Ich war mal so frei und habe den Teil des Beitrags, der noch für die neuste Firmware (832) gültig ist hier reinkopiert. --Jahlives 13:22, 21. Mär. 2009 (UTC) Falls Probleme mit getmail auftauchen, die sich in solchen Meldungen äussern:
Filter error (filter Filter_external spamc (allow_root_commands="True", arguments="('-s 250000', '-p 783', '-u USER')", command="spamc",exitcodes_drop="('99', '100')", exitcodes_keep="('0',)", group="None", ignore_stderr="False", path="/usr/syno/mailstation/bin/spamc", unixfrom="False", user="None") returned 64 (Error in argument 1, char 2: argument required for option s) dann solltet ihr versuchen die Argumente für spamassassin im rc File des externen Mailaccounts so
arguments = ("-s","250000","-p","783","-u","USER",) anzugeben
--Jahlives 17:39, 16. Apr. 2010 (UTC)

Voraussetzungen

Folgende Pakete müssen installiert werden

  • dovecot (bei der neusten Firmware dabei)
  • dovecot-doc
  • py25-getmail
  • py-getmail-common
  • python25
  • cron

Wenn ihr ein Paket mit ipkg nicht findet dann kann ein $ ipkg list | grep PART_NAME helfen

Dovecot einrichten

Jeder Benutzer von getmail muss in seinem Homeverzeichnis ein Verzeichnis .getmail haben. Wechselt mit su EUER_USER zum Benutzer EUER_USER und geht ins Verzeichnis /volume1/homes/EUER_USER/.getmail. Dort müsst ihr für jeden externen POP3-Account, der für EUER_USER 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 = /volume1/homes/EUER_USER/.getmail/log

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

[destination]
type = Maildir
path = /volume1/homes/EUER_USER/.Maildir/
user = EUER_USER
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 /volume1/homes/EUER_USER/.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!

Seit der neusten Firmware bietet die Diskstation via Mailstation die Unterstützung für SSL gesicherte Verbindungen nach POP3 und IMAP.
Damit kann man bei Accounts die dies unterstützen diese auch so abfragen z.B. gmail

type = SimplePOP3SSLRetriever
server = pop.googlemail.com
port = 995
username = myaccount@gmail.com
password = MegaGigaGeheim

Jetzt muss getmail noch mitgeteilt werden, welche Konfigurationsdateien es verarbeiten soll. Dazu geht ihr einen Schritt zurück nach /homes/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 --rcfile /volume1/homes/EUER_USER/.getmail/gmx.rc --getmaildir /volume1/homes/EUER_USER/.getmail

Die Option

-d

sollte jedoch nur gesetzt werden wenn die Mails auf dem Quell-Server nach dem Abholen gelöscht werden sollen, andernfalls nutzt man die Option

-l

.

Nun müssen noch die folgenden Verzeichnisse angelegt werden:

/volume1/homes/EUER_USER/.Maildir
/volume1/homes/EUER_USER/.Maildir/cur
/volume1/homes/EUER_USER/.Maildir/new
/volume1/homes/EUER_USER/.Maildir/tmp

Hiernach kann das erste Mal getestet werden, ob das Abrufen und Einsortieren der Mails klappt. Dazu startet als EUER_USER einfach das gerade angelegte Script getmail.sh! Dies kann man mit folgendem Befehl in dem jeweiligen Verzeichnis der getmail.sh erreichen:

sh getmail.sh

Hat alles fehlerfrei geklappt, sollte getmail keine weitere Meldung ausgeben und die Mails in eurem Posteingang auftauchen. Andernfalls schaut auch in /homes/EUER_USER/.getmail/log nach, was schief gegangen ist.

Automatisieren mit Cron

Nachdem das manuelle Abrufen geklappt hat, muss der DiskStation jetzt noch beigebracht 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ächlich 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 /homes/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 EUER_USER an. - Das wird unsere crontab für den Benutzer EUER_USER! Dann öffnen wir EUER_USER und tragen folgendes ein:

*/15 * * * * /volume1/homes/EUER_USER/getmail.sh &>/dev/null

*/15 am Anfang der Zeile weist 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 EUER_USER:users /opt/var/cron/crontabs/EUER_USER
chmod 0600 /opt/var/cron/crontabs/EUER_USER

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(EUER_USER):" 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ässig.

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_subject *****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-conn-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 +x S62spamd für alle ausführbar gemacht.

Jetzt müssen wir getmail beibringen, SpamAssassin auch zu verwenden. Dazu wechseln wir am Besten mit su EUER_USER direkt zum Benutzer EUER_USER und legen mit mkdir /volume1/homes/EUER_USER/.spamassassin ein neues Verzeichnis an. Solltet ihr satt dessen lieber mit root weiter arbeiten wollen, dürft ihr nicht vergessen, das neue Verzeichnis mit chown EUER_USER:users /volume1/homes/EUER_USER/.spamassassin dem richtigen Benutzer zuzuordnen. Danach müssen die Konfigurationsdateien in /volume1/homes/EUER_USER/.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 EUER_USER", )

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 /homes/EUER_USER/.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".