Order of Operations
Security Systems
When Mimecast processes an inbound email, checks and scans are performed to ensure only legitimate emails are accepted. Part of this processing includes Mimecast’s proprietary ARMed SMTP (Advanced Reputation Management). This helps make inbound email scanning more efficient and effective by looking at the reputation of the sending IP and email address.
Mimecast uses a combination of Policies, reputation checks, anti spam and virus systems to detect, and if necessary, reject unwanted emails. The SMTP protocol is implemented in a manner that allows the:
- Analysis of anomalies
- Comparison to shared and individual reputations
- Detection of malware
Policies always apply to the From and To addresses matched to the email. If a Distribution List email address is used to receive emails, user Managed Sender Policies may not take effect as they apply to a member address of the Distribution List.
Understanding ARMed SMTP
Understanding the order of the checks applied is significant. It will assist you when troubleshooting delayed or failed inbound and outbound emails. Mimecast also recommends that you review the Security Best Practice.
Mimecast ARMed SMTP occurs during the communication between the sending email server, and the receiving MTA (Mail Transfer Agent) in the Mimecast architecture. This ensures emails are analyzed in protocol, or on-the-wire, before they are accepted or rejected. This prevents the unnecessary transfer of unwanted emails to the customer infrastructure.
ARMed SMTP Blocks 98.5% of all dark SMTP traffic. This is unwanted inbound SMTP traffic including spam, DoS attacks, directory harvest attacks and malformed SMTP packets.
How does ARMed SMTP work?
ARMed SMTP consists of a combination of Policies, as well as reputation checks, that work on a protocol level for delivery pattern recognition. It is designed to be coupled with Mimecast’s MTA which helps emails to be processed more efficiently. If a match is found, emails will be rejected in protocol.
The following diagram shows a representation of the steps in processing an inbound email, with a brief explanation of each point below. A definitive representation is hard to show, due to the speed with which some processes occur, and that some actually occur almost simultaneously.
Description
If Triggered
| Anti-Spoofing Policy | This policy blocks spoof attempts. If a spammer falsifies their sending address to masquerade as an internal domain address, Mimecast rejects the email. | Rejects Email |
| Blocked Senders Policy | These policies reject the connection, and as with all other rejections, the connection is dropped in protocol. This means that the email data cannot be released or retrieved, as it is not present in Mimecast. | Rejects Email |
| Permitted Senders Policy |
Permitted Sender policies bypass all spam reputation and content based checks, but not anti-virus checks. If an email address or domain is in both a Permit and Block policy, the email would be rejected. This is because the Blocked Senders policy is applied first. For example, an end user may have permitted an email address, but the Administrator has blocked that entire domain at a global level. In this case, the email is rejected because the Block Policy for the domain is applied first. |
Bypasses Spam Checks |
| Auto Allow Policy and Managed Senders |
When an internal user sends an email, Mimecast adds the recipient’s email address to a database called Auto Allow. When the recipient sends an email to the internal user, Mimecast checks their email address against this database. If a match is found, the email is allowed through without applying additional spam reputation and content checks. This is similar to a Permitted Sender policy where virus checks are still applied. User Managed Sender entries can be used to manually bypass spam checks with a Permit entry, or to create a Block entry which takes preference over Permit and Auto Allow. An Auto Allow Policy is applied where the message is between the sender and recipient only, or the sender and multiple internal recipients, unless it has been overridden by an additional policy. |
Bypasses Spam Checks |
Reputation Checks
Descritpion
If Triggered
|
IP Reputation Checks (Bypassed by Auto Allow and Permitted Senders Policies) |
a. Block lists are applied next. These contain the IP addresses of known malware senders. Mimecast uses its own block list, along with other commercial DNS block lists. b. The other IP reputation check functions as a global network outbreak detection system. This allows Mimecast to be the first responder to many malware threats, both known and unknown. This reputation service temporarily defers connections if they are suspected to have a bad reputation. Updated checks will periodically be performed after which the connection is either accepted, deferred or rejected. Reputation checks can be customized through the use of a Reputation Policy. |
Rejects Email |
|
Greylisting (Bypassed by Auto Allow and Permitted Senders Policies) |
Compliance checks are applied to the sender’s mail server (based on sender's email address, IP address and recipient's email address) for all connections not previously seen before by Mimecast. Mimecast gives a busy signal, which prompts the sending server to retry the email delivery after 1 minute. If the sender’s mail server retries the connection, the email is processed. If the email is not retried within 12 hours, the email connection is dropped and rejected. | Temporarily Defers the Connection (Sender must retry) |
| Recipient Validation | Recipient validation is used to prevent inbound emails with invalid recipient addresses. To be effective, spammers send out numerous emails, most of which are guessed or a result of directory harvesting. Mimecast uses different types of recipient validation, and this is configured against each domain in Mimecast. | Rejects Email |
| DNS Authentication | DNS Authentication combines three industry-standard email authentication technologies that allow domain owners to control who sends on behalf of their domains. It also validates the authenticity of inbound messages. | Rejects Email or Ignores Auto Allow or Permitted Sender entries. |
Content Scanning
Description
If Triggered
|
Spam/Virus Scanning (Spam Scanning is bypassed by Auto Allow and Permitted Senders Policies. Virus scanning is NOT bypassed.) |
a. Spam scanning: Mimecast uses multiple content based heuristic scanning engines. These examine the content of emails, and look for key phrases and other identifiers commonly used by spammers. These include content matching rules, and DNS-based checksum-based and statistical filtering definitions. Depending on the policy configured, if a match is found, the email is held for review. b. Virus scanning: Mimecast uses its own proprietary software (ZHARA - Zero Hour Adaptive Risk Assessor) as well as market leading Commercial software. This provides malware protection software with combined intelligence gathered from the millions of commercial and freeware users. Mimecast’s engines combine signature and heuristic malware detection technologies. These detection systems work on the wire, which allows Mimecast to shut off viral and intrusive transmissions early. Any email matching a malware signature is rejected. |
Spam Scanning: Rejects Email if Spam Content is high, or Holds email for Review Virus Scanning: Rejects Email |
| Content Examination | If Content Policies have been configured, emails are scanned for any text matches. Content policies can be configured to scan the content of an email for a word, phrase or combination thereof. Matches can then be held for review, encrypted or sent using Mimecast’s secure mail (CCM – Closed Circuit Messaging) amongst other features. | Several actions could be selected |
| Attachment Management |
Attachment Policies are configured to look for certain attachment types and sizes. If found, the following actions can take place: - Hold for Review: Email delivery is interrupted, and a Notification or a Digest is sent to the recipient. The email and attachment/s are placed on hold. - Deny: Removes the attachment from the email, but delivers the email to the recipient. A notification is appended to the email content to inform the recipient that the attachment has been denied. The user is able to contact the Administrator to have the attachment released if necessary. - Strip and Link: The attachment is removed from the email, and is replaced with a notification including an HTTP download link, appended to the body of the message. The user has the ability to download the attachment to their local workstation using the HTTP link. |
Emails could be Held for review, or Attachments could be removed while the email body is delivered (with or without a notification) |
Ultimately, emails that pass all these checks will be accepted and moved to the Delivery Queue for final delivery to the recipients mail server. If an email does not reach the intended destination, use the Tracking tools provided by Mimecast to determine the email delivery issue.
Carlos Rios
Comments