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.

Lösung 1: Regeln

In den Einstellungen der webapp oder deskapp können Regeln hinterlegt werden. Eine passende Regel sieht zum Beispiel so aus:

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.

• Auf Zarafa bezogen, lässt sich aber 1 zu 1 auf Kopano umsetzen: http://wiki.zarafa.com/index.php/Email_delivery_with_procmail
• Mehr Details zu fetchmail gefällig? Die gibt es hier: https://sourceforge.net/projects/fetchmail/
• Da die procmail Homepage selbst derzeit nicht zu erreichen ist die deutsche procmail-FAQ von Butschek: https://www.butschek.de/procmail-faq/

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.

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.

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.

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.

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...