Dovecot Mailpush

Setup of the Dovecot Push

Prerequisites

Dovecot customers can use the special PUSH plugin without any additional costs. The plugin will be provided via the Dovecot software repository for Dovecot Pro and community edition. Please Note, the installation of the latest Dovecot v2.2.19 release is required

IMAP METADATA

Dovecot Push plug-in requires METADATA support on Dovecot side, but it should only be enabled for OX IMAP sessions and not for any other IMAP clients directly. Enabling can be done with e.g. the remote directive "remote 1.2.3.0/24 { imap_metadata = yes }" and specifying the IP ranges of OX.

Dovecot supports the [METADATA extension (RFC 5464)], which allows per-mailbox, per-user data to be stored and accessed via IMAP commands.

To activate metadata storage, a dictionary needs to be configured in the Dovecot configuration using the mail_attribute_dict option.

To activate the IMAP METADATA commands, the imap_metadata and mail_attribute_dict options need to be activated.

Example:

# Store METADATA information within user's Maildir directory
mail_attribute_dict = file:%h/Maildir/dovecot-attributes

protocol imap {
  remote 1.2.3.0/24  {
    imap_metadata = yes
  }
}

The following picture should demonstrate how the overall communication flow between Mail App, Open-Xchange Middleware, and the Dovecot Push plug-in takes place. That communication flow requires the "open-xchange-push-dovecot" and "open-xchange-rest" packages to be installed on the Open-Xchange Middleware nodes and the Dovecot "http-notify" plug-in.

Once the Open-Xchange Mail App is installed on the user’s mobile device and it is allowed to show notifications about a new message delivery, the Mail App performs a subscription call to the Open-Xchange Middleware Servers using a fully authenticated session.

When the "open-xchange-push-dovecot" package is installed, the previous subscribe call requests it to spawn a permanent listener. Such a listener simply tells the Dovecot server to notify about new message delivery events for the associated user by executing a special SETMETADATA command. Hence, it does not open or use any resources other than firing a single IMAP command to the Dovecot IMAP Server.

Whenever a "new message delivery" event occurs, the Dovecot Server performs a HTTP callback against a configurable HTTP end-point of the Open-Xchange Middleware providing crucial information about the newly delivered message with a simple JSON body. That incoming HTTP callback is then turned into an appropriate OSGi event with topic "com/openexchange/push".

That event is in turn handled by the Mobile Push event handler, which uses the event’s information to request an APN/GCM push to the mobile device.

Configuration of Dovecot "http-notify" plug-in

To use push notifications, both the "notify" and the "push_notification" plugins need to be activated. For LMTP delivery, this is required:

protocol lmtp {
  mail_plugins = $mail_plugins notify push_notification
}

If you also want push notifications to work for LDA-based delivery, you would need additional configuration:

protocol lda {
  mail_plugins = $mail_plugins notify push_notification
}

The HTTP end-point (URL + authentication information) to use is configured in the Dovecot configuration file. The appropriate configuration options will contain the HTTP URL denoting the end-point to connect to as well as the authentication information for Basic Authentication as configured by properties "com.openexchange.rest.services.basic-auth.login" and "com.openexchange.rest.services.basic-auth.password". The URL to configure in Dovecot configuration follows this pattern.

<http|https> + "://" + <login> + ":" + <password> + "@" + <host> + ":" + <port> + "/preliminary/http-notify/v1/notify"

Please note that SSL endpoints are only supported from Dovecot >= 2.3.

E.g.

plugin {
 push_notification_driver = ox:url=http://login:pass@node1.domain.tld:8009/preliminary/http-notify/v1/notify
}

Furthermore, it is also possible to specify more than one HTTP end-point to connect to if a new message delivery occurs. Thus the configuration section mentioned above may be extended by additional "push_notification_driver" entries; e.g. push_notification_driver2, push_notification_driver3, etc.

Please note that the path "/preliminary/http-notify/v1/notify" denotes the internal REST API of the Open-Xchange Middleware, which must not be publicly accessible. The administrator can decide whether to add that path to the Apache configuration (see also AppSuite:Apache_Configuration and AppSuite:Grizzly) through a Location/ProxyPass directive:

<Location /preliminary>
    Order Deny,Allow
    Deny from all
    # Only allow access from servers within the network. Do not expose this
    # location outside of your network. In case you use a load balancing service in front
    # of your Apache infrastructure you should make sure that access to /preliminary will
    # be blocked from the internet / outside clients. Examples:
    # Allow from 192.168.0.1
    # Allow from 192.168.1.1 192.168.1.2
    # Allow from 192.168.0.
    ProxyPass /preliminary balancer://oxcluster/preliminary
</Location>

In a scenario where Dovecot Push is also supposed to be used for websockets based browser notifications the OX property com.openexchange.push.allowedClients needs to be extended with "open-xchange-appsuite".

In case the "user=" sent by OX in the push_notification_driver url data does not match the IMAP login of a user, Dovecot ignores it. This can be overridden by defining "user_from_metadata" in the push_notification_driver url, e.g.

 push_notification_driver = ox:url=http://example.com/ user_from_metadata