Skip to main content
This page is the canonical source for xorlab vocabulary. Terms are listed alphabetically.

Abuse Mailbox Automation (AMA)

The service of xorlab Security Platform that analyzes, handles, and automates the processing of user-reported emails. Reported emails are grouped into cases, enriched with xorlab’s analysis, and can be resolved automatically. See Handle the Abuse Mailbox. Also known as: Abuse Mailbox.

Attachment Airlock

A feature that holds back emails with encrypted attachments in the Self-Service Quarantine until the user supplies the password. The email is then re-analyzed. Only attachments that cannot be decrypted by other means are affected. Emails held this way receive the encrypted verdict. See Enable Attachment Airlock.

Blacklist

A list of senders, domains, links, or file properties that you maintain to force emails matching them to be treated as malicious. Emails matched by a blacklist receive the Blacklist verdict. See Blacklists. Also known as: blocklist. xorlab Security Platform uses the term Blacklist, so this documentation does too. Not to be confused with: third-party DNS blocklists such as Spamhaus, which are an unrelated external service.

Campaign

An analyst-defined policy that turns a search query into a detection rule, overriding the built-in detection for exactly the emails that match. Campaigns are used to respond to undetected threats, recurring false positives, and greymail. See Using Campaigns.

Case

A user-reported email as it appears in the Abuse Mailbox, together with its analysis, status, and resolution. Analysts resolve a case by assigning a verdict. See Handle the Abuse Mailbox. Not to be confused with: Case Isolation, which is a separate feature.

Case Isolation

A feature that removes already-delivered emails from a user’s mailbox through the Microsoft Graph API. Once enabled, an Isolate button appears in the detail view of every email. See Activate Case Isolation.

Confidence

The certainty level attached to a verdict: high, medium, or low. Confidence takes precedence over specificity when xorlab determines the final verdict of an email, and it controls which action is taken. See Verdict precedence.

Config Set

A reusable configuration template defined in guarded_tenants.yml that can be applied to any number of tenants, so shared settings do not have to be repeated per tenant. See Using Tenant Config Templates.

Contextual Banners

Warnings inserted into the body of an email to highlight a specific risk that xorlab detected, such as low sender trust or a suspicious attachment. They are surfaced through mail flow rules in Exchange. See Enable Contextual Banners.

Email Direction

The relationship of an email to your guarded domains. Every email is assigned exactly one of four directions: Incoming, Outgoing, Internal, or External, see Email Direction. Not to be confused with: the External verdict, which is unrelated to the External direction.

Expert Editor

The administration tool inside XCC that gives full access to all xorlab configuration files. See Expert Editor.

External Service

A service that the xorlab MTAs or the XCC call over the network while analyzing an email, rather than doing the work locally. External means external to those two components, not outside xorlab: the Sandbox, Tika, xorlab ML, NLU, and xorlab xCloud are all operated by xorlab. See Data Flow Overview.

Global Reputation

xorlab’s relevance scoring for email content that is identical across all xorlab customers, rather than learned from a single organization’s traffic. See Local Reputation. Not to be confused with: Local Reputation, which xorlab learns from your own email traffic and which is specific to your organization.

Guarded Domains

List of domains and subdomains which belong to your organization or the tenants you mention. Email filtering will only be applied to recipients in these domains. For example, the guarded domains for xorlab are xorlab.com and xorlab.ch. See Before You Begin. Not to be confused with: Guarded Tenants, which names the tenants themselves rather than their domains.

Guarded Tenants

The tenants configured in guarded_tenants.yml, each with its own domains, routing, and settings. See Configure Domains and Routing.

Inbound Email Security

The service of xorlab Security Platform that protects your organization from malicious incoming emails. It is the core of the platform. See Feature Overview.

Inline Mode

The operating mode in which xorlab sits in the mail flow and actively filters emails, forwarding them after processing. This is the mode used whenever xorlab provides Inbound Email Security. See Inline and Monitoring Mode.

Learning Phase

The initial period during which the relationship model builds up before it can be relied on. Detection is normally disabled during this phase, and enabled manually afterward. See Learning phase.

Lists

The built-in lists in XCC that adjust platform behavior on the fly, covering blacklists, whitelists, VIPs, trusted senders, fraud keywords, and more. See Lists.

Local Reputation

xorlab’s continuously learned model of which email content — domains, file types, and similar — is common in your organization. It is used to distinguish relevant emails from potentially malicious ones. See Local Reputation.

Misclassification

An email that xorlab classified incorrectly: a benign email that was quarantined (false positive) or a malicious email that was delivered (false negative). Misclassifications can be reported to xorlab to improve detection. See Report a Misclassification.

Monitoring Mode

The operating mode in which xorlab sits out-of-band of the mail flow and only observes traffic without intervening. Emails usually arrive as an additional BCC recipient and are dropped after processing. See Inline and Monitoring Mode.

MTA GUI

The technical management interface of an xorlab MTA, reachable on port 8443. This is only available for on-premises deployments. See How to connect to MTA GUI. Not to be confused with: the XCC web interface, which is the main interface for analysts and administrators and is a different application.

