Dovecot Lawful Interception (LI) Framework

Note

Dovecot Pro's Lawful Interception Framework is not distributed as part of the base Dovecot Pro packages.

This plugin requires separate licensing to use. Contact Dovecot Pro SLA for further information.

Dovecot Pro provides a flexible, compliant, high performance lawful interception framework.

Users can be monitored by their interaction with the various Dovecot services. Relevant data is captured by hooking into the mail storage API and by parsing protocol data to and from mail access and delivery services (IMAP, POP3 and LMTP).

The overall structure of the framework consists of an intercept proxy and input plugins that hook into various Dovecot services.

The intercept proxy handles the communication with the external interception receiver (a law enforcement entity or, more commonly, some sort of LI service provider). The intercept-proxy service has several driver classes that abstract the various intercept handover protocols that are involved. LI events are thus submitted by such a driver implementation.

Supported Input Plugins

The intercept-proxy accepts protocol data and/or message events from one of several Dovecot service plugins. There are plugins to capture:

• IMAP/POP3 session (pre-login and post-login)
• IMAP session (post-login)
• POP3 session (post-login)
• LDA/LMTP mail delivery
• All saved mails

Supported Output Drivers

Driver	Description
fs	Reports are stored in a directory on the local Dovecot driver filesystem.
pine	Reports are passed to the remote PineApp API.
utimaco	Reports are passed to the remote Utimaco API.

Target Identification

Lawful Interception is usually not blanket surveillance: only specific users are targeted. Therefore, various service plugins only enable interception when the intercept_id field from either Passdb or userdb (depends on context) has a value.

Interception is enabled when the intercept_id field has any value. Additionally, this value is passed to the intercept-proxy as an intercept-ID in the interception session. Some intercept drivers, such as Utimaco, use this as a means to convey a target identifier along with the events. This avoids the need to perform another lookup in the intercept-proxy service.

To assign the intercept field, usually additional lookups are needed in the auth configuration, since the surveillance information is not available from the normal user databases.

Intercept Mail Storage Driver (intercept-box)

This is a mail storage driver intended to be configured to a special user that receives intercepted mails via LMTP or IMAP APPEND. Saving a mail to any of its folders results in the mail being saved to the specified fs/path. The saved mail is written to the intercept file without any modifications - no additional metadata is saved.

This plugin is independent of the rest of the intercept infrastructure, i.e. it doesn't use the intercept-proxy service or support any configurable drivers.

See intercept-box plugin.

Management API (intercept-api)

Some LI service providers, such as Utimaco, require access to a management API that allows management of surveillance targets.

Common Settings

intercept

Default	[None]
Value	Named List Filter
See Also	intercept_driver

Enables the intercept driver. Only one intercept driver can be enabled. The filter name refers to the intercept_driver setting.

Example:

intercept utimaco {
  # ...
}

Since an empty dict_driver defaults to dict_name, there is no need to specify the dict_driver setting explicitly.

intercept_buffer_dir

Default	[None]
Value	string

Path to temporary files creating intercepted data.

Needed only when intercept_buffer_max_size > 0.

intercept_buffer_max_size

Default	0
Value	size

Write intercept buffers larger than this into temporary files in intercept_buffer_dir.

If 0, buffers are always kept in memory.

intercept_crypted_user

Default	[None]
Value	string

Value for the %{crypted_user} variable. The most secure way to generate this is to generate a unique identifier for each intercept request's intercept_id and use that as the salt:

intercept_crypted_user = %{user | encrypt(key='secret',salt=userdb:intercept_id,raw=1)}

For backwards compatibility with old intercept_crypt_* settings, use:

intercept_crypted_user = %{user | encrypt(hash='sha1',rounds=16,key='intercept_crypt_key',salt='intercept_crypt_key',algorithm='intercept_crypt_cipher',raw=1)}

intercept_debug

Default	no
Value	boolean

Normally, the intercept plugins don't log much of anything, even in error situations, because we want to avoid making visible which users are being intercepted.

Set this value to true to output additional debugging information.

intercept_driver

Default	[None]
Value	string

The intercept driver to use. Configure this via the intercept_driver setting instead.

intercept_id

Default	[None]
Value	string

If set, intercept is activated for this user.

Additionally, this value is passed to the intercept-proxy as an intercept-ID in the interception session.

Note

This is intended to be set in a user's session by userdb lookup.

It is documented here for completion's sake.

Note

The login-intercept plugin uses passdb: Extra Fields instead of this value.

intercept_tz

Default	<system time zone>
Value	string

Allows choosing a time zone for the proxy that is different than the default system time zone. This is useful for some backends (Utimaco) that use timestamps without time zone field and expect a specific time zone.

The syntax is identical to the TZ environment variable.