> ## 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.

# Tika

xorlab Security Platform uses the [Tika](https://tika.apache.org/) service to improve the URL extraction of attachments (for example, OCR). In general, Tika is installed on the Sandbox servers and is a part of the same product stack. On-premise customers have the opportunity to decide what type of email traffic the Tika process is applied to in order to prevent traffic from being relayed to the Sandbox servers. By default, the Tika scan is applied to emails coming from an untrusted sender and the following flow:

* **Disabled by default**: outgoing
* **Active by default**: incoming, coming from internal and external servers, and reported by users

As an on-premises customer, you can prevent emails with attachments to be sent to SaaS Sandbox. You can configure additional parameters in [Expert Editor](/9.0/expert-editor) in the `local.properties` file located at `activeguard/core/rule_sets/90_local/params/`:

```text theme={null}
EXECUTE_TEXT_EXTRACTION_for_incoming_emails_state=DISABLED
EXECUTE_TEXT_EXTRACTION_for_internal_emails_state=DISABLED
```

<Note>
  **Tika active in listening modes**

  Tika is still used by default for URL extraction when Sandbox is switched off. Therefore, the above rule to prevent traffic from being sent to Tika is essential if you don’t want to use Tika.
</Note>

## Disabling Tika

Tika should not be disabled in any production environment as it will severly impact classification accuracy. However, if needed, it can be disabled using the [Expert Editor](/9.0/expert-editor). In the `activeguard/core/active_guard.yml` file, add the following lines:

```yml theme={null}
tikaService:
  enabled: false
```

## Processed file formats

Tika extracts text and URLs from a defined set of file formats.

<Info>
  The full list of processed file formats is documented in
  [Detection Defaults → Tika processed file formats](/9.0/detection-defaults#tika-processed-file-formats).
  Password required.
</Info>