Quarantine

A holding area for emails that xorlab did not deliver. Quarantines are named by category — for example Filter, Malware, Phishing, or Spam — and each has its own retention and release permissions. See Change Quarantine Retention.

Relationship

xorlab’s model of the email communication patterns in your organization, built up continuously and automatically. Each email is assigned a relationship value between 0 and 100, derived from how much back-and-forth communication has been seen with the sender. It is a key indicator for the detection engine. See Relationship. Also known as: trust model. The relationship value is also called the trust score, and is what the trust score matches in Search.

Reported Email

An email that an employee submitted to the security team as suspicious, using the reporting button or the abuse mailbox address. Reported emails appear in the Abuse Mailbox as cases. See Handle the Abuse Mailbox.

Retrospective Email Scanning

A one-time onboarding feature that imports past emails from M365 and pushes them through xorlab for analysis, so trust and reputation build up without waiting for live traffic. See Retrospective Email Scanning.

Rule Profile

A named set of rule parameters that switches xorlab between operating modes — Inline or Monitoring, Toothless or active protection — without editing individual rules. Profiles are assigned per tenant in guarded_tenants.yml. See Rule Profiles.

Self-Service Quarantine (SSQ)

The service of xorlab Security Platform that lets end-users view, release, and manage their own quarantined emails without involving the security team. It is abbreviated as SSQ, which is the form used throughout this documentation after the first mention on a page. See SSQ Overview.

Tags

Hashtags that xorlab attaches to every processed email, describing what it extracted from the content, metadata, and communication history — for example #untrusted or #newsender. Tags are the main building block for searches and campaigns. See Tags.

Tenant

An organizational unit within one xorlab Security Platform instance, with its own guarded domains, routing, quarantines, and settings. A deployment serving several tenants is a multi-tenant deployment. See Multi-Tenancy Overview.

Toothless Mode

An operating mode in which xorlab delivers all emails and only records the actions it would have taken. It is used for evaluation and during the learning phase. See Toothless.

Topic Detection

The classification of what an email is about — for example an invoice or an account issue — based on its subject, body, and attachments. It is powered by xorlab NLU and the results are searchable. See Topic Detection.

Trusted MTA

An internal mail server whose Received headers xorlab treats as authentic. Declaring trusted MTAs is required for correct SPF evaluation when xorlab is not the border gateway. See Trusted MTAs.

Verdict

The single final classification xorlab assigns to every email, ranging from benign to malicious. Together with its confidence, the verdict determines the action taken on the email. Verdicts are also used by analysts to resolve reported emails. See List of Verdicts.

VIP

A member of senior management, the board, or another well-known person registered in xorlab so that impersonation attempts against them are detected more aggressively. See VIP Names.

Whitelist

A list of senders, domains, or infrastructure that you maintain to exempt matching emails from filtering. See Whitelists. Also known as: allowlist. xorlab Security Platform uses the term Whitelist, so this documentation does too.

xorlab Control Center (XCC)

The component of xorlab Security Platform that provides the web interface for analysts and administrators. It maintains the configuration as well as the shared state for the xorlab MTAs (for example, the quarantines). It is referred to as XCC everywhere else in this documentation. There is only one instance per xorlab Security Platform. Not to be confused with: the MTA GUI, which is a separate interface on the MTAs.

xorlab ML

The external machine learning service that xorlab queries to improve message classification. It receives only non-identifying indicators, never message bodies, and is active by default. See Data Flow Overview.

xorlab MTA

The component of xorlab Security Platform that is responsible for processing and forwarding emails. It is lightweight and stateless. Usually, multiple xorlab MTAs are set up to guarantee zero-downtime and fail-safe operations.

xorlab Natural Language Understanding (NLU)

Denotes a set of services in xorlab Security Platform that are responsible for understanding of email content, such as what topics are discussed in an email. See xorlab NLU.

xorlab SaaS

The deployment option in which xorlab hosts and operates xorlab Security Platform, as opposed to an on-premises deployment on the customer’s own virtual infrastructure. It determines who is responsible for upgrades, restarts, and data retention settings. See What Integrating xorlab Involves. Also known as: xorlab Security Platform (SaaS). Not to be confused with: xorlab xCloud, which is an external service both deployment options use.

xorlab Sandbox (DANA)

The component of xorlab Security Platform that is responsible for the sandbox analysis of email attachments. In on-premises deployments it is also referred to as DANA, which is the name used for the appliance, its containers, and its configuration files. See xorlab Sandbox (DANA). Also known as: Dynamic Analysis, DANA.

xorlab Security Platform

The complete email defense platform by xorlab. It is the name of the product. It is also abbreviated by just “xorlab”.

xorlab Tika

The external service that extracts text and URLs from attachments, including OCR, to improve classification. It should not be disabled, as it is critical for email classification. See xorlab Tika.

xorlab xCloud

The external service that xorlab queries for global information about domains, URLs, and IP addresses. It is active by default and cannot be disabled. See Data Flow Overview.