Kopano4S (Zarafa 2.0)

[Jens H]

Ich glaube ich weiß jetzt, wo wir aneinander vorbei reden. Ich habe bei meinem Domainsevice-Provider KEINE Mailadressen gekauft bzw. eingerichtet. Daher muss ich sie von dort nicht aktiv abholen. Ich habe in der Domainverwaltung einfach analog zum DNS Eintrag für meine Domain, der auf die IP Adresse meiner Synology verweist, den MX Eintrag auf Mail.meinedomain.at gelegt. Auf diese Art lege ich mir selber beliebig viele Mailadressen mit meiner Domain an und verteile sie an die lokalen User wie ich will. Das klappte mit meiner alten 214 wunderbar. Aber anders als ich oben geschrieben habe, nicht mit Zarafa, sondern über den Mailserver. Dort habe ich die Alias/User Tabellen eingerichtet und die eingehenden Mails an meine Providermails weitergeleitet. Vermutlich kann Kopano das was ich will gar nicht und ich müsste es wieder mit dem Mailserver lösen.

 

[Matis]

Das ist auch richtig, pop3 und imap bei den usern brauchst du nur, wenn die Clients nicht active sync sondern eines der beiden zum Austausch nutzen.
Ich denke es war seither nicht ganz klar, dass du 1-2 domains/adressen per fetchmail nutzen willst und eine domain direkt über mx zugeschickt haben willst.
Ist denn der provider entsprechend konfiguriert, dass er nicht puffert?
Mails verschicken willst du aber über das provider relay?
Ich kann dir nicht sagen, ob relay und direkt zuschicken gemeinsam geht.
Ich verstehe den Sinn auch nicht. Du hast alle möglichen Probleme mit offener Tür und Mailproblemen und keinerlei Ausfallsicherheit, wenn deine Synology nicht läuft. Wenn du deine emails auch nicht ein paar Sekunden bei Provider haben willst, dürftest du auch das relay nicht nutzen und wer sie abgreifen will hat u.U. genug andere Möglichkeiten. Auch beim direkten Versand läuft die Adressierung über deinen Provider.
Zu diesem gemischten Betrieb kann ich nichts sagen, hab ich nie probiert oder mich eingelesen.
Ich nutze für alle meine domains fetchmail und dann ist das alles straight forward mit der Konfiguration, ich hab nur 443 offen und muss keine Angst haben, dass mir bei einem Ausfall emails flöten gehen.

 

[Andy+]

Diese Mischsituation war tatsächlich nicht so klar. Vielleicht auch mal im Kopano-Forum gucken

https://forum.kopano.io/

was sich da findet. Es müssen sich doch Hinweise finden, wie Kopano zu konfigurieren ist für solche Fälle, bzw. der Mailserver von Kopano dann insgesamt.

 

[Jens H]

Danke Euch beiden. Vermutlich ist das wirklich keine gute Idee. Obwohl ich bisher keine Probleme mit dem offenen Port 25 hatte. Nach 2 Fehlversuchen am Port 25 habe ich ihn dicht gemacht. Werde es lassen und mich mit der jetzt höheren Sicherheit zufrieden geben, weil kaum mehr Ports offen sein müssen.

 

[Andy+]

Vielleicht macht es Sinn, Tosoboso mal direkt zu kontaktieren, denn mit MX Einträgen auf der eigenen DS habe ich keinerlei Erfahrung, ich kenne dazu nur die Hinweise im Intro vom WebAdmin von K4S.

 

[Matis]

Was mir aber bei dem ganzen Probieren aufgefallen ist: greift SpamAV auch bei fetchmail? ich habe den Eindruck nicht. Kann man das ändern?

 

[Andy+]

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

Beitrag 1418

 

[Matis]

Danke, hatte ich nicht mehr auf dem Schirm.
Dann ist das nochmal ne Menge Arbeit für Tosoboso und ein nächster großer Schritt.

 

[big-tini]

Ich hätte mal eine Frage zum Thema SSL Zertifikat.
Vielleicht ist das schon mal besprochen worden, aber ich finde leider nichts im Forum.

Mein Problem: Mein Let´s Encrypt Zertifikat ist heute abgelaufen.
1. Ich habe in der Syno unter Systemsteuerung-Sicherheit-Zertifikat dieses verlängert. Es ist nach wie vor als Standard Zertifikat hinterlegt.
2. Den Befehl kopano4s-init ssl im Kopano Admin im Bereich "K-Cmds" ausgeführt.
Der Befehl wird ausgeführt, allerdings bekomme ich noch immer einen Zertifikatsfehler, sobald ich via https://meinedomain versuche die WebApp zu erreichen.
Schaue ich mir dann im Webbrowser die Zertifikatsdetails an, sehe ich, dass es sich vom Ablaufdatum um das alte bereits abgelaufene handelt.

Es kommt mir so vor, als ob es im Container nicht ersetzt wurde?
Kann mir vielleicht jemand sagen, wo und wie ich das kontrollieren kann oder mir den Pfad nennen, wo es abgelegt wird?

