Kopano4S (Zarafa 2.0)

[Matis]

Vielen Dank Ihr Zwei, das war sehr verständlich.
Ich werde das in ner ruhigen Stunden mal auf dem Test-System probieren.

 

[InTheCloud]

Bei mir verbleiben folgende Probleme:
1. Auch nach dem letzten Update (gestern Abend) gibt es einen Fehler bei logrotate:

/etc/cron.daily/logrotate:
error: error setting owner of /var/log/kopano/z-push/z-push-error.log to uid 1023 and gid 1023: Operation not permitted
error: error setting owner of /var/log/kopano/z-push/z-push.log to uid 1023 and gid 1023: Operation not permitted
run-parts: /etc/cron.daily/logrotate exited with return code 1

Konnte das verbleibende Problem mit log rotate wie folgt beheben:
1. In der Datei "/etc/logrotate.d/z-push.lr" folgende Zeile geändert:
su root www-data

2. In der Datei "/etc/logrotate.d/rsyslog" folgende Zeilen geändert (2x in der Datei):
postrotate
reload rsyslog >/dev/null 2>&1 || true

@Tosoboso: Habe das mit dem "reload rsyslog" durch Internetrecherche herausgefunden (z.B. hier: https://serverfault.com/questions/688658/rsyslog-with-logrotate-reload-rsyslog-vs-copytruncate).
Ich weiß nicht, ob das jetzt zuverlässig funktioniert aber vielleicht hilft es Dir.

 

[honk013]

Moin,
ich schließe mich meinen Vorrednern an; die Version 1.1.0 läuft seit gestern einwandfrei (Dank Tipp von Andy+).

Lediglich Logrotate meldet sich immer noch mit folgender Mail bei mir:

/etc/cron.daily/logrotate:
invoke-rc.d: WARNING: No init system and policy-rc.d missing! Defaulting to block.
error: error setting owner of /var/log/kopano/z-push/z-push-error.log to uid 1023 and gid 1023: Operation not permitted
error: error setting owner of /var/log/kopano/z-push/z-push.log to uid 1023 and gid 1023: Operation not permitted
run-parts: /etc/cron.daily/logrotate exited with return code 1

@Tosoboso
Super Job Tosoboso!!!! (Darf man Dir für Deine viele Arbeit eigentlich eine Donation für einen Kaffee zukommen lassen?)

 

[Andy+]

Eine weitere Anregung meinerseits: Jedes Image hat eine ID, zB.

D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1
Digest
c9cfe6d41bbb

welche ich bislang nicht in der Installation gefunden habe. In den letzten Tagen gab es ja rund 5 Imageupdates, jeweils mit der gleichen Bezeichnung D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1 und anhand dieser scheint die Installation dann zu erkennen, dass diese zwar installiert ist, jedoch nicht weiss, welche Revision. Mit dem Update auf v1.1.0 zB. wurde nicht die neuste Revision geladen, das muss mit kopano4s-init refresh manuell nachgeholt werden.

Die Frage wäre, ob eine Imagebezeichnung für den besseren Überblick und dass ggf. damit gearbeitet werden könnte, mit einer Revision versehen werden könnte.

 

[Cruising]

Guten Tag,

gibt es eine Möglichkeit K4S als Testumgebung zu installieren?
Was wird dazu benötigt? Ich habe das Paket installiert und "hänge" nun bei den SMTP-Relay Daten. Was muss hier eingetragen werden?
Aktuell benutze ich Google als Mail Provider...

Ich möchte einfach die Funktionalität von K4S mit Outlook testen ohne den derzeitigen Mailversand abzuschneiden.
Könnte ich die ganze Installation auf dem Synology durchführen und dann im Outlook ein Konto einrichten, was nur im lokalen Netzwerk auf das K4S zugreift und mir quasi nur lokal ein paar Emails usw. senden?
Und wenn ja, wie stelle ich das an?

Vielen Dank.

 

[Andy+]

Für eine Testumgebung kannst Du beliebig installieren. Ich habe für verschiedene Zwecke mehrere DS im Betrieb, daher ist für K4S eine davon produktiv, die anderen sind da für Tests, Ausproben neuer Updates und Builds usw. Wie in meiner Signatur, gibt es ein Wiki

https://wiki.z-hub.io/display/K4S/Install-Update

Eingabe wie folgt:

Emailadresse xxxx@gmail.com
Server smtp.gmail.com
Benutzer xxxx@gmail.com
Passwort yyyyy

Beim Server kann noch ein Port angehängt werden

smtp.gmail.com (ohne Portnr. für Port 25, da Standard)
smtp.gmail.com:587
smtp.gmail.com:465

 

[Cruising]

Danke für die schnelle Antwort.
Ich habe die Daten eigegeben und K4S installiert.
Die Diskstation hat nun eine RAM Auslastung von 75% und die Admin-GUI von Kopano4S hat extrem lange Antwortzeiten....
Ich habe eine 412+.
Kann ich etwas tun um hier eine Besserung zu bewirken?

Danke.

 

[Andy+]

Das kann man so pauschal nicht sagen. Es kommt ja auch auf die Prozesse an, die auf einer DS laufen. Ich habe auch eine DS412+, auf welcher K4S v1.1.0 in der Communityversion C-Core-9.0.2_Webapp-4.0.2581_Z-Push-2.5.1, also Beta, läuft. Die Auslastung liegt im Mittel bei ca. 25-30% und schwankt zwischen 20-80%, obwohl ich neben einigen Syno-APPs noch Resilio und Syncthing installiert habe. Schau da mal im Ressourcen-Monitor in den Aufgaben-Manager, sortiere nach CPU-Auslastung und verfolge den Verlauf. Dann siehst Du schon eher etwas. K4S kommt darin zwar nicht vor, jedoch die Datenbank MariaDB 10, die zeigt bei mir 0-10% an.

 

[NASDuck]

Hi, versuch mal auf Port 8443 also mit SSL. Wenn Kopano im Modus Force-SSL läuft, werden die http ports 80 für,Web, 8080 für ICAL etc. nicht freigegeben...

Danke für Deine Antwort. Aber ich komme nicht weiter. Ich auf 8443 keinen curl oder wget machen, es kommt immer Status zurückgesetzt. Auch nicht mir ignore certificate. Auch nicht im Container. Was immer noch geht ist im Container auf 8080 einen wget auf localhost zu machen und den Kalender so zu laden... was kann das sein?

Im Log im Container kommt die Meldung dass der Port schon belegt ist, wie kann das sein?

$ cat ical.log
2020-01-05T06:46:16.925169: [kopano-ical|T85] [warning] Log connection was reset
2020-01-07T17:08:33.770186: [kopano-ical|T632] [=======] Starting kopano-ical version 9.0.2 (pid 632 uid 0)
2020-01-07T17:08:33.770648: [kopano-ical|T632] [error ] K-1559: bind 0.0.0.0%lo:8080: Address already in use
2020-01-07T17:08:33.770697: [kopano-ical|T632] [error ] K-1559: bind [::]%lo:8080: Address already in use
2020-01-07T17:44:40.619180: [kopano-ical|T5094] [error ] Client request is invalid: too complex (80040117)
2020-01-07T17:44:40.619281: [kopano-ical|T5094] [error ] Error processing POST request: too complex (80040117)

 

[Andy+]

Da wären Überschneidungen bei den Ports zu prüfen, da mW. Port 8443 vom CalDAV belegt wird, sofern installiert.

 

[NASDuck]

Hallo und vielen Dank für die Hilfe.
Ich habe das alles übers Webinterface eingestellt und dort keine Überschneidungen bei den Ports.
Auf der DSM habe ich keinen CALDAV Server installiert.

Mir würde es schon reichen wenn ich per http Port 8080 den ical Kalender abrufen könnte, leider geht das nicht. Im container geht es.
Hast du noch einen Tipp was ich machen könnte?

Danke und Gruß

[EDIT]
Habs jetzt zum laufen gebracht.
Musste in der ical.cfg die Option "ical_listen = *:8080" manuell setzen.
Jetzt läuft es.
[/EDIT]

 

[hnies]

Guten Morgen,
seit dem letzten Update geht der Server bei der nächtlichen Sicherung alle 2-5 Tage down. Ist bei mir auch auf dem Testsystem. Gibt es dazu eine Lösung

2020-01-04T03:06:21.720145: [warning] SQL [00000639] info: Try to reconnect
2020-01-04T03:06:21.720313: [error ] mysql_real_connect: Can't connect to local MySQL server through socket '/run/mysqld/mysqld10.sock' (2)
2020-01-04T03:06:21.720356: [crit ] ----------------------------------------------------------------------
2020-01-04T03:06:21.720372: [crit ] Fatal error detected. Please report all following information.
2020-01-04T03:06:21.720388: [crit ] kopano-server 9.0.2
2020-01-04T03:06:21.720405: [crit ] OS: Debian GNU/Linux 10 (buster) (Linux 4.4.59+ x86_64)
2020-01-04T03:06:21.720442: [crit ] Thread name: kopano-server
2020-01-04T03:06:21.720479: [crit ] Peak RSS: 67144
2020-01-04T03:06:21.720495: [crit ] Pid 21681 caught SIGSEGV (11), traceback:
2020-01-04T03:06:21.720510: [crit ] Backtrace:
2020-01-04T03:06:21.740694: [crit ] f0. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x507f0) [0x7f36f0cd17f0]
2020-01-04T03:06:21.740756: [crit ] f1. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x37826) [0x7f36f0cb8826]
2020-01-04T03:06:21.740771: [crit ] f2. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x38a2e) [0x7f36f0cb9a2e]
2020-01-04T03:06:21.740786: [crit ] f3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f36edaa4730]
2020-01-04T03:06:21.740800: [crit ] f4. /usr/lib/x86_64-linux-gnu/libmariadb.so.3(mariadb_reconnect+0x3a) [0x7f36ee70be4a]
2020-01-04T03:06:21.740815: [crit ] f5. /usr/lib/x86_64-linux-gnu/libmariadb.so.3(+0x264d1) [0x7f36ee70c4d1]
2020-01-04T03:06:21.740829: [crit ] f6. /usr/lib/x86_64-linux-gnu/libmariadb.so.3(mysql_real_query+0x60) [0x7f36ee70a000]
2020-01-04T03:06:21.740858: [crit ] f7. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN2KC9KDatabase5QueryERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x52) [0x7f36f0ae9222]
2020-01-04T03:06:21.740873: [crit ] f8. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN2KC10ECDatabase5QueryERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x15) [0x7f36f0b18675]
2020-01-04T03:06:21.740888: [crit ] f9. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN2KC9KDatabase8DoSelectERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_9DB_RESULTEb+0x53) [0x7f36f0ae98f3]
2020-01-04T03:06:21.740903: [crit ] f10. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN2KC10ECDatabase8DoSelectERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_9DB_RESULTEb+0x11) [0x7f36f0b17651]
2020-01-04T03:06:21.740917: [crit ] f11. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(+0xa835c) [0x7f36f0b3535c]
2020-01-04T03:06:21.740932: [crit ] f12. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN11KCmdService10getChangesEmRK17xsd__base64BinaryjjjjP13restrictTableP17icsChangeResponse+0x205) [0x7f36f0bb3345]
2020-01-04T03:06:21.740946: [crit ] f13. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(+0x192fc9) [0x7f36f0c1ffc9]
2020-01-04T03:06:21.740961: [crit ] f14. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN11KCmdService8dispatchEP4soap+0x2742) [0x7f36f0c24f42]
2020-01-04T03:06:21.740975: [crit ] f15. /usr/sbin/kopano-server(+0x140f8) [0x55bade6440f8]
2020-01-04T03:06:21.740989: [crit ] f16. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x3f2c2) [0x7f36f0cc02c2]
2020-01-04T03:06:21.741003: [crit ] f17. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f36eda99fa3]
2020-01-04T03:06:21.741035: [crit ] f18. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f36ed6a94cf]
2020-01-04T03:06:21.741073: [crit ] Signal errno: Success, signal code: 128
2020-01-04T03:06:21.741089: [crit ] Sender pid: 0, sender uid: 0, si_status: -552850152
2020-01-04T03:06:21.741105: [crit ] Signal value: -552850152, faulting address: (nil)
2020-01-04T03:06:21.741119: [crit ] When reporting this traceback, please include Linux distribution name (and version), system architecture and Kopano version.
2020-01-04T11:20:36.839438: [=======] Starting kopano-server version 9.0.2 (pid 35 uid 0)
2020-01-04T11:20:36.916672: [=======] Starting kopano-server version 9.0.2 (pid 35 uid 1042)

