Wie funktioniert Antispam (Spamassassin, DNSBL, u.a.) mit Zarafa?

[Jdo2002]

@491810: bitte probier das doch erstmal aus de, vmail user mehr rechte zu geben. Ich weiß das verzeichnis auch nicht, sonst hätte ich es geschrieben

 

[491810]

Ich bin gerade bissl auf'n Kopf gefallen ... wie mache ich nochmal einen chmod eines bestimmten users (in diesem Fall den user "vmail") für ein spezifischen Ordner (in diesem Fall den "spool" Ordner, den ich noch finden muss)? Muss ich dazu als user "vmail" eingelogged sein? Die Ordnerrechte kann ich ja nicht aus dem Synology-GUI ändern. Das bietet mir ja nur die Änderung der Zugriffsrechte für die Hauptordnerebene an. Danke für die kurze Hilfe.

 

[Banesh]

Ich werde heute abend nochmal die original Konfiguratiosdateien mit meinen Änderungen vergleichen. Hat bei mir auch mehrere Anläufe gebraucht bis es bei mir funktionierte, daher kann es sein das ich noch etwas vergessen habe. Sorry, für die unvollständigen Infos. Ich eeiss wie frustrierend das ist, wenn man mehrere Tage ohne rechten Erfolg am Server rumbastelt. ;-)

 

[491810]

Ich werde heute abend nochmal die original Konfiguratiosdateien mit meinen Änderungen vergleichen. Hat bei mir auch mehrere Anläufe gebraucht bis es bei mir funktionierte, daher kann es sein das ich noch etwas vergessen habe. Sorry, für die unvollständigen Infos. Ich eeiss wie frustrierend das ist, wenn man mehrere Tage ohne rechten Erfolg am Server rumbastelt. ;-)

Du Banesh ... kein Thema. Klar frustet das einen Windows-lastigen (gelernter) ITler wenn er auf nem Linux nix so schnell ans Laufen bekommt wie er mag ... aber das ist eben Karma.
Hätte 1.) meine UNIX-Kenntnisse nicht so einstauben lassen sollen und vielleicht auch nicht 2002 die IT-Branche vom IT-Bereich in den Sales verlassen sollen ... ist dumm gelaufen.
Das hat man davon, wenn man dann privat noch jahrelang mal einen Windows Home Server betrieben hat und nun Astaro Firewalls und Synology Server mit 'Halbwissen' betreibt.
Wäre ich jetzt fit im Linux Bereich dann wüsste ich ja, wie die Syntax von all dem Kram wäre ... Ich kann Dir nur soviel sagen ... ich glaube irgendwie es liegt an der fetchmailrc selber.
Alle anderen Einstellungen sind ja auch in anderen Dokus auf der Zarafa-Webseite für die Nutzung des Zarafa mit einer eigenen Domäne i.V.m. Postfix anstelle von fetchmail nachzulesen:

http://www.zarafa.com/wiki/index.ph...gy_NAS#Configure_Postfix_with_your_own_domain

Die Syntax ist nahezu 1:1 die selbe wie Du sie auch verwendet hast. "Lediglich" in der mail.template hast Du noch die folgenden Zusatzzeilen

header_checks = regexp:/var/packages/MailServer/target/etc/header_checks
sender_bcc_maps = hash:/var/packages/MailServer/target/etc/bcc/sender_bcc
recipient_bcc_maps = hash:/var/packages/MailServer/target/etc/bcc/recipient_bcc
smtpd_client_restrictions = check_client_access hash:/var/packages/MailServer/target/etc/access/client_access, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

zu den bereits auf der Seite als zu ergänzenden Zeilen

mailbox_transport = zarafa:
local_recipient_maps =
zarafa_destination_recipient_limit = 1

angefügt. Da ich jetzt auch (mal wieder) die Funktion/Sinn dieser Zusatzzeilen auch nur erraten kann (oder mich durch jedes File durchlesen muss) könnte es u.U. auch noch daran liegen (?)
Ob jetzt an dem Tipp von Jdo2002 noch was dran ist, das sich dem user "vmail" noch Rechte auf den "spool" Ordner benötigt musst Du mir sagen. Weißt Du ggf. noch, wie Du gemacht hast?
Leider weiß ich jetzt auch nicht, ob die Syntax in der fetchmailrc richtig ist. Beim googeln habe ich auch festgestellt, dass Du >"< benutzt und andere nur das >'< benutzt haben. Geht beides?
Ach ja ... bevor ich es vergesse zu fragen. Du hast es ggf. bei meinem Stoß an fragen auf Seite 2 überlesen. Ich hatte mich noch gewundert, wieso ich Einträge in der mail.template doppelt habe:

