Mailbox listeners configuration overview

Note: This feature requires Guice wiring. This is not implemented using Spring wiring.
Additionally, wiring not providing a mailbox support, like jpa-smtp, do not have support for mailbox listeners configuration.

Consult listeners.xml to get some examples and hints.

James Guice wiring allow the user to register potentially user defined additional mailbox listeners.

To do so, just register the class that needs to be instantiated and added to global listeners. These JAR can be part of James source code, or provided as an extension and thus should be located in theextensions-jars folder.

MailboxListener configuration

The <executeGroupListeners> controls whether to launch group mailbox listener consumption. Defaults to true. Use with caution: never disable on standalone james servers, and ensure at least some instances do consume group mailbox listeners within a clustered topology.

Mailbox listener configuration is under the XML element <listener>

Some MailboxListener allows you to specify if you want to run them synchronously or asynchronously. To do so, for MailboxListener that supports this, you can use the async attribute (optional, per mailet default) to govern the execution mode. If true the execution will be scheduled in a reactor elastic scheduler. If false, the execution is synchronous.

    Already provided additional listeners includes:
  • org.apache.james.mailbox.spamassassin.SpamAssassinListener: Provides per user real-time HAM/SPAM feedback to a SpamAssassin server depending on user actions. Please note that a spamassassin.properties file is needed.
    This mailet is asynchronous by default, but this behaviour can be overridden by the async configuration property.
  • org.apache.james.mailbox.cassandra.MailboxOperationLoggingListener: For Cassandra guice wiring. Provides more insights on mailbox operations
  • org.apache.james.mailbox.quota.mailing.listeners.QuotaThresholdCrossingListener: For Cassandra guice wiring. Sends emails to users exceeding 80% and 99% of their quota to warn them

PreDeletionHook configuration

Before deleting a message in James, this message and some related information about the deletion will be passed to a set of PreDeletionHook instances, This process is called notifying, and it acts sequentially. If the notifying process for all PreDeletionHooks finish successfully, then the message will be processed to be deleted. Otherwise, that message won't be deleted.

Pre Deletion Hook configuration is under the XML element <preDeletionHook>

    Already provided additional pre deletion hooks includes:
  • org.apache.james.vault.DeletedMessageVaultHook: Storing messages about being deleted into org.apache.james.vault.DeletedMessageVault

NOTE: From James 3.8.1 onward the DeletedMessageVaultHook should no longer be specified for Cassandra based products.

Add custom Guice injections for extensions

Upon injections, the user can reference additional guice modules, that are going to be used only upon extensions instantiation. In order to do that:

1. Place the jar containing the guice module that should be used to instantiate your extensions within the /extensions-jars folder

2. Register your module fully qualified class name within extensions.properties under the guice.extension.module key.