2020-01-08T03:05:42.618857: [warning] SQL [00000024] info: Try to reconnect
2020-01-08T03:05:42.622365: [error ] mysql_real_connect: Can't connect to local MySQL server through socket '/run/mysqld/mysqld10.sock' (2)
2020-01-08T03:05:42.622463: [crit ] ----------------------------------------------------------------------
2020-01-08T03:05:42.622501: [crit ] Fatal error detected. Please report all following information.
2020-01-08T03:05:42.622518: [crit ] kopano-server 9.0.2
2020-01-08T03:05:42.622536: [crit ] OS: Debian GNU/Linux 10 (buster) (Linux 4.4.59+ x86_64)
2020-01-08T03:05:42.622599: [crit ] Thread name: kopano-server
2020-01-08T03:05:42.622634: [crit ] Peak RSS: 79692
2020-01-08T03:05:42.622652: [crit ] Pid 35 caught SIGSEGV (11), traceback:
2020-01-08T03:05:42.622667: [crit ] Backtrace:
2020-01-08T03:05:42.624755: [crit ] f0. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x507f0) [0x7f8f641b17f0]
2020-01-08T03:05:42.624819: [crit ] f1. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x37826) [0x7f8f64198826]
2020-01-08T03:05:42.624835: [crit ] f2. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x38a2e) [0x7f8f64199a2e]
2020-01-08T03:05:42.624864: [crit ] f3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f8f60f84730]
2020-01-08T03:05:42.624878: [crit ] f4. /usr/lib/x86_64-linux-gnu/libmariadb.so.3(mariadb_reconnect+0x3a) [0x7f8f61bebe4a]
2020-01-08T03:05:42.624893: [crit ] f5. /usr/lib/x86_64-linux-gnu/libmariadb.so.3(+0x264d1) [0x7f8f61bec4d1]
2020-01-08T03:05:42.624908: [crit ] f6. /usr/lib/x86_64-linux-gnu/libmariadb.so.3(mysql_real_query+0x60) [0x7f8f61bea000]
2020-01-08T03:05:42.624923: [crit ] f7. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN2KC9KDatabase5QueryERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x52) [0x7f8f63fc9222]
2020-01-08T03:05:42.624938: [crit ] f8. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN2KC10ECDatabase5QueryERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x15) [0x7f8f63ff8675]
2020-01-08T03:05:42.624953: [crit ] f9. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN2KC9KDatabase8DoSelectERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_9DB_RESULTEb+0x53) [0x7f8f63fc98f3]
2020-01-08T03:05:42.624968: [crit ] f10. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN2KC10ECDatabase8DoSelectERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_9DB_RESULTEb+0x11) [0x7f8f63ff7651]
2020-01-08T03:05:42.624983: [crit ] f11. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(+0xa835c) [0x7f8f6401535c]
2020-01-08T03:05:42.624997: [crit ] f12. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN11KCmdService10getChangesEmRK17xsd__base64BinaryjjjjP13restrictTableP17icsChangeResponse+0x205) [0x7f8f64093345]
2020-01-08T03:05:42.625012: [crit ] f13. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(+0x192fc9) [0x7f8f640fffc9]
2020-01-08T03:05:42.625027: [crit ] f14. /usr/lib/x86_64-linux-gnu/libkcserver.so.0(_ZN11KCmdService8dispatchEP4soap+0x2742) [0x7f8f64104f42]
2020-01-08T03:05:42.625042: [crit ] f15. /usr/sbin/kopano-server(+0x140f8) [0x5597edb0c0f8]
2020-01-08T03:05:42.625056: [crit ] f16. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x3f2c2) [0x7f8f641a02c2]
2020-01-08T03:05:42.625071: [crit ] f17. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f8f60f79fa3]
2020-01-08T03:05:42.625085: [crit ] f18. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f8f60b894cf]
2020-01-08T03:05:42.625127: [crit ] Signal errno: Success, signal code: 128
2020-01-08T03:05:42.625143: [crit ] Sender pid: 0, sender uid: 0, si_status: 1355021592
2020-01-08T03:05:42.625159: [crit ] Signal value: 1355021592, faulting address: (nil)
2020-01-08T03:05:42.625187: [crit ] When reporting this traceback, please include Linux distribution name (and version), system architecture and Kopano version.
2020-01-08T09:30:50.415362: [=======] Starting kopano-server version 9.0.2 (pid 34 uid 0)
2020-01-08T09:30:50.480173: [=======] Starting kopano-server version 9.0.2 (pid 34 uid 1042)

 

