Whitelists - xorlab

Whitelists are accessible by selecting Settings → Lists → Whitelists in XCC.

SubdomainsWhen you add a root (top-level) domain, e.g., example.com, to the list, all its subdomains will also be whitelisted. When you add a particular subdomain, e.g., site.example.com, only this subdomain will be allowed; any lower-level ones such as other.site.example.com won’t be affected.

Safe senders

Customize any of the lists below to ensure that emails of certain individuals, organizations, or top-level domains are delivered even if your applied risk policy would indicate otherwise.

The Whitelist dialog in the message detail view also offers the Low trusted sender addresses and Low trusted sender domains lists. Those are trust levels rather than whitelists and are documented in Trusted Senders and Infrastructure.

List name	Description	Accepted entries
Registered domains	Any domain names that are controlled by your organization and sound similar to the domains of guarded tenants	Domain name as `String`, e.g., `springfield-nuclear-newsletter.com`
Sender address whitelist (requires auth)	Use this list to whitelist senders if their 5322.From identity can be verified	`mail-from` address as `String`
Sender address whitelist (no auth)	Use this list to whitelist senders for which you don’t require authentication. Use with care. Emails from senders in this list bypass threat analysis. This increases your attack surface to sender impersonation	Email address as `String`
Sender address airlock whitelist (requires auth)	Use this list to whitelist senders whose emails will never be put into the airlock quarantine	Email address as `String`
Sender domain whitelist (requires auth)	Use this list to whitelist organizations if their 5322.From identity can be verified	`mail-from` domain as `String`
Sender domain whitelist (no auth)	Use this list to whitelist entire organizations for which you don’t require sender authentication. Use with care. Emails from senders in this list bypass threat analysis. This increases your attack surface to sender impersonation	Domain name as `String`

Safe SMTP senders

List name	Description	Accepted entries
1. Envelope FROM sender whitelist (requires auth) 2. Envelope FROM sender whitelist (requires auth) (regex)	Use this list to whitelist SMTP senders if their 5321.From identity can be verified.	1. `envelope-from` address as `String` 2. `envelope-from` address as `Regex`, e.g., `bob\d*@whitelisted\.org`
Envelope FROM sender whitelist (no SPF)	Use this list to whitelist SMTP senders for which you don’t require authentication. Use with care. Emails from senders in this list bypass threat analysis	SMTP sender address as `String`
Envelope FROM domain whitelist (requires auth)	Use this list to whitelist organizations if their 5321.From identity can be verified	`envelope-from` domain as `String`
Envelope FROM domain whitelist (no SPF)	Use this list to whitelist entire organizations for which you don’t require SMTP sender authentication. Use with care. Emails from senders in this list bypass threat analysis. This increases your attack surface to sender impersonation	SMTP domain name as `String`

Safe infrastructure

List name	Description	Accepted entries
1. MTA EHLO whitelist (regex) 2. MTA RDNS whitelist (regex)	Use this list to whitelist SMTP sender domains	Domain name as `Regex`, e.g., `mta\.partner\.org`
MTA IP whitelist (regex)	Use this list to whitelist SMTP sender IPs	IP address as `Regex`, e.g., `192\.168\.1\..`

Safe recipients

Customize any of the lists below to ensure that emails to certain email addresses are delivered even if your applied risk policy would indicate otherwise. Note that emails that also go to other recipients in your organization are not affected by these whitelists.

List name	Description	Accepted entries
Recipient address whitelist (regex)	Use this list to whitelist emails to these (guarded) recipients. Emails addressed to these and no other guarded recipients not on this list will always get through	Email addresses as `Regex`, e.g. `dmarc-reports.*@guarded.com$`

Accepted links

Customize any of the lists below to exclude certain links from risk analysis.

List name	Description	Accepted entries
Link domain whitelist	Use this list to whitelist accepted link domains. Accepted links will not increase the risk score	Domain name as `Regex`, e.g., `businesscritical.com`

Accepted files

Customize any of the lists below to exclude certain files from risk analysis.

List name	Description	Accepted entries
File extension whitelist (regex)	Use this list to exclude files with a given extension from risk analysis	File extension as `Regex`, e.g., `\.txt$`
File output whitelist (regex)	Use this list to exclude files with a given type from risk analysis. The file type is based on the output of the `file` command	Pattern as `Regex`, e.g., `ASCII text`
File extension expected (regex)	Use this list to indicate files with a given extension which are considered as expected in communication and shouldn’t increase risk when present	File extension as `Regex`, e.g., `\.txt$`
File output expected (regex)	Use this list to indicate files with a given extension which are considered as expected in communication and shouldn’t increase risk when present. The file type is based on the output of the `file` command	Pattern as `Regex`, e.g., `ASCII text`
Macro file whitelist (hash)	Use this list to not consider as dangerous files with Microsoft Office macros. To whitelist a macro file within an Office document, add its file hash to this list. You can either whitelist the whole file or all the dangerous OLE-nested subfiles inside. In order to understand which nested files should be whitelisted, you can check the drop-down list under Attachments in XCC (if there is no email message with a file as attachment, it could be uploaded directly with the File upload feature). For the nested files that have some macro keywords under their Office analysis tab, whitelist them by adding their `sha256` hashes to the list	`sha256` hash of the file

Accepted file behavior

Customize any of the lists below to exclude files from risk analysis that exhibit a specific behavior in the Sandbox.

List name	Description	Accepted entries
Dynamic DNS request whitelist	Use this list to whitelist domains in the context of the Sandbox	Domain name as `String`, e.g., `backend.com`

Spam blacklist exclusion

If some senders your organization communicates with have landed on a spam blacklist, you can circumvent this here.

List name	Description	Accepted Entries
SPAM sender exclusion from external blacklist	Emails with sender’s domain (`From` and `EnvFrom`) found in this list will not be affected by the external SPAM blacklists. This helps when certain free webmail provider MTAs land on SPAM blacklists and you want to ignore this.	Domain name as `String`, e.g., `bluewin.ch`
SPAM recipient exclusion from external blacklist	Emails with recipient’s address (`To`, `ReceivedFor`, `CC`, `EnvelopeRecipient`) found in this list will not be affected by the external SPAM blacklists. This helps when certain free webmail provider MTAs land on SPAM blacklists and you want to ignore this.	Email address as `String`, e.g., `user@xorlab.ch`

Contextual banners

Configure which senders or recipients should not get a contextual banner on their emails.

List name	Description	Accepted Entries
Contextual banners recipient address exclusion	Use this list to exclude recipient email addresses within your organization from displaying banners.	Email address as `String`, e.g., `user@xorlab.ch`
Contextual banners sender address exclusion	Use this list to exclude sender email addresses from displaying banners.	Email address as `String`, e.g., `user@xorlab.ch`

​Safe senders

​Safe SMTP senders

​Safe infrastructure

​Safe recipients

​Accepted links

​Accepted files

​Accepted file behavior

​Spam blacklist exclusion

​Contextual banners

Safe senders

Safe SMTP senders

Safe infrastructure

Safe recipients

Accepted links

Accepted files

Accepted file behavior

Spam blacklist exclusion

Contextual banners