Data Sent to External Services

External means external to the MTAs and the XCC, not outside xorlab. Most of the destinations below are services xorlab operates itself; the ones that are genuinely third parties are VirusTotal and the DNS-based threat intelligence services, and both are switched off until you enable them. Data Flow Overview introduces the components and the services. Both tables apply to on-premises and SaaS deployments. Two rows are marked On-premises only — they describe transfers that leave your own infrastructure, which in a SaaS deployment is xorlab’s. The Mandatory column means the same in both: whether the transfer is part of normal operation or something you turn on and off. In SaaS, xorlab operates the platform and sets that configuration.

Sent by the MTAs

Data attribute	Encrypted	External Service	Mandatory	Comment
Domains, IPs, URLs	Yes	xorlab xCloud	Yes	Query global information for domains, IPs, and URLs that are found in an email
Detection indicators	Yes	xorlab ML	Yes	Analyze an email by sending data to the machine learning service. The data is not client-identifying, meaning no sensitive information is transmitted. What is sent is already visible under the CONTEXT VARIABLES tab in the message detail view and limited to the variables that start with `dce.`. The data includes SHA-256 hashes of attachments and files, and otherwise only inferred metadata of the email
Attachments	Yes	xorlab Sandbox	No	Certain suspicious attachments are temporarily uploaded to a secure cloud environment for sandbox analysis. After the scan is completed, relevant data is automatically removed from the cloud, and the analysis results are stored locally. If a customer runs its own xorlab Sandbox locally, then the local service will be used instead.
Attachments	Yes	xorlab Tika	Yes	Used to extract text and URLs from attachments. Files are sent to Tika over HTTPS and processed in-memory; they are not retained after processing. Disabling this feature may reduce classification performance. If a customer runs its own xorlab Sandbox locally, then the local Tika service will be used instead (Tika runs on the same system as the xorlab Sandbox).
Email (full content)	Yes	xorlab NLU	No	Sensitive email content is sent to xorlab NLU for text analysis. This feature is optional and disabled by default for on-premises installations. An on-premises version is planned for a future release.
Domains, IPs (A, MX, PTR, TXT)	No	Local DNS server	Yes	On-premises only. Used to verify SPF/DKIM, resolve domains, and, if manually enabled, query third-party DNS-based TI services. DNS queries are made directly from the MTA and may appear in your internal DNS logs. In a SaaS deployment the MTAs are operated by xorlab, so these queries never touch your infrastructure.

Sent by the XCC

Data attribute	Encrypted	External Service	Mandatory	Comment
Attachment hashes and URLs	Yes	External TI (VirusTotal)	No	On-demand VirusTotal query to get more threat intelligence for attachments and URLs
Telemetry	Yes	Telemetry	Yes	On-premises only. Information on the hardware the XCC VM is running on (CPU, memory, …), information on the XCC VM (versions, packages, …), information on the product usage, guarded domains. In a SaaS deployment xorlab operates the XCC, so this data never leaves xorlab.

Misclassification reports

The data in these reports depends on the reporter’s chosen options: it’s possible to share metadata, previews, and original email; share metadata only, or share anonymized metadata. The metadata means the following information:

Information	Description
`ggrid`	Unique ID
`direction`	Incoming, outgoing, internal
`contextFields`	Context variables
`coreCreated`	Analysis start time
`coreCompleted`	Analysis end time
`xccReceived`	Time when XCC received the message
`coreVerdict`	Message verdict
`coreVersion`	–
`pipeline`	Email, AnalysisFile, AnalysisEmail, or Report
`tags`	Tags added by xorlab
`userTags`	Tags added by the admin/analyst
`appliedRules`	Rules applied to this message
`passiveRules`	Passive rules
`ruleSetEssentialInfo`	Finger printing
`decisionHistory`	Series of decisions made by Core
`spamScore`	–
`rspamdScore`	Rspamd: external
`reporterClassification`	Reporter’s expected classification if the message is reported
`reporterVerdict`	Reporter’s expected verdict if the message is reported
`tenantId`	Unique customer ID
`principal`	Reporter’s username and permissions
`submissionDate`	–
`perceivedSeverity`	Misclassification severity as perceived by the reporter: low, moderate, major, critical
`expectedClassification`	Classification as expected by the reporter: benign, malicious, or other
`reporterMessage`	Message from the misclassification reporter
`event`	Where the misclassification is reported from: isolation, report, direct submission

Most of this data is contained in the Context fields (you can see it by clicking the Context tab in the message detail view). Reports are sent to xorlab Cloud via HTTPS, then they are processed by us and stored indefinitely on our infrastructure.

​Sent by the MTAs

​Sent by the XCC

​Misclassification reports

Sent by the MTAs

Sent by the XCC

Misclassification reports