> ## 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. # Actions, Rules and Profiles Rules are the basis for all email actions of xorlab Security Platform. They define the characteristics and behavior of the [inbound email security](/9.0/inbound-email-defense) as well as the [Abuse Mailbox Automation](/9.0/abuse-mailbox-automation): * Email quarantining * Subject rewrites * Attachment removals * Quarantine notifications * Feedback and acknowledgments for reported emails * Auto-handling of reported emails A profile is a predefined set of rule parameters that you can reuse to configure xorlab Security Platform for common use cases. There are a few different mechanisms to configure xorlab Security Platform for the above-mentioned aspects, varying in complexity and flexibility. Start with the first one and only move to the next if it does not cover your use case: 1. **Simple and standardized**: Go through the different provided [profiles](#profiles) described below and configure the ones that fit your use case. Profiles are standardized, tested, and should cover most scenarios. 2. **Advanced**: Manually configure certain rule parameters. This can be used to fine-tune or override specific actions of xorlab Security Platform. Just go to the [Actions panel](#actions-panel) in XCC or edit a [config file](#rule-parameters). 3. **Expert**: Write custom rules. Rules provide high flexibility and can be tailored to cover most requirements. The xorlab Security Platform rule language allows combining indicators and actions in virtually every possible way. However, xorlab does not yet provide documentation for this. If you require custom rules, please contact [support@xorlab.com](mailto:support@xorlab.com). ## Profiles The active profiles are configured in the `activeguard/core/active_guard.yml` file: ```yaml theme={null} rules: params: - default.properties - - ... - local.properties - ui.properties ``` The profiles are applied in the specified order. This means that, in the example above, rule parameters from `local.properties` overwrite parameters from the `default.properties`, but the configuration that a user sets in UI (`ui.properties`) has the highest precedence and will be used by xorlab Security Platform. You can specify as many profiles as you want. Always keep `default.properties` as the first entry and do not remove it. It contains the default parameters necessary for xorlab Security Platform to run properly. The `ui.properties` profile should always be the last one and is empty by default. It allows you to override any parameters from the predefined profiles with settings configured in UI in the [Actions panel](#actions-panel) in XCC. The following table lists the available profiles: | Profile | Description | | :-------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `default_actions.properties` | **Default profile for active inbound email security**

It uses subject rewrites for lower confidence decisions and quarantine actions for higher confidence decisions. Subject rewrite text is `[SPAM]`

It does not use attachment removal nor quarantine notifications | | `no_subject_rewrite_no_quarantine.properties` | **“Toothless” mode**

This profile deactivates all quarantine actions and subject rewrites. This profile is usually used for evaluation purposes where XSP should not perform any actions on the email traffic | | `no_auto_feedback.properties` | **Deactivates all automatic feedback and acknowledgment emails for reported emails**

If used, users will not get any automatic reply after reporting an email

**Note:** this profile does not prevent the sending of manual feedback through the GUI | | `default_dana.properties` | **Configures the default SaaS Sandbox settings**

Applies the default dynamic analysis scope, including the additional coverage for recipients in the *Exposed accounts*, *High-value targets*, and *Recipient dynamic analysis* lists | | `monitoring_dana_offline_only.properties` | **Configures the default SaaS Sandbox settings for monitoring mode**

Same scope as `default_dana.properties`, but scans are performed offline | | `no_dana_except_for_specific_recipients.properties` | Disables Sandbox except for recipients in the *Recipient dynamic analysis* list | | `fp_low.properties` | **Configures the detection to be less aggressive to avoid false positives**

This profile should be added per default in all deployments and only removed when a more aggressive detection is required | | `learning_mode.properties` | **Can be used for active inbound email security during the learning phase of xorlab Security Platform**

Basic defense is active (quarantining and subject rewrites), but advanced filters that depend on the learning are disabled to prevent false positives | | `monitoring_mode.properties` | **Used when xorlab Security Platform runs in the [monitoring mode](/9.0/inline-and-monitoring-mode)**

Should not be used in other cases | The older profile `fp_sensitive.properties` is not listed here anymore as it will be deprecated in a future release. It can still be used, but new deployments should instead use `fp_low.properties`. The duration of the learning phase is documented in [Detection Defaults → Learning phase](/9.0/detection-defaults#learning-phase), and the delivered dynamic analysis values in [Dynamic Analysis](/9.0/dynamic-analysis). Password required. ### Common profile configurations You can learn how to use the profiles by studying the following profile configurations and their purposes. #### Standard Standard inbound email security with feedback and acknowledgments: ```yaml theme={null} rules: params: - default.properties - default_dana.properties - default_actions.properties - fp_low.properties - local.properties - ui.properties ``` #### Standard with no feedback Standard inbound email security with deactivated feedback and acknowledgments: ```yaml theme={null} rules: params: - default.properties - default_dana.properties - default_actions.properties # Disable feedback and acknowledgments for reported emails - no_auto_feedback.properties - fp_low.properties - local.properties - ui.properties ``` #### Learning phase with passive defense (evaluation mode) Disable all actions on emails. Can be used as an evaluation mode as well as during learning phase if no actions should be taken: ```yaml theme={null} rules: params: - default.properties - default_dana.properties - default_actions.properties # Disable quarantining and subject rewrites - no_subject_rewrite_no_quarantine.properties # Disable feedback and acknowledgments for reported emails - no_auto_feedback.properties - fp_low.properties - local.properties - ui.properties ``` #### Learning phase with active defense Learning phase with active inbound email security: ```yaml theme={null} rules: params: - default.properties - default_dana.properties - default_actions.properties # Disable certain rules that require completed learning phase - learning_mode.properties - fp_low.properties - local.properties - ui.properties ``` #### Monitoring mode Used only when xorlab Security Platform runs in the [monitoring mode](/9.0/inline-and-monitoring-mode) (“BCC mode”): ```yaml theme={null} rules: params: - default.properties - monitoring_dana_offline_only.properties - monitoring_mode.properties - fp_low.properties - local.properties - ui.properties ``` ## Actions panel Rule parameters can be configured to fine-tune the system in addition to the predefined profiles. You can either use the Actions panel available in the Admin tools of XCC or manually enter the parameters in a [config file](#rule-parameters). In fact, all parameters configured here end up as entries in the `ui.properties` [profile](#profiles) that has the highest precedence. See the Actions panel in action: