Kopano4S (Zarafa 2.0)

[491810]

Also das ist echt wie verhext. Selbst IMAP bekomme ich nicht hin. Aber vom Windows PC aus. Supi. Keine Ahnung warum das dort geht aber auf dem Macbook nicht. Ich habe inzwischen sogar intern die Firewall deaktiviert, um dort Fehler auszuschließen. Mein Macbook ist - in Ermangelung an ein RJ45 Port - via Wifi über die Fritzbox 6591 angebunden. Dort hat die DS918 mit Kopano mit dem LAN2 ein "Fuß" im Netz und ist via 192.168.178.3 erreichbar. Eigentlich nur für DNS (Port 53) für den ADguard. Aber die IMAP (143), IMAPs (993). POP3 (110), POP3s (995), SMTP (25) und SMTPs (465) habe ich inzwischen dort auch aktiviert. Ich habe sogar die Firewall schon ausgeschaltet. Kein Erfolg. gleich ob ich im Feld "IMAP Server" und "SMTP Server" die DNS-Adresse (womit er über das Internet geht) oder die interne IP (= 192.168.178.3) eingebe. Keine Verbindung. Aber mein Laptop aus dem internen Netz (hinter einer Sophos sg105w mit Netzbereich 172.16.0.0/24) kommt auf LAN1 der DS918 problemlos via IMAP ran. Und das ob die Firewall an oder aus ist. Ich habe inzwischen unter macos die Emailprogramme "Spark", "BlueMail", "Outlook" (das von Microsoft!) als auch "Mail" ausprobiert. jedes mal - gleich ob verschlüsselt (egal ob "SSL" oder "TLS") oder unverschlüsselt. Keine Chance. Und zwar egal, ob Exchange oder IMAP. Irgendwer eine Idee, wieso ich von einem Mac 0,0 Verbindung - noch nicht mal via IMAP - bekomme? Hier mal die Einstellungen meiner gatewway.cfg:

##############################################################
# GATEWAY SETTINGS

server_bind = 0.0.0.0

# Please refer to the administrator manual or manpage why HTTP is used rather than the UNIX socket.
#server_socket = http://localhost:236/

# Set this value to a name to show in the logon greeting to clients.
# Leave empty to use DNS to find this name.
#server_hostname =

# Whether to show the hostname in the logon greeting to clients.
#server_hostname_greeting = no

# drop privileges and run the process as this user
#run_as_user = kopano

# drop privileges and run the process as this group
#run_as_group = kopano

# create a pid file for stopping the service via the init.d scripts
pid_file = /var/run/kopano/gateway.pid

# run server in this path (when not using the -F switch)
#running_path = /var/lib/kopano

# create memory coredumps upon crash [no, systemdefault, yes]
#coredump_enabled = systemdefault

# enable/disable POP3, and POP3 listen port
pop3_enable = yes
pop3_port = 110

# enable/disable Secure POP3, and Secure POP3 listen port
pop3s_enable = yes
pop3s_port = 995

# enable/disable IMAP, and IMAP listen port
imap_enable = yes
imap_port = 143

# enable/disable Secure IMAP, and Secure IMAP listen port
imaps_enable = yes
imaps_port = 993

Was mich irritiert ist, dass die gateway.cfg vorher so aussah und Microsoft Outlook von meinem Windows-Laptop sich bereits verbinden konnte (sind da noch wo anders Einstellungen???):

##############################################################
# GATEWAY SETTINGS

#server_bind =

# Please refer to the administrator manual or manpage why HTTP is used rather than the UNIX socket.
#server_socket = http://localhost:236/

# Set this value to a name to show in the logon greeting to clients.
# Leave empty to use DNS to find this name.
#server_hostname =

# Whether to show the hostname in the logon greeting to clients.
#server_hostname_greeting = no

# drop privileges and run the process as this user
#run_as_user = kopano

# drop privileges and run the process as this group
#run_as_group = kopano

# create a pid file for stopping the service via the init.d scripts
pid_file = /var/run/kopano/gateway.pid

# run server in this path (when not using the -F switch)
#running_path = /var/lib/kopano

# create memory coredumps upon crash [no, systemdefault, yes]
#coredump_enabled = systemdefault

# enable/disable POP3, and POP3 listen port
#pop3_enable = no
#pop3_port = 110

# enable/disable Secure POP3, and Secure POP3 listen port
#pop3s_enable = no
#pop3s_port = 995

# enable/disable IMAP, and IMAP listen port
#imap_enable = no
#imap_port = 143

