> ## 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. # Loggers This page focuses on the configuration of the `` element within the Logback framework. Each logger defines the events to be recorded and determines which appender(s) will handle the recording. **Remember to Configure the Appender** In order to write logs, the `logger` element must be paired with at least one `appender` element. ## Configuration ### Name The `name` attribute in a logger specifies the unique identifier for an event on XSP. It defines the scope and position of the event within the logging hierarchy, allowing precise control over logging behavior. Logger names follow a hierarchical structure, with each part of the name separated by dots, similar to a family tree. It is possible to only specify a prefix of an event as `name`. This will then log all events that start with this prefix. For example, `name="sys"` will log all `sys` events. Note that the only prefixes that are allowed are the ones derived from splitting the event name with a dot. ```xml theme={null} ROOT +- sys ->[customAppender1] - startup - restart - ready - ... - config + - ... ``` In this case, the logger named `sys` is the parent of `sys.startup`, `sys.restart`, `sys.ready`, and so on. All log events with names starting with sys are handled by the sys logger and its appenders, unless a more specific logger (like sys.startup) exists. It is also possible to specify only a prefix in the logger name to capture all events that start with that prefix. For example, setting `name="sys"` will log all `sys` events. Note that the only prefixes that are allowed are the ones derived from splitting the event name with a dot. ### Severity The severity attribute indicates the importance of a log event, with values ranging from 0-3 for low importance, 4-6 for medium, 7-8 for high, and 9-10 for very high importance. This helps prioritize monitoring and alerts, ensuring that the most critical issues are addressed quickly while still maintaining visibility over less urgent events. ### Component After identifying the log event you want to capture, refer to the Components column for the configuration file path. Configuration files are spread across directories because each XSP component operates independently, requiring separate logging setups. | Component | Container | Directory | | :-------- | :-------- | :--------------------------------------------------------------------- | | MTA | Core | **activeguard/core/** | | MTA | Mta | **activeguard/mta/audit/** | | XCC | Backend | **xcc/backend/** | | XCC | Auth | **auth/auth/** | | SANDBOX | Dana | **/etc/xorlab/dana/default/**
*- Modify configurations via ssh* | ## System Events System events, numbered from 0 to 999, cover basic system functions like startup, shutdown, and configuration changes. | ID | Event Name | Severity | Description | Components | | :- | :--------------------------- | :------- | :---------------------------------------------------------------------------- | :-------------------------------- | | 1 | `sys.startup` | 0 | Startup sequence for system component initiated | `Core`, `Backend`, `Auth`, `Dana` | | 2 | `sys.ready` | 0 | System component started up successfully and is ready for operation | `Core`, `Backend`, `Auth`, `Dana` | | 3 | `sys.restart` | 0 | System component is being restarted | n/a | | 4 | `sys.shutdown.triggered` | 4 | System component initiated shutdown process | `Core` | | 5 | `sys.shutdown` | 4 | System component completed shutdown process | `Core`, `Backend`, `Auth`, `Dana` | | 10 | `sys.config.reloaded` | 0 | System component successfully reloaded configuration | `Core`, `Backend`, `Auth` | | 11 | `sys.config.downloaded` | 0 | System component downloaded new configuration | `Core`, `Backend`, `Auth` | | 12 | `sys.config.migrated` | 4 | Migrated system configuration repository to new system version | `Backend` | | 13 | `sys.config.commit` | 4 | Committed a revised system configuration to the repository | `Backend` | | 20 | `sys.backup.started` | 7 | The backup service started creating a backup | `Backend` | | 21 | `sys.backup.resumed` | 7 | The backup service found an incomplete backup and is resuming it | `Backend` | | 28 | `sys.backup.failed` | 10 | The backup service failed to create a backup | `Backend` | | 29 | `sys.backup.completed` | 7 | The backup service successfully created a new backup | `Backend` | | 30 | `sys.recovery.started` | 10 | The recovery service started the recovery process | `Backend` | | 38 | `sys.recovery.failed` | 10 | The recovery service finished recovery with errors | `Backend` | | 39 | `sys.recovery.completed` | 10 | The recovery service completed the recovery process | `Backend` | | 40 | `sys.indexing.started` | 7 | Indexing of XCC data after a release update started | `Backend` | | 41 | `sys.indexing.progress` | 7 | Indexing of XCC data after a release update is progressing | `Backend` | | 42 | `sys.indexing.completed` | 7 | Indexing of XCC data after a release update completed | `Backend` | | 43 | `sys.synchronizing.progress` | 0 | Synchronization of XCC data is progressing | `Backend` | | 99 | `sys.admin.other` | 7 | An unspecific administrative action or task was executed affecting the system | `Core` | ## Message-tracing events Message-tracing events, numbered from 1000 to 1999, track the flow of emails and messages through the system. These are only supported by the MTA and Sandbox components. | ID | Event Name | Severity | Description | Components | | :--- | :-------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------- | | 1000 | `trace.mta.received` | 3 | xorlab Security Platform accepted an email (SMTP status code 2xx if successful) | `Mta` | | 1001 | `trace.mta.send` | 3 | xorlab Security Platform relayed an email (SMTP status code 2xx if successful). Use in combination with `trace.msg_delivered` to correlate queue ID and GGRID | `Mta` | | 1008 | `trace.msg_analysis.receiving` | 0 | Email analysis engine of xorlab Security Platform received an email | `Core` | | 1009 | `trace.msg_analysis.received` | 0 | Email analysis engine of xorlab Security Platform accepted/rejected an email | `Core` | | 1010 | `trace.msg_analysis.start` | 0 | Message analysis started | `Core` | | 1100 | `trace.dynamic_analysis.request` | 0 | xorlab Security Platform requested a dynamic analysis scan for one of the attached files | `Core` | | 1120 | `trace.dynamic_analysis.queued` | 0 | Dynamic file analysis started | `Dana` | | 1129 | `trace.dynamic_analysis.complete` | 0 | Dynamic file analysis completed | `Dana` | | 1130 | `trace.dynamic_analysis.cleanup` | 0 | Dynamic analysis result of a file has been removed | `Dana` | | 1140 | `trace.dynamic_scan.start` | 0 | Dynamic analysis spun up a VM for the in-depth analysis of a file | `Dana` | | 1141 | `trace.dynamic_scan.retry` | 4 | Failed dynamic analysis retries an analysis step on a specific VM | `Dana` | | 1149 | `trace.dynamic_scan.complete` | 0 | Dynamic analysis completed an analysis step on a specific VM | `Dana` | | 1199 | `trace.dynamic_analysis.complete` | 0 | Dynamic file analysis completed | `Dana` | | 1300 | `trace.msg_verdict` | 0 | xorlab Security Platform decided a verdict. This event will be logged twice for emails with attachments for which dynamic analysis was performed out-of-band | `Core` | | 1301 | `trace.msg_analysis.complete` | 0 | Message analysis completed
**Notes:**
1. This event is logged once per email.
2. The decision code is appended to the key. | `Core` | | 1400 | `trace.msg_released` | 6 | Message released from quarantine
**Note**: this event does not support the [email results extensions](/9.0/logging-formats#message-tracing) | `Core` | | 1401 | `trace.msg_report` | 0 | xorlab Security Platform sent a report containing verdict information for a single message | `Core` | | 1402 | `trace.msg_delivered` | 0 | xorlab Security Platform delivered an email. This event contains the SMTP **queue ID** that can be used to correlate with `trace.mta.send` | `Core` | | 1411 | `trace.delivery_status.delivered` | 0 | A message was put into the `delivered` state for a specific recipient | `Backend` | | 1412 | `trace.delivery_status.removed` | 0 | A message was not delivered to a specific recipient and was removed from the queue | `Backend` | | 1900 | `trace.msg_analysis.error` | 3 | xorlab Security Platform encountered an error during message analysis | `Core` | | 1901 | `trace.msg_analysis.resume` | 0 | xorlab Security Platform has resumed message analysis (after being interrupted, e.g., because of an outage) | `Core` | ## Audit trail events Audit events, numbered 2000 to 3999, capture user interactions and administrative actions within the XCC GUI. These events are not supported by the Sandbox or MTA components. | ID | Event Name | Severity | Description | Components | | :--- | :------------------------------------------ | :------- | :------------------------------------------------------------------------------------------------------------- | :--------- | | 2000 | `audit.access.granted` | 4 | A user successfully authenticated to xorlab Security Platform | `Auth` | | 2001 | `audit.access.denied` | 6 | xorlab Security Platform could not authenticate the user/credentials. Access was denied | `Auth` | | 2010 | `audit.user.msg_list` | 4 | A user requested overview information on a batch of emails | `Backend` | | 2011 | `audit.user.msg_details` | 4 | A user requested detailed information on a specific email | `Backend` | | 2012 | `audit.user.msg_download` | 6 | A user downloaded a specific asset related to an email, e.g., the raw email or a screenshot | `Backend` | | 2099 | `audit.user.msg_delete` | 7 | A user deleted a message | `Backend` | | 2100 | `audit.user.quarantine_release` | 6 | A user released a message from quarantine | `Backend` | | 2103 | `audit.user.incident.resolved.verdict` | 7 | A user closed a reported incident with an updated verdict | `Backend` | | 2120 | `audit.quarantine.release.request` | 6 | A user requested to release a message from quarantine (by replying to the quarantine notification email) | `Backend` | | 2130 | `audit.isolate.removed` | 7 | A security analyst triggered the eviction of an email out of a recipient’s inbox | `Backend` | | 2140 | `audit.quarantine.release.request.created` | 6 | A user requested the quarantine-release of an email which has to be reviewed and approved prior to be released | `Backend` | | 2141 | `audit.quarantine.release.request.approved` | 6 | A quarantine release request has been reviewed and approved | `Backend` | | 2142 | `audit.quarantine.release.request.denied` | 6 | A quarantine release request has been reviewed and denied | `Backend` | | 2200 | `audit.user.dynamic_analysis` | 4 | A user requested a dynamic analysis scan for a file | `Backend` | | 2300 | `audit.user.lists.item_added` | 7 | A user added an item to a rule list | `Backend` | | 2301 | `audit.user.lists.item_removed` | 7 | A user removed an item from a rule list | `Backend` | | 2302 | `audit.user.lists.item_replaced` | 7 | A user replaced an item on a rule list | `Backend` | | 2399 | `audit.user.config.file_modified` | 7 | A user updated the system configuration | `Backend` | | 2400 | `audit.user.data_export` | 4 | A user exported data from a saved campaign, query, or metadata (`result.json`) | `Backend` | | 2500 | `audit.user.search.added` | 6 | A user saved a search query | `Backend` | | 2501 | `audit.user.search.removed` | 6 | A user deleted a saved search query | `Backend` | | 2502 | `audit.user.search.updated` | 6 | A user updated a saved search query or its display text | `Backend` | | 2600 | `audit.user.campaign.added` | 6 | A user saved a new campaign | `Backend` | | 2601 | `audit.user.campaign.removed` | 6 | A user deleted a campaign | `Backend` | | 2602 | `audit.user.campaign.updated` | 6 | A user updated a campaign: the underlying search query, the display text, or the associated action | `Backend` | | 2603 | `audit.user.campaign.archived` | 6 | A user archived a campaign | `Backend` | | 2700 | `audit.user.tag.added` | 0 | A user added a tag to one or multiple messages manually | `Backend` | | 2702 | `audit.user.tag.removed` | 0 | A user removed a tag from one or multiple messages manually | `Backend` | | 2800 | `audit.user.backup.triggered` | 7 | A user manually triggered the creation of a backup | `Backend` | ## Threat analysis events Threat analysis events, numbered from 4000 to 4999, record details about threats detected by the xorlab Security Platform, such as malicious emails and their attributes. | ID | Event Name | Severity | Description | Components | | :--- | :---------- | :------- | :---------------------------------------------- | :--------- | | 4000 | `ti.email` | 7 | The email address of a malicious email | `Backend` | | 4001 | `ti.ip` | 7 | The IP of the sending MTA of a malicious email | `Backend` | | 4002 | `ti.file` | 7 | The attachment information of a malicious email | `Backend` | | 4003 | `ti.domain` | 7 | The domain embedded in a malicious email | `Backend` | | 4004 | `ti.url` | 7 | The URL embedded in a malicious email | `Backend` | ## Other events Other events, numbered from 9000 to 9999, include miscellaneous events, such as system deprecations or unspecific actions. | ID | Event Name | Severity | Description | Components | | :--- | :--------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------- | :--------- | | 9001 | `sys.mta` | 0 | Postfix postlog activity. This will contain the complete Postfix logs | MTA mta | | 9990 | `sys.deprecation.warn` | 6 | We require your attention. You are using a feature or a configuration which is deprecated and will be removed in the near future | n/a | | 9999 | `sys.other` | 0 | Unspecific | n/a |