> ## 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. # Terminology > Glossary of every xorlab product, component, and concept name, with the alternative names each one is also known by. 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](/latest/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](/latest/ssq-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](/latest/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](/latest/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](/latest/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](/latest/m365-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](/latest/verdicts#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](/latest/multi-tenancy-configsets). ## 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](/latest/detection-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](/latest/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](/latest/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](/latest/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](/latest/concepts-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](/latest/before-begin-integration#configure-your-guarded-domains). **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](/latest/multi-tenancy-domain-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](/latest/feature-overview#inbound-email-security). ## 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](/latest/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](/latest/concepts-relationship#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](/latest/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](/latest/concepts-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](/latest/reporting-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](/latest/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](/latest/troubleshooting#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](/latest/data-retention-quarantine). ## 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](/latest/concepts-relationship). **Also known as:** trust model. The relationship value is also called the trust score, and is what the `trust` score matches in [Search](/latest/search#scores). ## 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](/latest/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](/latest/m365-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](/latest/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](/latest/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](/latest/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](/latest/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](/latest/rule-profiles#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](/latest/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](/latest/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](/latest/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](/latest/vips). ## Whitelist A list of senders, domains, or infrastructure that you maintain to exempt matching emails from filtering. See [Whitelists](/latest/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](/latest/data-flow-overview#xorlab-ml). ## 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](/latest/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](/latest/admin-essentials). **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)](/latest/xorlab-sandbox). **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](/latest/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](/latest/data-flow-overview#xorlab-xcloud).