inet_protocols = ipv4, ipv6
mailbox_size_limit = 0
broken_sasl_auth_clients = yes
disable_vrfy_command = yes
cyrus_sasl_config_path = /var/packages/MailServer/target/etc
smtpd_sasl_authenticated_header = yes
smtpd_tls_cert_file = /usr/syno/etc/ssl/ssl.crt/server.crt
smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key
smtpd_tls_security_level = may
sender_bcc_maps = hash:/var/packages/MailServer/target/etc/bcc/sender_bcc
recipient_bcc_maps = hash:/var/packages/MailServer/target/etc/bcc/recipient_bcc
smtpd_client_restrictions = check_client_access hash:/var/packages/MailServer/target/etc/access/client_access, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

#mailbox_transport = zarafa:
#local_recipient_maps =
#zarafa_destination_recipient_limit = 1
#header_checks = regexp:/var/packages/MailServer/target/etc/header_checks
#sender_bcc_maps = hash:/var/packages/Mailserver/target/etc/bcc/recipient_bcc
#recipient_bcc_maps = hash:/var/packages/MailServer/target/etc/bcc/recipient_bcc
#smtpd_client_restrictions = check_client_access hash:/var/packages/MailServer/target/etc/access/client_access, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Soll das so sein, dass der die Zeilen "sender_bcc_maps", "recipient_bcc_maps" und auch "smtpd_client_restrictions" sowohl unter "inet_protocols" als auch mailbox_transport" auflistet werden???

 

[Jdo2002]

Bitte einmal folgendes Probieren, damit meine ich Admin/root Rechte über das DSM einzustellen:

@491810: bitte probier das doch erstmal aus de, vmail user mehr rechte zu geben. Ich weiß das verzeichnis auch nicht, sonst hätte ich es geschrieben

Wenn das hilft können wir auch noch nach dem Verzeichnis fahnden

 

[491810]

Über die Synology GUI (das meinst Du sicherlich mit dem DSM, oder?) habe ich ja bereits den user angelegt und ihm sogar testweise Schreib- und Leserechte auf alle Ordner gegeben.



Das macht aber keinen Unterschied. Leider kann ich dem user vmail "nur" rechte auf die Applikation "Zarafa" geben. Rechte auf die Applikation "MailServer" kann man leider nicht geben.



Ich könnten andernfalls natürlich noch schauen, dass ich auf der Kommandozeile Rechte ändere. Dafür muss ich aber erstmal wissen, wie ich die Rechte von vmail für spool ändern tue.

 

[Banesh]

Meine Einstellungen im DSM sind folgende:
Ich habe einen User "vmail" erstellt, den ich den Gruppen users und administrators zugeordnet habe. Schreibrechte habe ich keine vergeben, auch habe ich keine extra Rechte für den Spool-Ordner vergeben.

Im Email-Server habe ich smtp aktiviert. Als Domainnamen habe ich einen Dummynamen gewählt der nichts mir den real existierenden Emailadressen zu tun hat, damit die Emails nie intern zugestellt werden.

Ich habe gerade nach einer orginalen master.template und main.template gesucht. Leider habe ich keine gefunden. Kann mir jemand diese Dateien zur Verfügung stellen, damit ich mal ein diff darauf anwenden kann?

 

[Banesh]

Ich habe Sie gefunden. Also:
main.template
Ich habe die Zeile

#home_mailbox = .Maildir/

auskommentiert. Also # entfernen. (Vieleicht war das die notwendige Änderung?)

Desweiteren habe ich folgende Zusätze:

default_privs = guest
mailbox_transport = zarafa:
local_recipient_maps =
zarafa_destination_recipient_limit = 1

Sowie einige Zusätze um Nutzerabhängig verschiedene smtp Server für den Emailversand zu nutzen. (Stichwort: sender_dependent_relayhost_maps) Das dürfte aber nichts mit fetchmail zu tun haben.

master.template
Dort habe ich nur die bereits erwähnten Zusatz:

# ZARAFA
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
zarafa    unix  -       n       n       -       10      pipe
 flags= user=vmail argv=/usr/local/zarafa/bin/zarafa-dagent $(user)
#submission inet n       -       n       -       -       smtpd

Server.cfg (Zarafa)
Zu meinem Erstauen habe ich hier anders als vorher behauptet nur

local_admin_users	= root

drin stehen. Also ohne vmail.

