Wiki source for EMailGroupware
===== Groupware, E-Mail, Collaboration =====
== Serverlösungen und Konzepte ==
((1)) Standards und allgemeine Informationen
Folgende Informationen können bei Planung einer konkreten Lösung hilfreich sein:
- [[https://de.wikipedia.org/wiki/Microsoft_Exchange_Server#Alternativen Überblick über Alternativen zu Exchange bei Wikipedia]].
- Microsoft nutzt in seinen Server- und Client-Lösungen das proprietäre MAPI-Protokoll. Dies bedeutet, dass jegliche hybride Lösungen oder Migrationen auf //open source// es erfordern, die Bereitstellung entsprechender Schnittstellen zu MAPI abzusichern. [[https://de.wikipedia.org/wiki/Messaging_Application_Programming_Interface Informationen zu MAPI in Wikipedia]].
((1)) Versuch, E-Mail-Server unter TrueNAS im Jail zu installieren
Mit [[https://www.iredmail.org/index.html iRedMail]].
((2)) Anleitung
Wir folgen der [[https://docs.iredmail.org/install.iredmail.on.freebsd.with.jail.html Anleitung hier]]. Nachstehend werden nur die zusätzlichen Erläuterungen erfasst, die nicht in der offiziellen Anleitung enthalten sind bzw. Abweichungen davon, die notwenig waren.
((2)) Kein Erfolg!
Leider war wegen der nicht erfüllten Paketabhändigkeiten noch kein Erfolg mit iRedMail in jail zu verzeichnen.
((1)) iRedMail unter Ubuntu 20.04
Mit der Beschreibung [[https://docs.iredmail.org/install.iredmail.on.debian.ubuntu.html#access-webmail-and-other-web-applications hier]] funktionierte es einwandfrei!
((2)) Achtung Firewall!
Unter Ubuntu 20.04 wird mal gern eine Firewall (nftables) aktiviert. Werden nicht die Standardports genutzt, ist die Einstellung u. U. anzupassen, denn die Standardports öffnet (wohl) die Installationsroutine von iRedMail selbst. Wir haben es gemerkt, nachdem wir eine Weile 8443 (statt 443) genutzt hatten und zurück wollten...
=> siehe hier:
##/etc/nftables.conf##
nach Anpassung
##systemctl restart nftables##
nützlich auch:
##nft list ruleset##
((2)) Manuelle Erneuerung der Zertifikate
Besonderheit: da wir spezielle Ports (8443) für die Weboberfläche (insbesondere SOGo) verwenden (hinter dem Router sind verschiedene WWW-Dienste!), ist eine manuelle Erneuerung der Let's-Encrypt-Zertifikate notwendig. Die Challenge setzt dort voraus, dass der Webserver unter Standardports antwortet, aber dies ist in der vorhandenen Konfiguration für SOGo eben nicht möglich...
Zu beachten ist, dass die Änderung der Ports im Router nicht ausreicht! (=> von 10.0.0.2 auf 10.0.0.3) Vorher muss man noch die nginx-Konfiguration ändern => das Abhören entsprechender Ports sowie die Umleitung auf SOGo müssen umgeschaltet werden! Da dies mit den entsprechenden include-Dateien schwer zu steuern war, ist es besser, dies temporär mit einer einfachen ##nginx.conf## zu erledigen.
So geht es bei uns recht einfach:
((3)) Ports umleiten
Auf dem Lancom Ports 80+443 auf IP des mail.domain.com statt nxc.domain.com
((3)) Alle Besonderheiten von ##nginx## ausschalten
Folgende bash-Commands nutzen:
##service nginx stop
cd /etc/nginx/
mv nginx.conf nginx_sogo.conf## // normale sichern##
mv nginx_certRenew.conf nginx.conf## // die für das Zertifikate-Update aktivieren
in der index.html die Umleitung auf SoGO ausschalten##
cd /var/www/html/
mv index.html index_sogo.html
mv index_certRenew.html index.html
service nginx start##
((3)) Certbot Update
##certbot renew --post-hook '/usr/sbin/service postfix restart; /usr/sbin/service nginx restart; /usr/sbin/service dovecot restart'##
((3)) Alles zurück
Die Konfiguration zurück zum Produktionssystem:
##service nginx stop
cd /var/www/html/
mv index.html index_certRenew.html
mv index_sogo.html index.html
cd /etc/nginx/
mv nginx.conf nginx_certRenew.conf
mv nginx_sogo.conf nginx.conf
service nginx start##
((3)) Ports auf Lancom
Ports auf Lancom in den vorherigen Zustand zurückstellen (80+443 mail.domain.com => nxc.domain.com).
((2)) Customizing SOGo
Die Startseite des Mail-Webclients (SOGo) kann Firmenlogo enthalten. Die entsprechenden Dateien werden wie folgt eingefügt:
**Achtung: "user" gegen Benutzernamen austauschen!**
##""
cd /usr/lib/GNUstep/SOGo/Templates/MainUI/<br/>
rm SOGoRootPage.wox<br/>
cp /home/user/sogo/SOGoRootPage.wox /usr/lib/GNUstep/SOGo/Templates/MainUI/<br/>
chown root:root SOGoRootPage.wox<br/>
service sogo restart""##
((2)) Upgrades von SoGO
Bei Installation erscheint folgende Meldung:
##
Important SOGo post-installation note
SOGo database schemas are _not_ automatically upgraded by the packaging system.
Please check the list of database schema upgrade scripts
inside /usr/share/doc/sogo/ and apply them if needed.
More details can be found in the Upgrading section:
https://sogo.nu/files/docs/SOGoInstallationGuide.html#_upgrading
##
((1)) Problem mit "Unbehandelte Fehlerantwort"
Nach einem Update war Login in das SOGO-Webinterface nicht mehr möglich und endete mit der roten Meldung "Unbehandelte Fehlerantwort".
((2)) Dateien
Unter ##/etc/nginx/##:
##templates/sogo.tmpl##
(korrigierte Datei siehe ##ITIntern => config => MailServer##)
((2)) Problemlösung
Eine sinnvolle [[https://github.com/mailcow/mailcow-dockerized/issues/4537 Diskussion mit Problemlösung auch unter iRedMail ist bei github zu finden]]
Das Thema kann man [[https://stackoverflow.com/questions/25762111/how-to-fix-upstream-sent-too-big-header-while-reading-response-header-from-upstr/25762701#25762701 mit folgender Diskussion auch vertiefen]].
Im Ergebnis liegt das Problem darin, dass irgendwelche Proxy-Einstellungen, die offenbar beim iRedMail-Paket genauso gelten, nicht korrekt waren. Ich weiß nicht mehr, ob das daraus resultiert, dass ich die Konfiguration
- selbst geändert habe,
- seit iRedMail-Installation schon viele Updates durchgeführt wurden
- der Fehler sich sonst wie eingeschlichen hat
Eins ist sicher - es hilft, in der o. g. Datei die im oben verlinkten Artikel genannten Anpassungen vorzunehmen. Allerdings ist es nicht so einfach, die richtigen Stellen zu finden... Es sind in etwa folgende:
Im Abschnitt ##location ^~ /SOGo { }## (es scheint das Hauptverzeichnis zu sein)
habe ich nach ##proxy_set_header Host $host;## folgende Zeilen eingefügt:
##proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;##
Im Abschnitt ##location ^~ /Microsoft-Server-ActiveSync { }##
habe ich nach ##proxy_read_timeout 3540;## folgende Zeile eingefügt:
##proxy_buffers 64 512k;##
Schließlich im Abschnitt ##location ^~ /SOGo/Microsoft-Server-ActiveSync { }##
habe ich nach ##proxy_read_timeout 3540;## wieder die Zeile eingefügt:
##proxy_buffers 64 512k;##
Danach muss man noch die Dienste neu starten:
##service sogo restart
service nginx restart##.
((2)) Ähnliches Problem bei reverse proxy davor!
Ein (zusätzliches?) NGINX-reverse-proxy vor der Lösung (iRedMail mit SoGo) führt dazu, dass das Problem unter Umständen auflebt. Lösung ist Eingabe in dem Proxy der Parameter:
%%(perl)
proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;
%%
Wenn man den "Nginx Proxy Manager" nutzt, muss man dies einfach unter "Advanced" der Proxy-Weiterleitung einfügen.
----
== Serverlösungen und Konzepte ==
((1)) Standards und allgemeine Informationen
Folgende Informationen können bei Planung einer konkreten Lösung hilfreich sein:
- [[https://de.wikipedia.org/wiki/Microsoft_Exchange_Server#Alternativen Überblick über Alternativen zu Exchange bei Wikipedia]].
- Microsoft nutzt in seinen Server- und Client-Lösungen das proprietäre MAPI-Protokoll. Dies bedeutet, dass jegliche hybride Lösungen oder Migrationen auf //open source// es erfordern, die Bereitstellung entsprechender Schnittstellen zu MAPI abzusichern. [[https://de.wikipedia.org/wiki/Messaging_Application_Programming_Interface Informationen zu MAPI in Wikipedia]].
((1)) Versuch, E-Mail-Server unter TrueNAS im Jail zu installieren
Mit [[https://www.iredmail.org/index.html iRedMail]].
((2)) Anleitung
Wir folgen der [[https://docs.iredmail.org/install.iredmail.on.freebsd.with.jail.html Anleitung hier]]. Nachstehend werden nur die zusätzlichen Erläuterungen erfasst, die nicht in der offiziellen Anleitung enthalten sind bzw. Abweichungen davon, die notwenig waren.
((2)) Kein Erfolg!
Leider war wegen der nicht erfüllten Paketabhändigkeiten noch kein Erfolg mit iRedMail in jail zu verzeichnen.
((1)) iRedMail unter Ubuntu 20.04
Mit der Beschreibung [[https://docs.iredmail.org/install.iredmail.on.debian.ubuntu.html#access-webmail-and-other-web-applications hier]] funktionierte es einwandfrei!
((2)) Achtung Firewall!
Unter Ubuntu 20.04 wird mal gern eine Firewall (nftables) aktiviert. Werden nicht die Standardports genutzt, ist die Einstellung u. U. anzupassen, denn die Standardports öffnet (wohl) die Installationsroutine von iRedMail selbst. Wir haben es gemerkt, nachdem wir eine Weile 8443 (statt 443) genutzt hatten und zurück wollten...
=> siehe hier:
##/etc/nftables.conf##
nach Anpassung
##systemctl restart nftables##
nützlich auch:
##nft list ruleset##
((2)) Manuelle Erneuerung der Zertifikate
Besonderheit: da wir spezielle Ports (8443) für die Weboberfläche (insbesondere SOGo) verwenden (hinter dem Router sind verschiedene WWW-Dienste!), ist eine manuelle Erneuerung der Let's-Encrypt-Zertifikate notwendig. Die Challenge setzt dort voraus, dass der Webserver unter Standardports antwortet, aber dies ist in der vorhandenen Konfiguration für SOGo eben nicht möglich...
Zu beachten ist, dass die Änderung der Ports im Router nicht ausreicht! (=> von 10.0.0.2 auf 10.0.0.3) Vorher muss man noch die nginx-Konfiguration ändern => das Abhören entsprechender Ports sowie die Umleitung auf SOGo müssen umgeschaltet werden! Da dies mit den entsprechenden include-Dateien schwer zu steuern war, ist es besser, dies temporär mit einer einfachen ##nginx.conf## zu erledigen.
So geht es bei uns recht einfach:
((3)) Ports umleiten
Auf dem Lancom Ports 80+443 auf IP des mail.domain.com statt nxc.domain.com
((3)) Alle Besonderheiten von ##nginx## ausschalten
Folgende bash-Commands nutzen:
##service nginx stop
cd /etc/nginx/
mv nginx.conf nginx_sogo.conf## // normale sichern##
mv nginx_certRenew.conf nginx.conf## // die für das Zertifikate-Update aktivieren
in der index.html die Umleitung auf SoGO ausschalten##
cd /var/www/html/
mv index.html index_sogo.html
mv index_certRenew.html index.html
service nginx start##
((3)) Certbot Update
##certbot renew --post-hook '/usr/sbin/service postfix restart; /usr/sbin/service nginx restart; /usr/sbin/service dovecot restart'##
((3)) Alles zurück
Die Konfiguration zurück zum Produktionssystem:
##service nginx stop
cd /var/www/html/
mv index.html index_certRenew.html
mv index_sogo.html index.html
cd /etc/nginx/
mv nginx.conf nginx_certRenew.conf
mv nginx_sogo.conf nginx.conf
service nginx start##
((3)) Ports auf Lancom
Ports auf Lancom in den vorherigen Zustand zurückstellen (80+443 mail.domain.com => nxc.domain.com).
((2)) Customizing SOGo
Die Startseite des Mail-Webclients (SOGo) kann Firmenlogo enthalten. Die entsprechenden Dateien werden wie folgt eingefügt:
**Achtung: "user" gegen Benutzernamen austauschen!**
##""
cd /usr/lib/GNUstep/SOGo/Templates/MainUI/<br/>
rm SOGoRootPage.wox<br/>
cp /home/user/sogo/SOGoRootPage.wox /usr/lib/GNUstep/SOGo/Templates/MainUI/<br/>
chown root:root SOGoRootPage.wox<br/>
service sogo restart""##
((2)) Upgrades von SoGO
Bei Installation erscheint folgende Meldung:
##
Important SOGo post-installation note
SOGo database schemas are _not_ automatically upgraded by the packaging system.
Please check the list of database schema upgrade scripts
inside /usr/share/doc/sogo/ and apply them if needed.
More details can be found in the Upgrading section:
https://sogo.nu/files/docs/SOGoInstallationGuide.html#_upgrading
##
((1)) Problem mit "Unbehandelte Fehlerantwort"
Nach einem Update war Login in das SOGO-Webinterface nicht mehr möglich und endete mit der roten Meldung "Unbehandelte Fehlerantwort".
((2)) Dateien
Unter ##/etc/nginx/##:
##templates/sogo.tmpl##
(korrigierte Datei siehe ##ITIntern => config => MailServer##)
((2)) Problemlösung
Eine sinnvolle [[https://github.com/mailcow/mailcow-dockerized/issues/4537 Diskussion mit Problemlösung auch unter iRedMail ist bei github zu finden]]
Das Thema kann man [[https://stackoverflow.com/questions/25762111/how-to-fix-upstream-sent-too-big-header-while-reading-response-header-from-upstr/25762701#25762701 mit folgender Diskussion auch vertiefen]].
Im Ergebnis liegt das Problem darin, dass irgendwelche Proxy-Einstellungen, die offenbar beim iRedMail-Paket genauso gelten, nicht korrekt waren. Ich weiß nicht mehr, ob das daraus resultiert, dass ich die Konfiguration
- selbst geändert habe,
- seit iRedMail-Installation schon viele Updates durchgeführt wurden
- der Fehler sich sonst wie eingeschlichen hat
Eins ist sicher - es hilft, in der o. g. Datei die im oben verlinkten Artikel genannten Anpassungen vorzunehmen. Allerdings ist es nicht so einfach, die richtigen Stellen zu finden... Es sind in etwa folgende:
Im Abschnitt ##location ^~ /SOGo { }## (es scheint das Hauptverzeichnis zu sein)
habe ich nach ##proxy_set_header Host $host;## folgende Zeilen eingefügt:
##proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;##
Im Abschnitt ##location ^~ /Microsoft-Server-ActiveSync { }##
habe ich nach ##proxy_read_timeout 3540;## folgende Zeile eingefügt:
##proxy_buffers 64 512k;##
Schließlich im Abschnitt ##location ^~ /SOGo/Microsoft-Server-ActiveSync { }##
habe ich nach ##proxy_read_timeout 3540;## wieder die Zeile eingefügt:
##proxy_buffers 64 512k;##
Danach muss man noch die Dienste neu starten:
##service sogo restart
service nginx restart##.
((2)) Ähnliches Problem bei reverse proxy davor!
Ein (zusätzliches?) NGINX-reverse-proxy vor der Lösung (iRedMail mit SoGo) führt dazu, dass das Problem unter Umständen auflebt. Lösung ist Eingabe in dem Proxy der Parameter:
%%(perl)
proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;
%%
Wenn man den "Nginx Proxy Manager" nutzt, muss man dies einfach unter "Advanced" der Proxy-Weiterleitung einfügen.
----
