Kopano ist eine wunderbare Collaboration-Lösung welche mich schon seit vielen Jahren begleitet und welche ich bereits bei vielen zufriedenen Kunden erfolgreich installiert habe. Nur eins hat mich über die Jahre immer und immer wieder gestört: Benutzer werden per LDAP verwaltet, Berechtigungen, Adressbücher usw. ebenso. Nur die Zuordnung von Emailadressen an Ordner damit Mails an diese Adressen immer in den entsprechenden Ordner landen anstatt im Posteingang wird stiefmütterlich behandelt.
Lösungsansätze
Natürlich gibt es für dieses Problem mehrere Lösungsansätze. An dieser Stelle will ich verschiedene Lösungsansätze zeigen und diese mit einem kurzen für und wider gegeneinander stellen. Als Ausgangsbasis dient die in der Kopano Dokumentation beschriebene postfix Integration: https://documentation.kopano.io/kopanocore_administrator_manual/configure_kc_components.html?highlight=postfix#postfix-integration.
Du suchst die "ultimative" Lösung? Dann lies bitte sofort bei "Lösung 4" weiter. Du hättest gerne die Konfigurationen im Detail zu den Lösungen 1 bis 3.5? Dann melde Dich bei mir. Ich habe diese Details hier weggelassen um den Text nicht noch weiter aufzublähen.
Lösung 1: Regeln
In den Einstellungen der webapp oder deskapp können Regeln hinterlegt werden. Eine passende Regel sieht zum Beispiel so aus:
Falls die Nachricht enthält diese Wörter in den transport-headern "info@gehirn-mag.net" Folgende Aktion ausführen Nachricht in Ordner verschieben Gehirn-Mag.Net/Info
Damit die Emailadresse info@gehirn-mag.net bei mir überhaupt ankommt wird diese als kopanoAliases im LDAP eingetragen. Das funktioniert. Nur zentral verwaltet ist was anderes und da ich Fan vom LDAP bin finde ich dies wenig praktikabel. Zumal das für private Ordner ganz nett sein mag. Nur welchem Benutzer ordne ich so eine Regel sinnvoll zu wenn das Ziel ein öffentlicher Ordner sein soll? Nein, diese Lösung überzeugt mich nicht wirklich. Also auf geht es zur Lösung Nummer 2.
Details zu den Regeln gefällig? Die gäbe es hier: https://documentation.kopano.io/user_manual_webapp/settings.html#rules
Lösung 2: procmail
Die eierlegende Wollmilchsau Lösung. Mit procmail kann wirklich ein Regelwerk mit allem Schnick und Schnack erstellt werden. Ein Beispiel könnte wie folgt aussehen:
# Privat Einkaufen: Hibike, ...
:0H
* ^From:.*(newsletter@newsletter.*\\.hibike\\.com|news@news\\.bike-discount\\.de)
| /usr/bin/zarafa-dagent -p / -F "Posteingang/Newsletter/Einkaufen" steffen
Das Beispiel stammt noch aus Zeiten wo Kopano als Zarafa bekannt war und zeigt einen kurzen Einblick in meine privaten Hobbys. Aber egal, als Beispiel absolut ausreichend. Jetzt noch Postfix dazu gebracht, dass er die Mails für die im ersten Beispiel verwendete info@gehirn-mag.net Adresse an procmail übergibt oder falls fetchmail verwendet wird dort als mda eintragen. Egal, irgendwie die Mails an procmail übergeben. Wie ist hier nicht das Thema. Aber mal ehrlich: Hierfür muss ich eine Konfig-Datei im Dateisystem bearbeiten. Das ist ebenfalls nicht das was ich unter zentralem Management an einem Ort wie LDAP verstehe. Wenn ich schon Benutzer in LDAP verwalten tue, dann doch auch bitte mein Problem mit der Zustellung an Ordner.
Also das Fazit zur dieser Lösungsvariante: Toller Funktionsumfang. Was hier nicht mit einem Filter erfasst werden kann geht sonst auch nirgends. Falls die Emails von Dritten via POP3 oder IMAP abgeholt werden müssen hat dies Lösung im Zusammenspiel mit fetchmail einen ganz speziellen Charme. Aber: Eine Konfigurationsdatei anpassen zu müssen sobald sich was ändert ist nicht mein Ding. Nette Lösung, nur leider für mich alles andere als perfekt.
Lösung 3: Ein Hilfsskript verwenden
Bisher waren alle Lösungen noch weit von dem entfernt was ich Lösungsansatz via LDAP genannt hätte. Aber mit Zuhilfenahme von zusätzlichen Skripten lässt sich hier sicherlich was machen. Also fix los programmiert - die erste Fassung welche hierbei entstanden ist war fast so alt wie Zarafa selbst.
Der Gedanke dazu war wie folgt: Wenn die Email für einen öffentlichen Ordner an ein Skript übergeben wird kann dieses im LDAP nachschlagen in welchen Ordner die Email zu legen wäre. Das funktioniert, braucht aber zusätzliche Perlskripte. Ok, mit etwas Aufwand könnte man aus den zwei sicherlich eins machen. Ändert nichts daran, dass man zusätzliche Skripte braucht.
Ich habe die Skripte von damals noch auf die multi-tenancy Variante erweitert und unter https://gitlab.com/Gehirn-Mag.net/kopano-delivery-to-folders abgelegt.
Aber mal ehrlich: Das funktioniert zwar, aber der Aufwand ist hoch. Geht noch einfacher wie die folgenden Beispiele zeigen.
Zwischenlösung 3.5: Direkt in postfix
Naja, der Umweg über procmail mag viel Luxus bringen. Der über das eigene Skript die Möglichkeiten zu tun was man will. Nur braucht man dies nicht immer. kopano-dagent kann auch direkt aus postfix heraus gestartet werden. Das ist schlank, einfach und mehr braucht es in der Regel auch gar nicht.
# Info-Postfach
gehirnInfo unix - n n - - pipe
flags=DORhu user=kopano:kopano argv=/usr/sbin/kopano-dagent admin@gehirn-mag.net -v -C -p / -F Gehirn/Info
Dies funktioniert wunderbar. Die Emailadresse admin@gehirn-mag.net muss es natürlich geben und diese muss im Ordner Gehirn/Info schreiben dürfen. Im LDAP leitet man die entsprechenden Adressen einfach nach gehirnInfo: um. Infos zum postfix pipe Prozess gibt es hier: http://www.postfix.org/pipe.8.html. Doch Moment: Das soll flexibel sein? Wohl eher nicht, der Zielpfad steht ja statisch in der master.cf mit drin. Und genau das ist der Haken an der Sache. Sollte es sich um eine "kleine" Installation handeln wo nur ein paar wenige Adressen in Ordner umgeleitet werden mag das absolut ausreichend sein. Sobald es aber mehr werden oder diese Umleitungen einer gewissen Dynamik unterliegen stößt diese Variante an Ihre Grenzen. Der Zwischenschritt ist dennoch gut und führt uns direkt zur perfekten Lösung welche sich mit minimalen Aufwand realisieren lässt.
Zuviel Log-Ausgaben im mail Log? Dann entferne das -v aus der Argumenten-Liste von kopano-dagent.
Lösung 4: Direkt in postfix mit Dynamik via LDAP
Noch mal schnell in die Doku von postfix pipe rein geschaut: "${nexthop} This macro expands to the next-hop hostname". Na das ist es doch! Also kurz die master.cf entsprechend anpassen.
# Kopano an public Ordner
kpublic unix - n n - - pipe
flags=DORhu user=kopano:kopano argv=/usr/sbin/kopano-dagent admin@gehirn-mag.net -v -C -p / -P ${nexthop}
Das funktioniert ähnlich zur obigen Lösung unter 3.5. Nur steht als Zielordner hier das Makro ${nexthop} welches via LDAP als Wert nach "kpublic:" eingetragen wird. Auch hier sollte es die Emailadresse admin@gehirn-mag.net entsprechend mit den passenden Rechten für den Zielordner geben.
Dies funktioniert natürlich auch mit einem privaten Ordner. Dazu muss lediglich das -P durch ein -F ausgetauscht werden und die Emailadresse auf die des jeweiligen Benutzers getauscht werden. Aber Achtung: Für jeden Benutzer braucht man hier einen eigenen Eintrag in die master.cf von Postfix. Zu umständlich wenn wir es genau betrachten und somit in den Regeln des jeweiligen Kopano Benutzers besser aufgehoben.
Als LDAP-Schema verwende ich wieder das von Lösung 3: https://gitlab.com/Gehirn-Mag.net/kopano-delivery-to-folders/blob/master/sitsPostfixTable.ldif. Letztendlich kann man aber nehmen was man will bzw. ein anderes, unbenutztes Feld zweckentfremden.
dn: PTransSrc=offen@gehirn-mag.net,ou=Gehirn-Mag.Net,...
objectClass: sitsPostfixTransport
objectClass: top
PActive: TRUE
PTransDest: kpublic:Gehirn-Mag.Net/Offen
PTransSrc: offen@gehirn-mag.net
Die dazu passende LDAP Konfig Datei für postfix ldap.kopano-folders.conf:
#
# virtual LDAP Map for Kopano (PTransSrc für Ordner-Ablage)
#
server_host = ldap:///
start_tls = yes
search_base = ou=CharlieB.Schoch-IT.Solutions,dc=Schoch-IT,dc=Solutions
bind_dn = cn=postfix,...
bind_pw = ...
query_filter = (&(objectClass=sitsPostfixTransport)(PTransSrc=%s)(PTransDest=kpublic:*)(PActive=TRUE))
result_attribute = PTransDest
debuglevel = 0
Diese Datei muss dann noch in der main.cf von postfix den virtual mailbox maps hinzugefügt werden:
virtual_mailbox_maps =
ldap:/etc/postfix/ldap.dovecot-virtual-users.conf,
ldap:/etc/postfix/ldap.kopano-virtual-users.conf,
ldap:/etc/postfix/ldap.kopano-folders.conf,
ldap:/etc/postfix/ldap.kopano-groups.conf
Wie Du sehen kannst habe ich neben den Kopano-Benutzern auch noch die Gruppen aktiv und jetzt den Transport in den öffentlichen Ordner. Darüber hinaus gibt es bei mir auf diesem Server noch einen Dovecot für die reinen IMAP-Postfächer. Dieser Eintrag muss von Dir logischerweise sinnvoll angepasst werden.
Wie man dovecot und kopano-gateway auf der gleichen Adresse mit den gleichen Ports betreiben kann verrate ich Dir in einem der nächsten Blog-Beiträge 😉
Auf der Suche nach anderen Stellen im Internet die diesen Weg beschreiben habe ich die Doku von LECKERBEEFde gefunden. Zwar funktioniert die Homepage nicht mehr, aber den GitHub Eintrag gibt es noch: https://github.com/LECKERBEEFde/zarafa-deliver-mail-to-public-folder. Wie Du am Link erkennst bezieht sich diese Doku noch auf Zarafa. Das macht aber rein gar nichts, die lässt sich super einfach in Richtung Kopano umbauen. Und LECKERBEEFde verwendet ein Windows Active Directory. Da er sich nicht die Mühe gemacht hat ein spezielles Schema zu erstellen tut er, wie angesprochen, ein vorhandenes Feld für seine Zwecke "verwenden". Eine tolle Doku welche wirklich zu lesen lohnt.
Lösung 5: Kopano dagent Plugin
Wie, es gibt noch eine Lösung 5? Natürlich und die will ich Dir auch gar nicht vorenthalten. Ganz so egal ist Kopano das Thema Zustellung an den öffentlichen Ordner nämlich gar nicht. Hier mag die Einleitung etwas anderes suggeriert haben, deswegen nochmals der Hinweis: Es gibt einen Lösungsweg und der steht sogar im Handbuch: https://documentation.kopano.io/kopanocore_administrator_manual/special_kc_configurations.html#move-to-public. Dazu wird kopano-dagent über ein Plugin erweitert und eine Konfigurationsdatei entsprechend bearbeitet. Selbstverständlich funktioniert auch dies wunderbar!
Nun mein persönliches Fazit dazu: Eigentlich wollte ich die Zustellung an die öffentlichen Ordner via LDAP verwalten anstatt wie hier in einer Konfigurationsdatei. Also eine funktionierende Lösung die jedoch eine andere Strategie verwendet wie die von mir gewünschte. Die ist gut weil Sie funktioniert. Nur nichts für mich.
Du hast nur eine kleine Installation? Du editierst eine einfache Text-Konfigdatei lieber als LDIF-Daten? Du suchst eine Lösung die offiziell von Kopano angeboten wird? Dann bist Du hier genau richtig!
Fazit
Lösung 4 ist wunderbar. Sie ist schlank, einfach und schlichtweg elegant. Der zusätzliche Aufwand ist kaum nennenswert wenn man ohnehin dabei ist postfix mit Kopano zu verbinden. Einmal eingerichtet lässt sich das Verhalten komplett via LDAP beeinflussen. So macht es Spaß. Das ist schnell erledigt.
Was ich mir jetzt noch für die Zukunft wünschen würde und da schließt sich der Kreis zur Einleitung: Hinweise in der Kopano Dokumentation wie man dies macht wären super, richtig nett wäre die Erweiterung des Kopano LDAP Schemas um ein passendes Feld. Aber: Genau genommen ist diese Lösung schnell im Internet recherchiert oder durch das Studium der postfix Dokumentation rasch hergeleitet. Der Mehraufwand ist kaum nennenswert. Die Kopano Dokumentation ist meiner Meinung nach eher als Lösungsansatz zu verstehen da es zu viele verschiedene Umgebungen mit ihren ganz besonderen Eigenschaften gibt. Diese kleine zusätzliche postfix Anpassung fällt somit unterm Strich kaum ins Gewicht.
Und vergessen wollen wir nicht, dass es sehr wohl einen Kopano-Lösungsweg gibt. Nur finde ich persönlich, dass dieser nicht ganz in die Zeiten von LDAP-Bäumen, egal ob openLDAP, eDir oder Windows AD passt.
Darüber hinaus zeigt sich meiner Meinung nach noch ein ganz anderer wichtiger Aspekt: Kopano wirbt immer damit wie gut die Lösung in bestehende Strukturen integriert werden kann. Integration bedeutet Schnittstellen zu haben. Diese sind entsprechend dokumentiert und somit finden sich in kürzester Zeit verschiedene Lösungsansätze. Siehe oben. Das ist mal richtig toll! Leider gibt es viele andere Software da draußen wo man nicht mal einen Lösungsansatz finden würde...