Vielleicht könnt ihr diese Konfiguration nochmal testen und Rückmeldung geben.

 

[491810]

Hatte eben schon eine laaange Antwort geschrieben, dass es noch immer nicht geht ... inklusive aller möglicher Informationen.
Kann Entwarnung geben. Geht jetzt! Frag mich aber nicht, wo "der Hase im Pfeffer lag". Hier nochmal die Zusammenfassung:



ZARAFA SERVER AUF SYNOLOGY DISKSTATION MIT SPAMASSASSIN, DNSBL und ANTIVIRUS VIA SYNOLOGY MAILSERVER:


In der Administrationsoberfläche von Synology einen neuen Benutzer namen "vmail" mit Administrationsrechten anlegen.
Diesem dann (so habe ich es zumindestens gemacht und es funktioniert "schmackofatzig!) Rechte auf "Zarafa" gewähren.

In der main.template mit "vi /var/packages/MailServer/target/etc/template/main.template" öffnen. Durch drücken der Taste
"i" wird der Editier-Modus gestartet. Dann folgende Passuse einfügen bzw ändern und mit ":wq!" speichern und schließen.

# DELIVERY TO MAILBOX
#
# The home_mailbox parameter specifies the optional pathname of a
# mailbox file relative to a user's home directory. The default
# mailbox file is /var/spool/mail/user or /var/mail/user. Specify
# "Maildir/" for qmail-style delivery (the / is required).
#
#home_mailbox = Mailbox
#home_mailbox = Maildir/
home_mailbox = .Maildir/

"home_mailbox = .Maildir/" ausblenden indem man ein '#' davorsetzt >>> "#home_mailbox = .Maildir/". Am Ende folgendes ergänzen:

default_privs = guest
mailbox_transport = zarafa:
local_recipient_maps =
zarafa_destination_recipient_limit = 1

In der master.template mit "vi /var/packages/MailServer/target/etc/template/master.template" folgendes durchführen:

An folgender Stelle ...

# ZARAFA
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
#submission inet n - n - - smtpd

Folgenden Zusatz einfügen:

zarafa unix - n n - 10 pipe
flags= user=vmail argv=/usr/local/zarafa/bin/zarafa-dagent $(user)

Sieht dann am Ende so aus:

# ZARAFA
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
zarafa unix - n n - 10 pipe
flags= user=vmail argv=/usr/local/zarafa/bin/zarafa-dagent $(user)
#submission inet n - n - - smtpd

In der server.cfg von Zarafa mit "vi /etc/zarafa/server.cfg" überprüfen, dass folgender Wert gesetzt ist (sollte es "default"):

local_admin_users = root

Nun "nur noch" in der "fetchmailrc" mit "vi /etc/fetchmailrc" die bestehenden Einstellungen

poll *POP-SERVER-PROVIDER* protocol POP3 port 995 user *USERNAME-PROVIDER*
password *USERPASSWORT-PROVIDER* ssl
flush forcecr mda "/usr/local/zarafa/bin/zarafa-dagent *ZARAFA-USERNAME*"

mit "#" wie folgt ausblenden

#poll *POP-SERVER-PROVIDER* protocol POP3 port 995 user *USERNAME-PROVIDER*
#password *USERPASSWORD-PROVIDER* ssl
#flush forcecr mda "/usr/local/zarafa/bin/zarafa-dagent *ZARAFA-USERNAME*"

Und unten den folgenden Code anhängen

poll *POP-SERVER-PROVIDER* protocol POP3 user *USERNAME-PROVIDER*
there with password *USERPASSWORD-PROVIDER* ssl is *ZARAFA-USERNAME* here

Danach müssen natürlich sowohl der MailServer als auch der Zarafa BEIDE neu gestartet werden.

P.s.:
Nochmal herzlichen Dank an Banesh und Jdo2002 für die tatkräftige Hilfe "Licht ins Dunkel" zu bringen!

 

[mdawid]

Hallo Zusammen,

danke erstmal für die tolle Anleitung und Zusamenfassung in diesem Thread. Ich habe mich auch mit diesem Thema beschäftigt und habe eine andere Lösung gefunden, die ich euch hier nicht vorenthalten möchte. Vorab habe ich noch eine Frage zu der ersten Lösung. Wird bei dieser Lösung das automatische Lernen von SPAM der MailStation + SpamAssassin unterstützt? Oder anders gefragt lernt der SpamAssassin durch verschieben von Mails in Junk, das selbige SPAM sind. Und wenn man was aus dem Junk rauskopiert (z.B. in den Posteingang) wird dies dann als nicht-SPAM angelernt?

Hier nun meine Lösung:

Bei dieser Lösung muss mann nur die fetchmailrc anfassen sonst nichts. Dabei habe ich einfach die IMAP-Ordner des "Remote-Maildienstes" auf die lokalen Zarafa Ordner "gemapped". Für jedes Ordner-Mapping braucht man dann allerdings eine Sektion in der fetchmailrc.

1. fetchmailrc mit vi öffnen
vi /var/packages/Zarafa/etc/fetchmailrc

2. folgende config einfügen für 1 user mit 2 Ordermappings (INBOX, Junk)

# -----------------------------------------------------------------
# Setup for zarafa user *ZARAFAUSER*
# -----------------------------------------------------------------

# Folder INBOX
poll localhost protocol imap port 993 ssl user *REMOTEUSER*
password *REMOTEUSERPASSWORD*
folder INBOX
flush forcecr mda "/usr/local/zarafa/bin/zarafa-dagent *ZARAFAUSER*"

# Folder Junk
poll localhost protocol imap port 993 ssl user *REMOTEUsER*
password *REMOTEUSERPASSWORD*
folder Junk
flush forcecr mda "/usr/local/zarafa/bin/zarafa-dagent *ZARAFAUSER* -j"

Bei dieser Konfiguration wird im zweiten abschnitt nur der Junk (spam-ordner) von er Remote-Mailbox abgeholt. Danach wird dem zarafa-dagent mit dem Schalter "-j" mitgeteilt, dass die abgeholte mail in den Zarafa-Junk ordner soll.

Das ganze habe ich bereits getested und es funktioniert bei mir hervorragend. Leider umgeht man damit wahrscheinlich den SpamAssassin. Das bedeutet, es könnten Mails im INBOX landen, welche dann doch SPAM sind.

Gruß

 

[johnyb1]

Genau das wäre auch meine Frage, wie funktioniert das "sauber" und seit dem Update auf DSM 5.1 kommen sämtliche Mails in den Posteingang nichts mehr geht in den Spam Ordner.
Die Konfig Dateien hatte ich vor dem Update gesichert und wieder zürückgespielt und auch nochmal die "DB" Dateien erstellen lassen.

Nun weiß ich nicht weiter.

Hat jemand eine Lösung die wie oben schon gefragt "lernt" wenn Mails in die Inbox bzw. Junk Folder geschoben wird?

Danke

 

[olionsyn]

Ich habe die Konfiguration wie von 491810 auf meiner 214play angewandt (DSM 5.1), aber die eMails kommen nicht in Zarafa an. Ich sehe sie im Protokol von MailServer. Ideen?



Danke
OliOnSyn

 

[Tosoboso]

Hallo olionsyn,
versuche es mal mit diesem Paket von mir, das die benötigten Einstellungen automatisch durchführt und bei jedem Mail-Server update auch reaktiviert

http://www.synology-forum.de/showth...Empfang-in-Zarafa-(re)aktivieren-Z-Pull-Vmail

 

[491810]

Der thread ist zwar inzwischen etwas eingestaubt (sorry) ... ich habe aber festgestellt, dass man bei (eigentlich fast) jeden (leider) Update von Synology ALLE Einstellung überprüfen muss.
Sehr oft (eigentlich ausnahmslos - leider) verhaut Synology die Einstellungen in der main.template sowie auch in der master.template. Die muss man jedes Mal wieder manuell anpassen. *doof*

 

[491810]

Hallo Zusammen,

danke erstmal für die tolle Anleitung und Zusamenfassung in diesem Thread. Ich habe mich auch mit diesem Thema beschäftigt und habe eine andere Lösung gefunden, die ich euch hier nicht vorenthalten möchte. Vorab habe ich noch eine Frage zu der ersten Lösung. Wird bei dieser Lösung das automatische Lernen von SPAM der MailStation + SpamAssassin unterstützt? Oder anders gefragt lernt der SpamAssassin durch verschieben von Mails in Junk, das selbige SPAM sind. Und wenn man was aus dem Junk rauskopiert (z.B. in den Posteingang) wird dies dann als nicht-SPAM angelernt?

Hier nun meine Lösung:

Bei dieser Lösung muss mann nur die fetchmailrc anfassen sonst nichts. Dabei habe ich einfach die IMAP-Ordner des "Remote-Maildienstes" auf die lokalen Zarafa Ordner "gemapped". Für jedes Ordner-Mapping braucht man dann allerdings eine Sektion in der fetchmailrc.

1. fetchmailrc mit vi öffnen
vi /var/packages/Zarafa/etc/fetchmailrc

2. folgende config einfügen für 1 user mit 2 Ordermappings (INBOX, Junk)

# -----------------------------------------------------------------
# Setup for zarafa user *ZARAFAUSER*
# -----------------------------------------------------------------

# Folder INBOX
poll localhost protocol imap port 993 ssl user *REMOTEUSER*
password *REMOTEUSERPASSWORD*
folder INBOX
flush forcecr mda "/usr/local/zarafa/bin/zarafa-dagent *ZARAFAUSER*"

# Folder Junk
poll localhost protocol imap port 993 ssl user *REMOTEUsER*
password *REMOTEUSERPASSWORD*
folder Junk
flush forcecr mda "/usr/local/zarafa/bin/zarafa-dagent *ZARAFAUSER* -j"

Bei dieser Konfiguration wird im zweiten abschnitt nur der Junk (spam-ordner) von er Remote-Mailbox abgeholt. Danach wird dem zarafa-dagent mit dem Schalter "-j" mitgeteilt, dass die abgeholte mail in den Zarafa-Junk ordner soll.

Das ganze habe ich bereits getested und es funktioniert bei mir hervorragend. Leider umgeht man damit wahrscheinlich den SpamAssassin. Das bedeutet, es könnten Mails im INBOX landen, welche dann doch SPAM sind.

Gruß

Die Lösung klingt gut und ist auch einfacher - ist aber nur anwendbar wenn man die Emails lediglich per POP3 bzw. IMAP(S) abholt - funktioniert aber nicht mit eigener Domain (SMTP). ;-)

 