[Andy+]

.........[warning] SQL info: Try to reconnect ....... Can't connect to local MySQL server through socket '/run/mysqld/mysqld10.sock' (2).....

Davor geht die Datenbankverbindung verloren. Wenn Du beispielsweise mit Hyperbackup eine Sicherung fährst, stoppt die Sicherungsroutine die Datenbank MariaDB 10 während der Sicherung, danach startet diese aber wieder. Normalerweise läuft K4S dann aber weiter, damit arbeiten kann man dann halt nicht. Vielleicht stoppt der Dienst in diesem Falle bei Dir.

Das ist nur Vermutung, die Datenbankverbindung jedenfalls ist unterbrochen. Wenn das einfach so passiert, ist das ungewöhnlich.

 

[hnies]

Danke, Das ist mir schon klar. Vor dem Update auf 9.02 lief der Server weiter, ich vermute, dass etwas geändert wurde, das den Effekt hervorruft. Ich werde jetzt per Aufgabenmanager einfach kopano jeden Morgen um 4 starten. Wenn es läuft passiert nichts, wenn der Container steht wird er wieder gestartet.

 

[Matis]

Hallo !

Ich habe eigentlich wenig SPAM, doch in letzter Zeit häufen sich email von mailchimp.
Deren Eigenart ist, dass sie keinen From haben und einen "on behalf" benutzen. Sie schaffen es trotzdem nicht durch den spf check zu fallen und sind nur durch den helo-Eintrag zu erkennen.
Alle enden mir *.atl231.mcsv.net, meist ist es mail***.atl231.mcsv.net.
Gibt es eine Möglichkeit sowas durch die k4s features in den SPAM zu schieben oder gar nicht anzunehmen?

