> ## 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. # Data Storage > A per-component inventory of what is kept and for how long, graded by whether the data can identify a customer or a person. Everything below holds for on-premises and for SaaS. What differs is whose infrastructure the data sits on — your own, or xorlab’s — not what is kept or how long it is kept for. Which of these settings you can change is described in [Data Retention Overview](/latest/data-retention-overview), and the components named here are introduced in [Data Flow Overview](/latest/data-flow-overview). For this documentation, we define the following data classifications: **Sensitivity: Low** Data that does not contain Customer Identifying Data (CID) or Personally Identifiable Information (PII) and cannot typically be linked to a specific email. **Sensitivity: Medium** Data that may include CID or PII, such as email metadata (Subject, Sender, Recipient), but does not include full email content or attachments. **Sensitivity: High** Data such as full email bodies and/or attachments. ## XCC XCC stores both structured and unstructured data. Key data types, such as Email metadata and Log files, are detailed below. All stored data is subject to a retention time. | Data type | Sensitivity | Stored | Format | Retention time | | :--------------------------------------- | :---------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Email metadata | Medium | **Always** | Plaintext, structured | Configurable, default is 90 days | | Email subject | Medium | Configurable, options:
- Do not store
- **Store only for malicious emails (default)**
- Store for all emails | Plaintext, structured | Configurable, default is 90 days | | Email content | High | Always kept for quarantined or reported emails. For all other cases: configurable, options:
- **Do not store (default)**
- Store only for malicious emails
- Store for all emails | Plaintext (EML), unstructured | Configurable. Quarantined emails are kept according to the quarantine configuration. By default, quarantined emails are kept for 30 days and reported emails are kept for two years. | | Email content screenshots | High | Configurable, options:
- Do not store
- **Store only for malicious emails (default)**
- Store for all emails | JPEG, rendered image | Configurable, default is 90 days | | Email attachment screenshots and videos | High | Applies only to attachments analyzed in the Sandbox. Configurable, options:
- Do not store
- **Store for all attachments analyzed in the Sandbox (default)** | JPEG, MP4 | Configurable, default is 90 days | | Email attachments | High | Configurable, options:
- **Do not store (default)**
- Store for all emails | Unstructured file, unencrypted | Configurable, default is 90 days | | Trustmodel (communication relationships) | High | **Always** | Hashed, structured | Not configurable. Entities are removed from the trust model after three months of inactivity | ### Email metadata The email metadata contains the following attributes: | Data attribute | Example | | :----------------------------------------- | :------------------------------------------------------------------------------------------------------ | | All sender and recipient email addresses | `account@xorlab.com` | | Sender and recipient display names | `Mr. xorlab` | | Sending MTA IP address | `1.2.3.4` | | Received at (timestamp) | `2020-01-01T01:01:01+00:00` | | Body URLs | `https://www.xorlab.com` | | Matched email content and subject keywords | Popular phishing or spam keywords like `payment`, `drugs`, `banks`, etc. | | All email headers (except subject) | `Received`, `Date`, `From`, `To`, etc. | | All analysis results | Authentication information, extracted VBS from office attachments, events observed in the Sandbox, etc. | | Attachment names | `newsletter.pdf` | ## MTA An MTA maintains a persistent cache for various information like local domain reputation, trust scores, shortened URLs, etc. The cache contains only aggregated information and does not reference or relate to single emails. | Data type | Sensitivity | Stored | Format | Retention time | | :--------------------------------------------------------------------------------------- | :---------- | :--------- | :----------------------------------------------------------- | :---------------------------------------------------------- | | Cache for:
- Domain and IP information
- Email addresses
- Shortened URLs | Low | **Always** | Plaintext. Aggregated, data does not relate to single emails | Varies between the entities. Between one hour and two weeks | ## Sandbox The xorlab Sandbox only stores files while they are being analyzed. Files are deleted immediately after processing, typically within minutes. In any case, files are automatically removed within a few hours, even if the requesting MTA is unavailable. ## Log files Every xorlab Security Platform component writes local logfiles containing runtime events of different severity. | Data type | Sensitivity | Stored | Format | Retention time | | :-------- | :------------ | :---------------------------------------------- | :-------- | :--------------------------------- | | Log files | Low to Medium | Configurable. Can be disabled (not recommended) | Plaintext | Configurable, default is one month | * The MTA and XCC log files may contain the same data which is described in the [Email metadata](#email-metadata) section, and thus may contain email related data. SaaS instances may send log files to a centralized logging server operated by xorlab in the same region as the SaaS instance, i.e. in Switzerland for CH instances and in Germany for instances outside of Switzerland. * The log levels (DEBUG, INFO, WARN, ERROR) can be used to reduce the amount of email related data written to the log files, but overall there may always be email related data in the log files. * The xorlab Sandbox log files contain less sensitive data. The only email related data that those log files may contain are the names of the files (attachments) that are scanned.