> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes.
> xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal.
> Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can.
> Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames.
> Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing.

# xorlab NLU

> The Natural Language Understanding service that classifies email content using xorlab's in-house machine learning models.

NLU stands for Natural Language Understanding. It classifies email into predefined topics, which you can search for and use in campaigns.

For on-premises, the service is disabled by default.

## Enable xorlab NLU for on-premises

1. Open the file `activeguard/core/active_guard.yml` in the Expert Editor.

2. Add a `mltopic` block to `serviceProviders`, and set the `hosts` to the same one as the existing `ml` service provider:

```yaml active_guard.yml theme={null}
serviceProviders:
  mltopic:
    hosts:
      - https://ml1.de.activeguard.io
      - https://ml2.de.activeguard.io

topicService:
  enabled: true
  serviceProviderName: mltopic
```

2. In the Expert Editor, click **Publish**, then restart all MTAs. The `serviceProviders` and `topicService` settings in `active_guard.yml` require an MTA restart; see [How to Activate the Configuration](/latest/activate-configuration).

## Configuration options

As an on-prem user, you can define which types of email traffic should undergo topic detection.

To modify this behavior, adjust the following parameters in the `local.properties` file located at:
`activeguard/core/rule_sets/90_local/params/` in the Expert Editor.

Set each parameter to ACTIVE or DISABLED as needed:

```shell local.properties theme={null}
EXECUTE_TOPIC_CLASSIFICATION_for_analysis_pipelines_state
EXECUTE_TOPIC_CLASSIFICATION_for_incoming_emails_untrusted_state
EXECUTE_TOPIC_CLASSIFICATION_for_incoming_emails_extended_state
EXECUTE_TOPIC_CLASSIFICATION_for_reported_emails_state
```

After changing these rule properties, click **Publish**. They become active within about one minute and do not require a restart.

<Info>
  The shipped defaults — which traffic is classified after activation, and how to limit topic
  detection to untrusted senders only — are documented in
  [Detection Defaults → Topic classification](/latest/detection-defaults#topic-classification).
  Access to that page is restricted.
</Info>