X-Envelope-From: <>
X-Envelope-To: <mail@meine-domain.de>
X-Delivery-Time: 1578832570
X-UID: 47937
Return-Path: <>
Authentication-Results: strato.com; arc=none
Authentication-Results: strato.com; dkim=none
Authentication-Results: strato.com; spf=neutral smtp.helo="mail115.atl231.mcsv.net"
Authentication-Results: strato.com; iprev=permerror iprev=185.175.56.177
Message-ID: <K095c3w0CCaAUpN.RZmta@smtpin.rzone.de>
X-RZG-CLASS-ID: mi00
Received-SPF: neutral
client-ip=185.175.56.177;
helo="mail115.atl231.mcsv.net";
envelope-from="";
receiver=smtpin.rzone.de;
identity=helo;
Received: from imap.strato.de [81.169.145.103]
by kopano4s.mydomain.me with IMAP (fetchmail-6.3.26)
for <fetchmail@localhost> (single-drop); Sun, 12 Jan 2020 13:36:52 +0100 (CET)
Received: from mail115.atl231.mcsv.net ([185.175.56.177])
by smtpin.rzone.de (RZmta 46.1.4 OK)
with ESMTP id K095c3w0CCaAUpN
for <mail@meinedomain.de>;
Sun, 12 Jan 2020 13:36:10 +0100 (CET)
MIME-Version: 1.0
From: Endurancer.24@imap.strato.de
Subject: Besser als Viagra!! Sie werden den besten SEX Ihres Lebens haben!
Reply-To:
Received:
To:
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="UTF-8"
Date: Sun, 12 Jan 2020 11:27:04 +0100

 