[Tosoboso]

Sehr oft (eigentlich ausnahmslos - leider) verhaut Synology die Einstellungen in der main.template sowie auch in der master.template. Die muss man jedes Mal wieder manuell anpassen. *doof*

Genau diese gelöschten Template Einstellungen werden von Z-Pull-Vmail reaktiviert, sieh dir mal den Thread an, das Paket gibt es signiert bei https://www.cphub.net.
PS: ist in Planung die Funktion in Zarafa 0.6 zu integrieren, aber genau genommen ist es eine Einschränkung im Mail.Server Paket (Reset der Templates bei Update)

 

[Tosoboso]

Die Lösung klingt gut und ist auch einfacher - ist aber nur anwendbar wenn man die Emails lediglich per POP3 bzw. IMAP(S) abholt - funktioniert aber nicht mit eigener Domain (SMTP). ;-)

491810, ich vermute du bist auf dem Holzweg, wenn ich das sagen darf. Das Verschieben von SPAM, der durch SpamAssassing markiert wurde funktioniert tadellos... Es ist nur umgekehrt: man muss fetchmail auf postfix umleiten (ist so auch beschrieben und wird von Z-Pull-Vmail automatisch durchgeführt..) Einzige wichtige Einschränkung: nie nimmer nicht postfix mit recipient statt user benutzen, denn dann sind die fetchmails im Nirvana (siehe Thread Z-Pull-Vmail)

 

