Organizations that require or desire archiving of their communications often use an external solution distinct from the Kolab environment. Such appliances often support SMTP-based forwarding, and for those cases, this article explains how to configure Postfix such that all email is archived.

Environments that use end-to-end encryption as recommended should understand that using a Blind Carbon Copy may as well be called a Blunt Carbon Copy. No decryption nor re-encryption occurs for the email messages, as this article only outlines measures for the Mail Transfer Agent (MTA) level. For environments that require decryption and re-encryption, please solicit the consultancy of Kolab Systems.

A Note About Kolab, Backup & Archiving

Archiving email message tends to refer to a need to preserve communications for some longer period of time, and dedicated appliances or archiving software often indexes the archive, making it available for searching.

Separately, an organization typically backs up the environment in order to, usually in the more short term, be able to retrieve mistakenly deleted data, or in order to recover from a disaster.

In contrast, a Kolab environment would typically be used only for all things current. However, Kolab itself does have a trick up its sleeve, and its default configuration facilitates backup in such fashion that every single email message, groupware object and mail folder can be guaranteed to be included in backup.

Email messages, groupware objects and mail folders that are deleted by a user are not purged from the filesystem immediately. Kolab employs a delay of 69 days by default, facilitating a monthly full on the first Sunday of the month, with the allowance of one such backup run to fail, without incurring any immediate penalty by requiring manual intervention.

In short, archiving itself could be achieved through the retention of full backups for longer periods of time, and if your backup software allows you to do so, perhaps reduce the storage requirements for such backups through merging individual full backups (i.e. reducing duplicates by merging monthly full backups in to quarterly, then yearly full backups, etc.).

A Note About Distributed Environments

A Kolab environment that is distributed, splitting internal mail exchangers from external, and external in inbound and outbound, and such and so forth, need to be careful to configure the few systems that email is always transferred through. Typically, those would be the internal mail exchangers.

Configure Postfix

Configure Postfix to use the always_bcc option as follows:

# postconf -e 'always_bcc=archive@<IP-OR-DOMAIN>'
# systemctl reload postfix

It is generally recommended to use regular, old-fashioned transfer methodologies, such as a sub-domain for your environment, and for the aforementioned @<IP-OR-DOMAIN>, use @archive.example.com or similar.

Avoiding Duplicates in the Archive

For systems where content-filtering is used, override the configuration for re-injection daemons. Note that even distributed environments typically apply content-filters on all but the submission servers.

Edit /etc/postfix/master.cf, and find the definitions of re-injection from Amavis and from Wallace (where used). Append to the configuration for these daemons the following line in bold;

(...snip...)
# Listener to re-inject email from Amavisd into Postfix
127.0.0.1:10025 inet n - n - 100 smtpd
    (...snip...)
    -o receive_override_options=no_address_mappings

(...snip...)
# Listener to re-inject email from Wallace into Postfix
127.0.0.1:10027 inet n - n - 100 smtpd
    (...snip...)
    -o receive_override_options=no_address_mappings

Reload Postfix to apply this new configuration:

# systemctl reload postfix