[Matis]

.... bzw. gibt es eine Beschreibung zum neuen "SpamAV" Reiter im Admin-Tool?
Mein Spam Folder heißt "Junk E-Mail". Dies war schon immer so. Davon will der SpamAssasin nicht lernen.

 

[Tosoboso]

Konnte das verbleibende Problem mit log rotate wie folgt beheben:
1. In der Datei "/etc/logrotate.d/z-push.lr" folgende Zeile geändert:
su root www-data
2. In der Datei "/etc/logrotate.d/rsyslog" folgende Zeilen geändert (2x in der Datei):
postrotate
reload rsyslog >/dev/null 2>&1 || true
@Tosoboso: Habe das mit dem "reload rsyslog" durch Internetrecherche herausgefunden (z.B. hier: https://serverfault.com/questions/688658/rsyslog-with-logrotate-reload-rsyslog-vs-copytruncate).
Ich weiß nicht, ob das jetzt zuverlässig funktioniert aber vielleicht hilft es Dir.

Super, Danke, nehme ich so auf und baue dann die Images neu. Der nächste kopano4s-init refresh fixt es dann, Ich gebe bescheid, wann verfügbar..

 

[Tosoboso]

.... bzw. gibt es eine Beschreibung zum neuen "SpamAV" Reiter im Admin-Tool?
Mein Spam Folder heißt "Junk E-Mail". Dies war schon immer so. Davon will der SpamAssasin nicht lernen.

Hi, zu deiner Frage mit reject bei connect auf Helo Ebene siehe hier: http://unixwiz.net/techtips/postfix-HELO.html
Es ist aber zu Beachten, daß SpamAV auf Postfix ausgelegt ist und du laut Logs Oben fetschmail auf IMAP benutzt, d.h. Postfix läuft bei deinem Provider Strato. Man kann fetchmail statt direkt an Kopano dagent zuerst an k4s Postfix liefern lassen und erst dann wird SpamAV benutzt. Das habe ich aktuell noch nicht in drr Fetchmail GUI implementiert, hab das aber vor Jahren mal im JD Zarafa gemacht. Fetchmail und SpamAV verheiraten steht also noch aus, genauso wie Beschreibung / HowTo SpamAV. Was das Lernen Spam Assasins und den Spam bzw. Junk Folder angeht: SpamAssasin lernt von eingehenden Mails, markiert Spam und dann erst verschiebt Kopano dagent gefalaggten Spam nach Junk Folder. Egal, pb der Folder yspam oder Junk heisst. Manuelles nachträgliches Lernen erfolgt dann von Verzeichnissen und kann in Kombination mit kopano-spamd erfolgen, das ist auch zukünftige Funktionalität.
Das mit den Helo access Restrictions wie Oben gelistet Plane ich übrigens in SpamAV als Erweiterung einzubauen.
-TosoBoso

 

[Jens H]

Hallo,
ich bin gerade am Übersiedeln von DS214, wo unter anderem eine Homepage und Zarafa läuft, auf DS918+. Die Homepage konnte ich bereits mit Hilfe eines sehr hilfsbereiten Forenmitglieds übersiedeln. Nun wäre auch ein anderes Mailsystem gefragt, dann könnte ich nämlich meine DS214 auf DSM 6.x updaten und wäre wieder am aktuellen Stand.

Hier meine Frage:
Ich hätte schon gerne wieder all meinen Kalender und die Kontakte im Outlook. Wie aufwändig ist es, Kopano auf der DS918+ so einzurichten, dass sie mir für 3 Accounts per fetchmail die E-Mails abholt und in Outlook-Postfächer verteilt? Nachdem was ich hier so mitlese, dürfte es nach wie vor eine "Bastel-Lösung" sein, wo man auch einiges (für mich ziemlich unverständliches) in der Konsole anstellen muss. Aber vielleicht irre ich mich.
Alternativ könnte ich bei der Mailserver-Lösung von Synology (ohne Zarafa) bleiben und meine Kalenderdaten und die Kontakte vor dem Umstieg einfach in die iCloud verschieben und dort belassen. Dann hätte ich auch wieder alles in Outlook und am Handy, aber etwas "verteilt": Kalender und Adressen in der iCloud, E-Mails über Synology. Pusht mir der Synology Mailserver die Mails überhaupt auch aufs Handy?
Danke für Eure Ratschläge.
Jens

 

[Matis]

Hallo Jens,

das was du vorhast läßt sich alles per GUI konfigurieren, User anlegen, fetchmal und smtp einrichten, fertig.
K4s ist inzwischen eine super gereifte Sache, für Standardfunktionen geht das ohne basteln und sehr stabil.

Wenn Du alles in Outlook psts hast und es einfach willst, würde ich einfach alles neu installieren, die User anlegen und dann Kontakte, Kalender und Mails per Outlook vom pst in die db ziehen.
Dann mußt du nichts migrieren.

Der sync mit mobilen clients funktioniert per push sehr gut.

Wenn du sehr gute Performance haben willst, dann viel RAM in die Syno und die db, docker und k4s auf einem SSD Laufwerk mit ext4 formatiert.
Viel Erfolg.