[491810]

491810, ich vermute du bist auf dem Holzweg, wenn ich das sagen darf. Das Verschieben von SPAM, der durch SpamAssassing markiert wurde funktioniert tadellos... Es ist nur umgekehrt: man muss fetchmail auf postfix umleiten (ist so auch beschrieben und wird von Z-Pull-Vmail automatisch durchgeführt..) Einzige wichtige Einschränkung: nie nimmer nicht postfix mit recipient statt user benutzen, denn dann sind die fetchmails im Nirvana (siehe Thread Z-Pull-Vmail)

Also mein Zarafa ist jetzt so eingestellt, wie ich es damals beschrieben habe - zumal ich keine Emails via fetchmail mehr abhole. Bin jetzt auch (offen gestanden) zu faul das jetzt umzustellen wo doch gerade alles tadellos läuft. ;-)
Dein Tip bzgl. der Z-Pull-Vmail ist eine super Sache. ich blick vor lauter Updates nur nicht mehr durch, welche Version jetzt die aktuelle ist. Ich habe mir eben als letzte Version die 0.6 runtergeladen. Ist das der letzte Update???

 

[Tosoboso]

Zu den Versionen: Zarafa 0.55 ist aktuell / stable und 0.6 in Arbeit- Bei Z-Pull-Vmail ist die 1.05 aktuell. Wenn du in den Packetquellen https://www.cphub.net einträgst bekommst du immer die neuste Version