> ## 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.

# Abuse Mailbox Automation

xorlab Abuse Mailbox Automation automates the triage, analysis, and response to suspicious emails reported by staff to an organization’s abuse mailbox. It streamlines case management and ensures timely feedback to reporters, decreasing threat response times, employee awareness and engagement, and resilience to email threats.

xorlab Security Platform has two built-in mechanisms that will automatically handle reported emails for you:

* Verdict-based automation
* Campaign automation

Based on your preference, these mechanisms will automatically send feedback emails back to the reporter and close the case without any manual interaction.

The **verdict-based automation** generically handles emails depending on the verdict and the confidence. For example, high-confidence spam emails are handled automatically, while low-confidence spam emails create an open case that should be resolved manually. For more information about verdict and confidence, please see *[Verdict and confidence](/9.0/inbound-email-defense#verdict-and-confidence)*.

The **campaign automation** allows you to specify automation based on an arbitrary search query. All future emails that will match your search query will automatically be handled according to your specified configuration. The most common (and powerful) use case is a similarity-based campaign, where all similar emails will be automatically handled in the future.

For more information about the campaign automation, please watch *[Video Tutorials](/9.0/video-tutorials)*. This article will not go into more details about campaigns.

## Verdict-based automation

The verdict-based automation follows the same principles as the verdict-based actions described in *[Inbound Email Security](/9.0/inbound-email-defense)*. Depending on the verdict and its confidence, a case is either automatically resolved with a corresponding feedback email or kept open for manual inspection.

The default verdict-based automations per confidence are shown in the table below. `Auto-handled` means that the case is handled automatically, while `open` means that the case is kept open and needs to be resolved manually.

The defaults are chosen conservatively. In order to change them, please read *[Actions, Rules and Profiles](/9.0/actions-rules-and-profiles)*.

| Verdict                         | (Confidence:) Automation                                     |
| ------------------------------- | ------------------------------------------------------------ |
| Phishing                        | **High**: open<br />**Med**: open<br />**Low**: open         |
| Spam                            | **High**: auto-handled<br />**Med**: open<br />**Low**: open |
| Malware static                  | open                                                         |
| Malware dynamic                 | open                                                         |
| VIP Fraud                       | auto-handled                                                 |
| Impersonation                   | **High**: open<br />**Med**: open                            |
| Extortion                       | auto-handled                                                 |
| Exploit                         | open                                                         |
| BEC (Business Email Compromise) | open                                                         |
| Policy (Filter)                 | **High**: open<br />**Med**: open                            |
| Blacklisted                     | open                                                         |
| Forwarded                       | open                                                         |
| Whitelisted                     | auto-handled                                                 |
| Benign                          | auto-handled                                                 |
| Simulation                      | auto-handled                                                 |

**Forwarded** is a verdict only available for reported emails. It is assigned when a user reports an email that has been forwarded before and thereby lost all its header information. Those cases cannot be classified correctly and need to be resolved manually.

**Benign** is a special case and does not stand for a verdict. It stands for any reported email where xorlab Security Platform is highly sure that the email is benign. The actual verdict can be any of the benign verdicts listed in *[Verdicts](/9.0/search#verdicts)* but the email must fulfill more strict requirements in order to be automatically handled as benign.

<Note>
  **Default feedback**

  By default, automatically resolved cases will always trigger a corresponding feedback to the reporter.
</Note>