A status is subject to change as new data becomes available. Spam/Phish, Legitimate Email, and Marketing are the status options. If a user disagrees with the status, they can mark as agree/disagree. If the user disagrees, and the status might be a security concern, they should submit a dispute through TAC.
Rejected Statuses:
Email submissions can be rejected if they are submitted incorrectly, are outdated, or if they fit into specific exception categories. Rejected submissions cannot be further processed. However, users can re-submit email samples that were initially submitted incorrectly. The table below breaks down the various types of rejected submissions.
| Rejected Status | Reason | Able to re-submit? |
|---|---|---|
| Reject: not submitted correctly | Message was not submitted as an RFC-822 MIME encoded attachment (for example, was submitted as an inline-forward), one or more original internet headers are missing or malformed, or the original message content or link was modified in any way, including for security reasons. See this link for instructions on native sender callouts for external messages if a workaround is required. | Yes |
| Reject: fake phish | Message is an internal company phishing training exercise and is exempt from being classified. | No |
| Reject: other | Message is out of date or another exempt type of message such as: bounce notifications, auto-replies, challenge responses, or legitimate email messages discussing Spam content. | No |
Fake Phish
The submission processors recognize the major phishing education and testing services and exclude those samples from our Anti-Spam detection, allowing them through to simulate phishing attempts. Users can submit these test messages, in order to practice good detection habits. However, these are not real phish missed by our detection. We list these as “Fake Phish” for full transparency for our customers.
Reject: Other
If our processors can determine the reason for a Rejected status, we provide it in the status. Otherwise, it will be reject: other.
Incorrect submission processes often lead to “Reject: Other” statuses. For instance, if the submitter included the original email message as an in-line forward without the original headers, our processors may not have adequate data to form a classification.
Bulk messages caveat: The intended use of the Email Status Portal is for individual users to submit individual email messages. Bulk messages (e.g. ~1000’s per day) generated by scripts or other automated tooling are not guaranteed to be processed. The most reliable way to submit messages in bulk is to release them from quarantine. Messages released from quarantine will not be shown in the Email Status Portal.
Customers should engage with Cisco TAC to diagnose specific submission issues.
“Limited use” Statuses:
Email submissions with this status cannot be used consistently across all our machine learning systems because it’s missing context or message artifacts, such as post-delivery warning markup that hasn’t been removed. In the future, additional context might be gathered from it.
“No determination” Status:
Email submissions with this status do not yet have enough data to be accurately classified. As with other statuses, this could change as more data becomes available on this submission (for instance, more users report it with the same classification, etc.). Resubmitting the same sample from the same account will not change the status. Duplicate reports are not counted by the Talos processors.
Differing Statuses:
Note that if multiple identical copies of the same email are submitted with different suggested types, the status results may differ across those duplicate messages.