# enable/disable Secure IMAP, and Secure IMAP listen port
#imaps_enable = no
#imaps_port = 993

 

[Andy+]

Die Gateway sieht soweit normal aus. Der Port 236 ist der Exchangeport speziell für den Zarafa-Client. Ich denke, Du solltest nach Protokollversionen und -updates Ausschau halten.

 

[491810]

Welche "Updates" meinst Du denn @Andy+? MacOS? Synology? Kopnao4s? Also ich habe auf meinem zweiten NAS - einem ds620slim - den Mailplus Server installiert gehabt. Damit kann ich mich problemlos via IMAP vom Macbook aus verbinden. Sehr interessant. Muss mir mal fix den MailPlus Server auf der ds918+ installieren und schauen, ob das dort auch funktioniert. Falls nicht könnte das ein DSM6 vs. DSM7 Thema sein (?).

 

[Andy+]

Wegen DSMs glaube ich nun nicht. Ggf. ist Apple nicht so tolerant bei Protokollprozessen. Wegen DSM 7 habe ich zu MP migriert und inzwischen läuft alles damit auch sehr gut.

Bez. Updates meinte ich zu Apple, falls andere auch schon damit zu tun hatten.

 

[FricklerAtHome]

Glück Auf

leider sind die auf einem MAC / macOS nativen Apple-Mail Programme nicht mit der Funktionalität der Pendants auf ios / iPadOS gleich.
Auf den Gadets setzen Apple und Android auf einen "ActivSync" Konnekt. Die Dickschiffe unter Apple können aber nur mittels EWS einen Konnekt aufbauen. Ein Update (egal wo) wird da nicht helfen, da weder Kopano noch Gro bisher einen vollqualifizierten EWS Zugang anbieten.
Gro hat da etwas als zukünftige Option in Aussicht gestellt, spricht aber aktuell wieder von einem eigenen "Client" für MacOS. Bei Kopano war dies bisher der oben schon erwähnte Desktop Client für MACOS (ein verkappter Web-Browser). Bei mir läuft der schon seit langem nicht mehr störungsfrei (seit MacOS 12!). ---- Wir nutzen im Apple Umfeld nur noch die direkte WEB-APP mit Zugriff aus dem Browser!

IMAP sollte aber funktionieren. Zumindest funktioniert das bei uns im internen Netz egal ob mit Outlook unter Windows oder mit Apple-Mail auf den Mac-Books. Hier nutzen wir strikt die IP Adresse von Kopano im internen Netz und die entsprechenden Ports. Wenn man hier auch die TSL-Varianten nutzen möchte muss das Zertifikat passen! Also auch im K4S muss eine gültiges Zertifikat (lets Encrypt etc) genutzt bzw. vorhanden sein. ---- Mir persönlich ist das zu viel Aufwand. Wir nutzen einen Reverese-Proxy für Zugriffe aus dem Internet mit jeweils aktuellen Zerts und strikt über "ActiveSync". Nur aus dem internen Netz auch IMAP, MAPI etc. Die IP-Adresse von K4S ist als Docker-App gleich mit der IP der Syno. Jetzt muss du kontrollieren ob ggf. noch andere Dienste der Syno diese Ports ebenso nutzen. Auch das führt zu Störungen und muss dann Umgemappt werden.
Letztlich muss auch noch der Benutzer entsprechende Rechte für den IMAP Zugriff haben. Ob dies im WEB-Admin geht weis ich nicht mehr genau. In meiner Kopano-VM geht das übers Terminal mittels kopano-admin ....