Bin gerade ein wenig ratlos, auch die mobilen Endgeräte funktionieren logischerweise nicht mehr...:-(

Im Einsatz habe ich die Version 1.05

 

[Tosoboso]

Ich glaube ich weiß jetzt, wo wir aneinander vorbei reden. Ich habe bei meinem Domainsevice-Provider KEINE Mailadressen gekauft bzw. eingerichtet. Daher muss ich sie von dort nicht aktiv abholen. Ich habe in der Domainverwaltung einfach analog zum DNS Eintrag für meine Domain, der auf die IP Adresse meiner Synology verweist, den MX Eintrag auf Mail.meinedomain.at gelegt. Auf diese Art lege ich mir selber beliebig viele Mailadressen mit meiner Domain an und verteile sie an die lokalen User wie ich will. Das klappte mit meiner alten 214 wunderbar. Aber anders als ich oben geschrieben habe, nicht mit Zarafa, sondern über den Mailserver. Dort habe ich die Alias/User Tabellen eingerichtet und die eingehenden Mails an meine Providermails weitergeleitet. Vermutlich kann Kopano das was ich will gar nicht und ich müsste es wieder mit dem Mailserver lösen.

Hi, Kopano4s hat einen kompletten Postfix unter der Haube.
K4s kann damit alles, was der Synology Mail Server kann.zum Weiterverteilen von Mails, siehe Alias-BCC in der K4s-Admin-GUI.
Ein wichtiger Punkt: k4s Postfix arbeitet frei von lokalen Accounts mit virtueller Domain gegen LMTP und damit müssen alle Alias Regeln auf Mail-Adressen verweisen. Dein Verteilen auf lokale User muss also nun auf eMail Alias Basis gehen (mache ich auch so).
Was Fetchmail angeht, so arbeitet das aktuell OHNE Postfix direkt auf den Kopano Dagent und an diser Stelle können keine Aliase greifen. In Zukunft ist ein Fetchmail MTA Modus geplant, der an Postfix Routet mit Aliasing, SpamAv etc.
-TosoBoso

 

[Tosoboso]

Ich hätte mal eine Frage zum Thema SSL Zertifikat. Mein Problem: Mein Let´s Encrypt Zertifikat ist heute abgelaufen.
1. Ich habe in der Syno unter Systemsteuerung-Sicherheit-Zertifikat dieses verlängert. Es ist nach wie vor als Standard Zertifikat hinterlegt. 2. Den Befehl kopano4s-init ssl im Kopano Admin im Bereich "K-Cmds" ausgeführt.
Der Befehl wird ausgeführt, allerdings bekomme ich noch immer einen Zertifikatsfehler, sobald ich via https://meinedomain versuche die WebApp zu erreichen. Schaue ich mir dann im Webbrowser die Zertifikatsdetails an, sehe ich, dass es sich vom Ablaufdatum um das alte bereits abgelaufene handelt. Es kommt mir so vor, als ob es im Container nicht ersetzt wurde? Kann mir vielleicht jemand sagen, wo und wie ich das kontrollieren kann oder mir den Pfad nennen, wo es abgelegt wird?

Hi,
nach deinen Beschreibungen ist davon auszugehen, dass dein erneuertes Zertifikat platziert wurde und du im Browser noch alte Sieten gechached hast. Du solltes also den Cache leeren.
Mit > sudo ls -al /etc/kopano/ssl/ kannst du von der Synology Cmd-Line aus Prüfen welchen Stand / Zeitstempel die Zertifikate haben. Wenn du die Funktion Refresh SSL aktiviert hast, vergelicht k4s übrigens die Dateien in /etc/kopano/ssl/ mit dem Synology Default Zertifikat auf Binär gleichheit und kopiert das Zertifikat selbstständig rüber; kopano4s-init ssl ist also nicht immer nötig.
Ansonsten kommen die Zertifikate im Container nur zum Einsatz, wenn du dirket auf die Ports 9443 bzw. 25 gehst. Nach deiner Beschreibung greibst du via Reverse-Proxy ~/webapp und Port 443 zuund damit wird dir Das Zertifikat der Synology angezeigt. Deswegen miene Diagnose, dass du den Browser cache leeren musst. Wenn du dein Zertifikat z.B. mail.meinedomain auf Port 25 SMTP TLS Testen willst bzgl. Verschlüsselung mit aktivem Zertifikat dann nimm Tools wie mxtoolbox.
-TosoBoso

 

[Jens H]

Hi, Kopano4s hat einen kompletten Postfix unter der Haube.
K4s kann damit alles, was der Synology Mail Server kann.zum Weiterverteilen von Mails, siehe Alias-BCC in der K4s-Admin-GUI.
Ein wichtiger Punkt: k4s Postfix arbeitet frei von lokalen Accounts mit virtueller Domain gegen LMTP und damit müssen alle Alias Regeln auf Mail-Adressen verweisen. Dein Verteilen auf lokale User muss also nun auf eMail Alias Basis gehen (mache ich auch so).
Was Fetchmail angeht, so arbeitet das aktuell OHNE Postfix direkt auf den Kopano Dagent und an diser Stelle können keine Aliase greifen. In Zukunft ist ein Fetchmail MTA Modus geplant, der an Postfix Routet mit Aliasing, SpamAv etc.
-TosoBoso

Ja, so habe ich das auch verstanden.
Habe daher unter Alias-BCC wie folgt eingetragen:

Alias Recipient
vorname@meinedomain.at k-usermailadresse

Aber das klappt nicht.

Mail.log steht u.a.:
relay=127.0.0.1[127.0.0.1]:2003, delay=0.18, delays=0.06/0/0.05/0.07, dsn=5.1.1, status=bounced (host 127.0.0.1[127.0.0.1] said: 503 5.1.1 User does not exist (in reply to RCPT TO command))
Jan 25 12:31:05 kopano4s postfix/bounce[5432]: warning: 0318D261B: undeliverable postmaster notification discarded
Jan 25 12:31:05 kopano4s postfix/qmgr[332]: 0318D261B: removed

 

[Andy+]

Ich war etwas erstaunt, dass es bereits eine Version 10 von Kopano gibt. Gibt es einen Grund für den raschen Wechsel von v8 zu v9 zu v10?

Derzeitiger Stand:
core 10.0.1.32
files 3.0.0.5
webapp 4.0.2609
deskapp 2.5.4

 

[Jens H]

Habe die Version 9.0.2, das ist die über das Paket-Zentrum installierte. Ist ein Update empfehlenswert, oder soll ich warten, bis über das Paketzentrum was angeboten wird? Gibt es ein Changelog?
Wie kann man die Versionen der anderen apps (webapp, deskapp) auslesen?

 

[Andy+]

Wir sprechen über zweierlei Kopanoversionen. Die von mir genannten sind die neusten Betaversionen von Kopano, deren core irgendwann als v10.x.x.x in einen Container von Tosoboso integriert werden für K4S. Dort ist der derzeitige Stand von vor 22:

C-Core-9.0.2_Webapp-4.0.2581_Z-Push-2.5.1
S-Core-8.7.9_Webapp-3.5.14_Z-Push-2.5.1
D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1
M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5

Neuere gibt es derzeit nicht, somit solltest Du auf dem neusten Stand sein. Das heisst warten und Geduld. Mich interessiert nur, was so wichtig ist, dass Kopano kurz nach Erscheinen der v9 bereits jetzt schon eine v10 ausrollt.

 

[Jens H]

Gibt es Empfehlungen für die zuzuordnende Menge an RAM? Ich habe zum installierten 4 GB Riegel noch einen weiteren 8er eingebaut und bei "Tuning" 20% angegeben. Kopano bedient 3 User, alle per fetchmail, mit eher wenig Mailverkehr und arbeitet meinem Gefühl nach sehr schnell. Obwohl auch eine Homepage läuft, blinken die Festplatten seltener als auf meiner 214er, die nur als Dataiablage dient. Letzteres irritiert mich etwas, das ist aber was für einen anderen Thread.

 

[honk013]

12GB RAM hört sich doch schon gut an. Schaue Dir mal den Thread #1393 ff. an bzgl. Tuning.

 

[Andy+]

Alleine schon durch das Mehr an RAM ist das Weniger an HDD-Aktivitäten nachvollziehbar. Bezüglich dem verbauten RAM könntest Du bereits auf 60% gehen. 40% gehen mE. bereits schon ab 4 GB RAM, wenn viele APPs laufen ggf. erst ab 8 GB.

 

[Jens H]

Habe mal auf 40% erhöht.

Unabhängig davon hat ein Handy seit heute ein Problem, dass keine Mails mehr reinkommen iPhone. In der Webapp trudeln die Mails aber ein. Habe schon folgendes erfolglos probiert:
Account am Handy gelöscht und neu angelegt.
Account testweise auf einem anderen iPhone angelegt.
Kopano vom Paketdienst aus neu gestartet.

Die Mails liegen nach wie vor am Server und kommen am Handy nicht an. Unter Devices werden alle Geräte ordnungsgemäß angezeigt, vor wenigen Minuten synchronisiert.

Hat jemand eine Idee? Gibt es einen Befehl, um den Push Dienst neu zu initiieren?

Edit:
Hab nochmal ein Postfix init und restart gemacht, und nachdem das nix gebracht hat einfach gewartet. Seit einer halben Stunden synchronisiert alles wieder. Schon eigenartig, auf den anderen Handys gab es keine Unterbrechung. Schon blöd, wenn man sich nicht darauf verlassen kann, dass alles reinkommt.

 

[Jens H]

Da in einer der Logdateien immer zwischen 6 und 7 in der Früh eine Fehlermeldung kam betreffend eines nicht zustellbaren Emails an root@meinedomain.at habe ich nun einen entsprechenden alias- Eintrag erstellt, und sieht da, soeben ist folgendes Mail eingetroffen:

/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

Wie ist das zu bewerten? Offenbar soll jeden Tag eine neue Logdatei angelegt werden, und das klappt nicht.