The following is a proof of concept describing how the integration of Benno MailArchiv into an existing hosting infrastructure can be implemented in practice. The following configurations are described.

• Automatic provisioning
• Mail import
• Authentication

The examples explain the connection to the respective backend systems of a hosting provider using easily understandable shell scripts and simple text files as a replacement for the databases typically used here.

The scripts and "example databases" presented here allow for quick integration into your own hosting systems and implementation in any programming language of your choice.

The fictitious backend system used in this proof of concept (PoC) stores the data in an SQLite database, provisioning.sqlite. The database is shown here as an example with four tables.

In this scenario with our fictitious hosting provider, neither login names, email addresses, nor alias addresses are permanently assigned to customer mailboxes, as is often the case in practice. In this example setup, the customer's email addresses and aliases can be flexibly moved between the customer's accounts at any time. The following database schema is therefore somewhat more extensive than in a simple setup where email address (+ alias addresses) = mailbox.

Alle ein- und ausgehenden E-Mails werden über ein Mail-Gateway (MTA) geroutet. Auf diesem ist ein benno-milter konfiguriert, der von jeder E-Mail eine Kopie zwischenspeichert.

Die zwischengespeicherten E-Mails werden per SMTP an den auf dem Benno MailArchiv-Server laufenden benno-smtp Daemon übermittelt. Die lokale Kopie der Mail auf dem MTA wird anschließend gelöscht.

Falls ein Kunde das Produkt Benno MailArchiv im Online-Portal des Hosters bucht, wird die Option in der Datenbank des Provisioning-Systems eingetragen und anschließend die Aktualisierung der Benno MailArchiv Konfiguration getriggert. Die Konfigurationsdatei benno.xml wird dabei von benno-writeconfig.sh automatisch aus der Datenbank heraus erstellt (generiert). Anschließend wird die Konfiguration der Dienste neu geladen.

#!/bin/sh
#
# benno-writeconfig.sh
(
  cat xml_header.tpl sqlite provisioning.sqlite \
    'SELECT c.displayname,m.maildomain FROM customer AS c ,maildomain AS m WHERE c.customer_id=m.customer_id;' |\
  while read -d\| domain customer; do
     cat xml_container.tpl |sed -e "s/###CUSTOMER###/$customer/g" -e "s/###DOMAIN###/$domain/";
  done
 
  cat xml_footer.tpl
) > /etc/benno/benno.xml service benno-archive reload service benno-rest reload

The script benno-writeconfig.sh creates the benno.xml file from the template files xml_header.tpl, xml_container.tpl, and xml_footer.tpl. The container template contains the customer's name and the domain(s) to be archived in this container.

The configuration of the services benno-archive and benno-rest reloaded.

Copies of the emails are stored as .eml files by MILTER on the mail gateway (MTA) in the directory /milter/spool/dir .

The cron job milter2smtp reads the .eml files. Using the value of the X-REAL-RCPTTOheader, the mailbox mapping is then determined from the provisioning database.

Im Beispiel-Setup liefert die Abfrage für den Alias info@hansen-und-meyer.de die Mailbox-Id „m3“. Diese Information wird vor dem Übertragen der E-Mail an benno-smtp als zusätzlicher Header in die E-Mail eingetragen. Somit wird die Zuordnung der einzelnen Mail zur Empfänger-Mailbox zum Zeitpunkt der Zustellung in Index und Archiv festgehalten.

Bei der Authentisierung am Web-Interface von Benno MailArchiv wird dem Benutzer, dem die Mailbox m3 zugeordnet ist, die E-Mail Adresse m3@benno-mailarchiv.local als für ihn gültige Adresse übergeben. Damit kann er auf die oben importierte E-Mail zugreifen.

Der für diese Zwecke beim Archivieren in die Mail eingefügte Header X-Benno-MAILBOXID wird von Benno MailArchiv bei Anzeige oder Download der Mail aus dieser entfernt.