Ach so: selbst Outlook (Microsoft) für MacOS spricht auf Apple-Kisten kein MAPI (also die technische Anbindung eines nativen Exchange Servers für Windows-PC's). Auch OL verlangt hier eine vollständiges EWS Anbindung. Und die gibt es aktuell nicht für KOPA oder GRO.

ieLbdN (schon an da Weihnachts-Session)
F@H

 

[491810]

Was muss ich denn bei IMAP beachten unter Kopano4s (z.B. in der gateway.cfg o.ä.?) damit es läuft? Unter Windows kann ich via Microsoft Outlook per IMAPs das Postfach problemlos einrichten, Verbindungstest ist auch erfolgreich und das Postfach funktioniert. Bei macOS geht da 0,0. Was mich irritiert. natürlich habe ich die Ports (25, 110, 143, 465, 587, 993 und 995) freigegeben. Ich habe sogar (s.o.) die Firewall im Netz der Fritzbox (in das das Macbook Pro via Wifi connected ist) ausgeschaltet. Keine Änderung. Finde ich wie gesagt sehr verwirrend. By the way ... wie stehen denn eigentlich inzwischen die Aktien bzgl. GRO? Ist da schon was unter DSM7.x lauffähig???

 

[Andy+]

IMAP sollte beim Benutzer im K4S-Admin aktiviert sein. Dann sollte das zusammen mit den freigegebenen Ports auch klappen. Bezüglich Grommunio mit dem DSM 7 läuft das in einer VM mit den gezeigten Steps Seite 106, ggf. f. soweit. Ich habe das allerdings bis heute nicht rund ans alufen bekommen, da SMTP nicht geht (das ging ja noch), aber User Loginfehler ausser beim Admin, läuft zähv usw. Für mich ist das produktiv noch nichts, mal sehen.

Ich bin inzwischen vollständig auf MailPlus-Server umgestiegen. Es ist nicht ganz so das, wie mit K4S, aber im Grundsatz akzeptabel und läuft ansonsten schon ziemlich gut.

 

[FricklerAtHome]

also meine gateway.cfg sieht so im Start-Bereich aus:

##############################################################
# GATEWAY SETTINGS

# Space-separated list of addressort specifiers for where the server should
# listen for connections.
#
# "*:143" — port 143, all protocols
# "[::]:143" — port 143 on IPv6 only
# "[2001:db8::1]:143" — port 143 on specific address only
#
# imaps is normally on 993, pop3s on 995.
#

#server_bind = 0.0.0.0
#pop3_enabled = no
#pop3_listen = *:110
#pop3s_listen = *:995
#imap_enabled = no
imap_listen = *:143
imaps_listen = *:993

Spezielle Ports auf dem Mac-Book sind nicht geöffnet auch die WLAN Anbindung der Mac-Books bedarf keiner besonderen Einstellung. Die Firewall der Fritzbox ist an.
Unter Internet-Accounts in der MAC-Systemsteuerung steht dann so was:



Zu GRO: ich nutze auch GRO in einer VM. Da spielt wie auch bei Kopano als VM das DSM keine Rolle. Alle Synokisten die ich betreibe laufen soweit möglich mit DSM 7.1. Eine alte Kiste schnurrt noch mit DSM 6.2 (nicht update-fähig). Deren wenige Freigaben habe ich in eine aktuelle Syno eingehangen. So spricht keiner meiner Clients das Schätzchen mit veralteten Protokollen oder Methoden an.

Immer noch kein Schnee
F@H

 

[FricklerAtHome]

.. User Loginfehler ausser beim Admin, läuft zähv usw. Für mich ist das produktiv noch nichts, mal sehen.

Bei GRO sind zwei Interfaces zu beachten:

Admin-Interface: Aufruf mit https://<IP-der_VM:8443/ dort dann anmeldem mit USER admin und entsprechendem Passwort

An diesem interface kann sich kein normaler User anmelden, es kann von dort auch keine Mail versandt werden!

User-Interface: Aufruf mit https://<IP-der_VM/web/ (also hier Standardport 443 mit Unterverzeichnis) dort anmelden als User mit der vollen E-Mail Adresse und dann das Passwort. Eine Anmeldung nur mit dem Benutzernamen läßt sich nur in den Tiefen der Konfig-Dateien mittels Terminal umstellen.

und auch noch kein Schlitten am Horizont!
F@H

 

[Andy+]

anmelden als User mit der vollen E-Mail Adresse

Das muss ich nochmal testen...

 

[FricklerAtHome]

und wenn man die aktuellsten updates über "zypper ref && zypper up" abgerufen hat, danach die VM mittels "reboot" ebenso neu gestartet hat ------ dann sollte mittels https://IP-der_VM:8443/antispam/ auch das RSPAMD Interface zur Verfügung stehen.

Empfehlenswert ist auch die Installation der qemu-guest-tools in der VM mittels "zypper inst qemu-guest-tools" (danach zwingend reboot).
Das verbessert das Zusammenspiel zwischen VM und SYNO deutlich. Eine GRO Instanz läuft bei uns mit folgenden Einstellungen bei 4 Usern eigentlich ausreichend performant, zu Kopano kein spürbarer Unterschied (läuft als VM auf der gleichen Syno sogar mit 4GB RAM):



Wir verzichten hier aber auf allen SchnickSchnack wie Webmeeting, GRO-Files etc. Aktuell experimentieren wir mit dem GRO-Archiv Modul. Das ist aber für uns noch nicht ausgereift. Im Gegensatz zu Kopano gibt es bei GRO relativ schnell Updates! Teilweise im Tagestakt.

es wird auch noch nicht ruhiger! Die Laubbläser!
F@H

 

[FricklerAtHome]

Noch 'ne Antwort: Wie betreut man denn die Nachbarschaft?

wir machen das in zwei Stufen:

Stufe 1 --- Der Nachbar braucht eine neue VM, zB. GRO.
Der Nachbar sagt welchen IP-Bereich er nutzt, wie seine Mail-Domäne heißt und welche Benutzer sie/er benötigt. Mit diesen Angaben richte ich erstmal eine "Basis-VM-Installation" auf meiner Hardware ein. Wenn die läuft, wird Sie als "OVA-Datei" exportiert und über ein Nextcloud-Share dem Nachbarn zur Verfügung gestellt. Der lädt diese sich dann herunter und importiert sie dann in sein VMM auf der Syno.
Das spart zeitraubende "Primär-Installationen" und hat den Charme das alle bisherigen Erfahrungen bereits einfließen.

Stufe 2 --- Feinschliff vor Ort oder per VPN oder mit Video-Telefon
Läuft die Basis-Installation treffe ich mich mit einem zwingenden "Deputat aus Gerstensaft" mit den Nachbarn. Dann werden direkt vor Ort durch den Nachbarn, die notwendigen "General-Passwörter" geändert (ich zeige nur wo oder wie man das tut). Die bereits eingericheten Benutzer können sich ertsmalig anmelden und müssen dort Ihr Passwort sofort neu eingeben (Wir nutzen DB und nicht LDAP). Das dauert keine Stunde. Meine bisherigen Zugangserkenntnisse sind damit auch verschwunden. Das system ist personalisiert. --- geht das nicht direkt vor ORT nutzen wir seit Corona auch mal ein VPN oder eine Videoschalte über die Handys.

Damit ist eine reine Neu-Installation schon erledigt.

Müssen noch Migrationen erfolgen dauert Stufe 2 ggf. etwas länger, da die Basis-Installation auf erprobter Technik bzw Konfiguration basiert, ist das bereits geübte Praxis. Es funktioniert in der Regel ohne Probleme oder Pannen. Der Gerstensaft-Mehraufwand hält sich in Grenzen.

All unsere Installationen haben ein Grundprinzip: E-Mail liegen primär bei unseren Providern, sie werden per fetchmail abgeholt. Wir nutzen let's encrypt Zertifikate die über einen Reverse-Proxy bereitgestellt werden. Der Zugriff aus dem Internet (über unsere DynDNS Adressen) ist nur über einen Port auf dem Router möglich. Dieser liegt weit ausserhalb der üblichen Muster von Port-Scannern im Netz. Zum Versand wird ausschließlich der entsprechende smtp-auth Server des Provider benutzt. Unsere DynDNS Domänen sind nicht deckungsgleich mit den genutzten Mail-Domänen. --- Damit fahren wir seit Jahren relativ sicher, zumal noch weitere Dinge in Hard- und Software eingesetzt werden.

das Taglicht neigt sich schon zum Ende
F@H

 

[FricklerAtHome]

weitere Info zur BASIS-VM-GROMO

die OVA-Datei der Basis VM für GRO nach dem beschriebenen Muster hat lediglich eine Größe von 1,61 GB. Da sind dann aber noch alle User-Postfächer leer.

@Andy+
Funktionieren die Zugänge jetzt?

Dauerregen ist nicht erfreulich!
F@H

 

[Andy+]

Bin noch nicht dazu gekommen, meine Familie hält mich gerade noch davon ab, das wird wieder mal wieder etwas für die fortgeschrittene Stunde....

 

[Caramlo]

Mit zapper up sollte man derzeit vorsichtig sein. Bei Gro werden derzeit die Community Repos wegen des Updates auf die neue Version zusammengestellt. Da gibt‘s öfter mal unerwartete Effekte, dass das eine oder andere nicht mehr läuft. Von daher habe ich erst einmal alle Updates verschoben bis das durch ist.

 

[FricklerAtHome]

Ja --aktuell auch von meiner Seite eine Bestätigung!

 

[Andy+]

Admin-Interface: Aufruf mit https://<IP-der_VM:8443/ dort dann anmeldem mit USER admin und entsprechendem Passwort

Admin und anmelden als User mit der vollen E-Mail Adresse und dann das Passwort geht.

User-Interface: Aufruf mit https://<IP-der_VM/web/ (also hier Standardport 443 mit Unterverzeichnis) dort anmelden als User mit der vollen E-Mail Adresse und dann das Passwort.

Geht nach wie vor nicht, es kommt dann "Page not found"

mittels https://IP-der_VM:8443/antispam/ auch das RSPAMD Interface zur Verfügung stehen.

Geht auch mit dem Admin account

updates über "zypper ref && zypper up" abgerufen

Das mache ich jedesmal sowieso.

Übrigens muss ich nginx jedes mal manuell starten. Kann ich das umgehen?

 

[FricklerAtHome]

also ich mache nach "zypper ref && zypper up" immer einen Reboot.
(Akutell bitte zurückstellen, es gibt bekannte Probleme wegen eines anstehenden Release-Wechsel!)

Üblicherweise startet nginx automatisch. Wenn du nach einem Reboot auf das Admin-Interface kommst, läuft auch nginx.
Es bleibt das Problem mit dem USER-Interface. Hast du im Admin-Interface eine Mail-Domaine angelegt?
Und zu dieser Domäne auch einen Benutzer eingerichtet?
Gebe bitte das https://<IP-der_VM/web/ direkt in der Browser-Zeile ein, nicht die Links im Admin-Interface nutzen.
Was steht in der /usr/share/grommunio-common/nginx.conf?

Das wäre Frickel-Arbeit! Ich nutze stattdessen gerne einen ein komplettes Neu-Aufsetzen der VM.
Geht aus dem ISO eigentlich geschmeidig zumal man aus der letzten Installation ja noch die Fallstricke kennen sollte.

 

[Andy+]

mache nach "zypper ref && zypper up" immer einen Reboot

Mache ich ebenso.

im Admin-Interface eine Mail-Domaine angelegt ... zu dieser Domäne auch einen Benutzer eingerichtet

Nach Abschluss der Installation angelegt bzw. zugeordnet.

das https://<IP-der_VM/web/ direkt in der Browser-Zeile ein

Mach ich auch so.

 

[Andy+]

in der /usr/share/grommunio-common/nginx.conf

Auf was ist inhaltlich zu achten? Inhalt wie folgt:

include /etc/grommunio-common/nginx/upstreams.d/*.conf;
include /usr/share/grommunio-common/nginx/upstreams.d/*.conf;

error_log /var/log/grommunio/nginx-error.log;
access_log /var/log/grommunio/nginx-access.log;

map $http_user_agent $filter_user_agent {
default 'unknown';
~(iPhone|iPad) ios;
~Android android;
~Linux linux;
~(Windows|MSIE|Mozilla) windows;
~Mac macos;
~(FreeBSD|OpenBSD|NetBSD) bsd;
~Outlook outlook;
~Thunderbird thunderbird;
}

map $http_host $this_host {
"" $host;
default $http_host;
}
map $http_x_forwarded_proto $the_scheme {
default $http_x_forwarded_proto;
"" $scheme;
}
map $http_x_forwarded_host $the_host {
default $http_x_forwarded_host;
"" $this_host;
}
map $http_upgrade $proxy_connection {
default upgrade;
"" close;
}

map $request_uri $topdir {
~(?<captured_topdir>^/[a-zA-Z0-9]+/[a-zA-Z0-9]+)[/] $captured_topdir;
}

server {
listen 80;
listen [::]:80;
server_name _;
return 301 https://$host$request_uri;
include /usr/share/grommunio-common/nginx/traffic_status_params*.conf;
}

server {
server_name _;
listen [::]:443 ssl http2;
listen 443 ssl http2;
include /etc/grommunio-common/nginx/ssl_*.conf;
include /usr/share/grommunio-common/nginx/ssl_params.conf;
include /usr/share/grommunio-common/nginx/proxy_params.conf;
include /usr/share/grommunio-common/nginx/security.conf;

include /usr/share/grommunio-common/nginx/brotli-params*.conf;
include /usr/share/grommunio-common/nginx/traffic_status_params*.conf;
include /etc/nginx/conf.d/grommunio_custom-*.conf.include;

server_tokens off;

include /etc/grommunio-common/nginx/locations.d/*.conf;
include /usr/share/grommunio-common/nginx/locations.d/*.conf;
}

Ich hatte zu Beginn auch die beiden Dateien angelegt:

/var/log/grommunio/nginx-admin-access.log
/var/log/grommunio/nginx-admin-error.log