Skip to main content
Three components make up the xorlab Security Platform, and this page describes the data that moves between them:
  • xorlab MTA — the mail transfer agents that receive and forward email, analyze it, and decide the classification of each message. A deployment usually runs several of them.
  • xorlab Control Center (XCC) — the web interface analysts and administrators work in. It also holds the configuration and the shared state, such as the quarantines. There is one XCC per deployment.
  • External services — services that the MTAs and the XCC call over the network during analysis instead of doing the work locally. They are described one by one below.
External means external to the MTAs and the XCC, not outside xorlab. Every service listed below is operated by xorlab, apart from the DNS blocklists. Where a xorlab service in turn contacts a third party — a URL shortener, for example — the section below says so. Which company hosts each service, and in which country, is listed in List of Data Sub-Processors.

Who operates which component

In a SaaS deployment there is normally nothing here for you to change. xorlab operates these services and defines their configuration. The options below for turning a service on or off describe on-premises deployments. What each service receives, and how long it keeps it, is the same either way.
The data flow diagram and the order in which an email passes through the processing stages are documented in Data Flow Details → Email processing pipeline. Access to that page is restricted.

Description of External Services

xorlab Sandbox

The xorlab Sandbox scans selected email attachments for malicious behavior in a secure, isolated environment. Supported file types include:
  • MS Office files: Word (including RTF), Excel (including CSV), PowerPoint, OneNote
  • PDF files
These files are transmitted over HTTPS and are only stored temporarily—typically for a few minutes—during the analysis process. After analysis, they are automatically deleted. You can configure which file types are submitted for analysis. Disabling file submission effectively turns off the Sandbox. You may also disable the xorlab Sandbox entirely, if required.

xorlab Tika

The Tika service is used to improve the URL extraction and text extraction from attachments (for example, through OCR). It processes a defined set of file formats. Attachments are sent to Tika via HTTPS for processing, then the extracted text is sent back. Files are only kept during processing. Tika should not be disabled as it is a critical component for email classification.

xorlab ML

The xorlab ML service uses machine learning based on indicators found in emails to further improve the message classification. The indicators are sent to the ML service over an HTTPS connection. The data does not contain personal or customer-identifying data, nor does it contain the message body data. The data is only kept during processing. xorlab ML is active by default and cannot be disabled.

xorlab NLU

The xorlab NLU service uses natural language understanding to enhance the classification accuracy of the xorlab Security Platform by analyzing the semantics and intent of email content. When enabled, selected content such as the subject line, message body, and extracted attachment text is securely transmitted to the NLU service via HTTPS. This data may include customer-identifying information and is therefore treated as sensitive. The transmitted data is processed in-memory only and is never persisted or stored after analysis. For on-premises deployments this service is disabled by default and needs to be activated manually. You can also limit which traffic it analyzes.

xorlab xCloud

xorlab maintains a centralized service for information around IPs, domains and URLs that is queried by the xorlab Security Platform. These queries are sent via HTTPS and contain domain names or IP addresses found in messages analyzed by xorlab Security Platform. You can’t turn them off. In general, the xorlab xCloud does not store the IPs, domains, and URLs beyond the time of processing. It may do so only in case of an error. For shortened URLs (e.g., bit.ly/foo), xorlab xCloud may forward only the shortened URL to the external shortener service in order to resolve it. The resolved destination address is then evaluated like any other URL. xorlab does not open, download, or render the page behind that address, so no request from xorlab ever reaches the destination site itself. The traffic is via HTTPS. The xorlab xCloud is active by default and cannot be disabled.

External DNS Blocklists

Customers may enable the integration with third-party DNS TI services such as Abusix or Spamhaus. In such a case, xorlab may send domains, IPs, URLs and hashes to the third party TI service via DNS requests. This integration is disabled by default and needs to be manually activated.