4.4. Policy
The policy how emails are handled in Email Gateway Security can be configured by the rules under the Security Rules page.
Direction
In traditional configurations MetaDefender Email Gateway Security is wedged between the organization's email gateway and mail server (see the image below). In case of inbound email directions the email is received from the email gateway and sent towards the mail server. In case of outbound directions the email is received from the mail server and sent towards the email gateway.
The direction of the email flow can be mapped to security rules in Email Gateway Security with defining:
-
Where emails are coming from, and
-
Where emails should be sent next after processing.
To configure direction for a certain security rule:
-
Apply appropriate filter settings for the Security rules > rule / FILTER / Sender IP address filter (PREVIOUS HOP) to define where emails matching this rule are coming from.
-
Select the appropriate SMTP destination in Security rules > rule / GENERAL / SMTP relay server profile to define where emails matching this rule should be sent next after processing. For further details about server profiles see 4.6. Server profiles.
When the filter and the SMTP relay are set appropriately to match emails coming from or going to a certain direction, then the Security rules > rule / GENERAL / Rule direction can be set accordingly to Inbound or Outbound depending on the direction of the email flow.
Priority
Email Gateway Security supports the following three priority queues when processing emails:
-
High,
-
Normal and
-
Low.
The system will always give priority to emails with higher security rule priority.
Example
Processing of Low priority emails will start or continue only if there are no High and/or Normal priority emails waiting for processing.
Default
The default priority for each rule is Normal.
Email History
The priority of the email is displayed in 5.2. Email History. The following icons represent each priority:
-
High: ↑
-
Low: ↓
Normal priority
For Normal priority there is no icon in the Email History.
Rule order
Several security rules can be created that may target different messages from different sources going to different recipients. However, care must be taken how these rules are set up and ordered, as there is a first match and a no match policy (see the next two sections).
Specific rules should come first while generic rules should go at last.
First match policy
If there are more matching rules in the system, then the email message will be accepted/rejected and processed according to the security policy of the first matching rule in the list.
No match policy
If there is no matching rule in the system (or no rule at all), then the email message will be rejected.
Risk of blocking email flow
Deleting all security rules from the system results all email messages being blocked.
Security rule configuration
Fitering
Recipient verification
When SMTP relay recipient verification is enabled for the rule, then Email Gateway Security will attempt to initiate sending an email to the recipient via the SMTP servers of the SMTP server profile configured for the rule (GENERAL / SMTP relay server profile).
The rule is applied to the email only, if the connection initiation succeeds.
For details see 4.4.4. Recipient verification.
Sender IP address conditions
Sender IP addresses are the addresses of infrastructure elements in the deployment, from which MetaDefender Email Gateway Security is allowed to receive emails according to this rule.
Example
In case of a traditional setup, for example, sender is the email gateway for inbound messages and the mail server for outbound messages.
|
Type |
IP address or subnet |
|
|
Match type |
EQUALS |
|
|
Examples |
IP |
10.0.0.1 |
|
IP range |
10.0.0.0/24 |
|
Relation
There is OR relation among entries in sender IP address conditions.
Sender domain or address conditions
Sender filter makes possible to apply security rule based on from what email address the email was sent. The value is taken from the SMTP communication’s MAIL FROM command that holds an email address.
Risk of spoofing
When using this filter please be aware of the fact that spoofing the sender of the email is a very easy task. A more secure way to use this filter would be for OUTBOUND emails only along with filtering to the sender IP.
Field details
|
Value type |
email address |
|
Field type |
|
|
Match type |
regular expression match |
|
Examples |
|
Regular expression specialities
Please note that the "." (dot) in a regular expression matches any character. This means that .+@opswat.com can match test@opswat1com. If you want to match explicitly for a dot you should escape it like this: .+@opswat\.com
Relation
There is OR relation among the sender domain or email address conditions.
Recipient domain or address conditions
Recipient conditions can help to restrict emails matched by the rule to specific recipients. The value is taken from the SMTP communication’s RCPT TO command that holds an email address.
Benefits of recipient filtering
Recipient domain or email address conditions can also help to counter emails sent to invalid recipients; that do not even exist at an organization or among the partners, for example.
This kind of defense may protect against unnecessary overloads or even against malicious attacks.
Field details
The field details are identical to the field details of the sender domain or address conditions (for details see the Sender domain or address conditions section).
SMTP relay
After processing, emails must be forwarded by Email Gateway Security to an SMTP destination so that recipients can receive them.
For each security rule the SMTP destination can be set in Security rules > rule / GENERAL / SMTP relay server profile to define where emails matching this rule should be sent next after processing. For further details about server profiles see 4.6. Server profiles.
Security policy
The security policy of a certain rule is defined by the settings on the SCAN, ADVANCED THREAT PREVENTION, ZERO-DAY MALWARE PREVENTION, ANTI-PHISHING, UPLOAD ATTACHMENTS and ADVANCED tabs.
Scan
On the Scan tab of a certain rule it can be defined if emails matching this rule must be scanned at all, or not.
MetaDefender Core server profile
A MetaDefender Core server profile to which emails are sent for malware scanning and zero-day malware prevention. For further details see 4.6. Server profiles.
Scan email body and headers
Email Gateway Security is capable to process email headers, body and attachments, thus find malicious or sensitive content not only in attachments, but even in the body or headers.
Advanced Threat Prevention
Using multiscanning, Email Gateway Security can utilize even 20 anti-malware engines to prevent advanced, unknown threats.
On this tab it can be configured what Email Gateway Security should do if its Advanced Threat Prevention feature found malware in one or more components of the email.
If Quarantine original email is enabled, then the original copy of the email is put into the 5.3. Quarantine regardless of how Handling of the email is set.
Handling of the email may be:
-
Block email: the email is blocked. If Notify recipients if email is blocked is enabled, then a notification will be sent to the recipients. For further details see 4.8. Alert, notification and quarantine report emails.
-
Delete blocked contents: the blocked contents (e.g. infected attachments) are removed from the email. The remaining is delivered.
-
Deliver blocked contents: the email is delivered containing the potentially malicious (infected) contents.
For Delete blocked contents or Deliver blocked contents options Email Gateway Security provides customization to remove attachments.
Risk of outbreak
Selecting Deliver blocked contents will deliver potentially malicious contents to recipients.
If Email Gateway Security is set to Notify recipients if email is blocked then notifications may be limited to the case of emails with password protected attachments. To do so set Send notifications for to Only emails with password protected attachments.
Zero-Day Malware Prevention
Using content disarm and reconstruction, Email Gateway Security can prevent zero-day malware in over 85 common file types.
The content disarm and reconstruction capabilities can be configured for each MetaDefender Core server. For further details see 4.6. Server profiles.
On this tab it can be configured what Email Gateway Security should do if its Zero-Day Malware Prevention feature applied disarm and reconstruction to one or more components of the email.
If Quarantine original email is enabled, then the original copy of the email is put into the 5.3. Quarantine.
Data loss prevention
When Proactive Data Loss Prevention is licensed (see 1. Licensing), certain behaviour of the technology can be modified on this tab.
Enabling Send sanitized version of blocked files only if redacted can influence the setting under Zero-Day Malware Prevention / Override sanitization behavior / Send sanitized version of blocked files. A sanitized version is sent only, if it could have been successfully redacted, too.
Example
As of today, Proactive DLP can detect sensitive data in PowerPoint presentations (.ppt), but can not redact.
If both Send sanitized version of blocked files and Send sanitized version of blocked files only if redacted then the sanitized version won’t be sent for .ppt files as they can not be redacted.
Enabling Send redacted version of blocked files will deliver redacted email contents - when redaction is available for the file type - if they were blocked due to sensitive data only.
Infected contents
Malware infected contents won’t be delivered even when this option is enabled.
Anti-phishing and anti-spam
Email Gateway Security provides cutting edge anti-spam and anti-phishing protection. Spam and phishing are handled by the same component so the settings are quite similar. For specific settings see the two subsections at the end of this section.
Probability level
The anti-spam and anti-phishing component use the Probability level setting to tell the component what it should treat as Possible spam or Possible phishing (for details see 5.11. Email classifications) and what is known Spam or Phishing (for details see 5.11. Email classifications).
Probability levels
Email Gateway Security can assign the following probability levels to spam and phishing emails:
-
0: not a spam or phishing,
-
1-8: possible spam or phishing (the higher the number, the higher the probability),
-
9: known spam or phishing.
The levels 0 and 10 are not configurable.
Example 1
In the example below Email Gateway Security assigned the spam probability level 9 to the email.
Example 2
In the example below the Probability level is set to 4.
It means, that
-
all email that’s probability level is higher or equal than 4, will be treated as known Phishing, while
-
all email that’s probability level is lower than 4 will be treated as Possible phishing
-
(all email that’s probability level is 0 will be treated as not phishing)
Example 3
If the Probability level is set to 9, then only emails with probability level 9 will be treated as known Spam or Phishing. Emails with levels 1-8 will be treated as Possible spam or Possible phishing.
Actions for known or potential phishing and spam
Based on the probability level, Email Gateway Security can be configured to handle known and potential spam or phishing in different ways.
The following actions are available:
|
Action |
Description |
|
Reject |
Perform an IP reputation check and if turns out to be a (potential) spam or phishing sender, then reject the email on the SMTP level. The email will show up in Audit > Refused Emails. IP reputation only Reject works for spam or phishing emails only when the spam or phishing nature of the email can be pointed out by the IP reputation check. If the spam or phishing nature is given by the content and the action is set to Reject, then the email gets delivered. |
|
Delete |
Receive the email, perform an IP reputation and/or content check, and if turns out to be a (potential) spam or phishing, then delete it. The email will show up in Audit > Email History with some additional details as if it was rejected and with the appropriate classifications added (for details see 5.2. Email History and 5.11. Email classifications). |
|
Quarantine |
Receive the email, perform an IP reputation and/or content check, and if turns out to be a (potential) spam or phishing, then quarantine it (just like infected emails). The email will show up in Quarantine with the appropriate classifications added (for details see 5.3. Quarantine and 5.11. Email classifications). |
|
Deliver |
Receive the email, perform an IP reputation and/or content check, but even if it turns out to be a (potential) spam or phishing, deliver it (just like clean emails). The email will show up in Audit > Email History with the appropriate classifications added (for details see 5.2. Email History and 5.11. Email classifications). |
|
Add headers |
If the known or potential action is set to Deliver, then headers can be added to the email for each case. These headers can indicate for example to the receiving side that a (potential) phishing has just been received. |
Anti-spam specific settings
Email Gateway Security’s ant-spam component can detect some kind of graymail, too. Enabling Classify marketing/bulk email as spam will instruct Email Gateway Security to treat email detected as marketing and bulk as spam and handle it according to the anti-spam settings.
Anti-phishing specific settings
If Enable Dynamic Anti-phishing is turned on, all links in the email body will be redirected through MetaDefender.com Safe URL redirect service for URL reputation check.
MetaDefender Cloud license required
For this functionality to work properly, MetaDefender Cloud’s Reputation API must be licensed.
For demonstration purposes, however, a limited number of Reputation API calls are available for free of charge.
Upload attachments
Prerequisites
Configuring the Upload attachments capability requires some technical understanding of MetaDefender Vault.
For details about MetaDefender Vault see https://onlinehelp.opswat.com/vault/.
For details about integrating Email Gateway Security and Vault see 5.8. Integration with MetaDefender Vault.
The Upload attachments capability requires a MetaDefender Vault server profile to be configured and set for the MetaDefender Vault server profile value. For details see 4.6. Server profiles.
Attachment notice
Setting the Attachment notice a custom notification text can be configured to be appended to emails notifying recipients about where they can access their files in MetaDefender Vault.
The Attachment notice works the same way as other disclaimers do. For details see 4.4.1. Disclaimers.
Required disclaimer variable
You should not remove %[]vault_list[]% from the notification texts as it would lead to missing URLs. For details see 4.4.1. Disclaimers.
Upload blocked attachments
By selecting this option, the original copy of every attachment which was blocked will be uploaded to MetaDefender Vault.
Upload sanitized attachments
By selecting this option, the sanitized copy of every attachment which was sanitized will be uploaded to MetaDefender Vault.
To upload the original copy of the sanitized attachments see 4.4. Policy.
Upload partially sanitized attachments
By selecting this option, the original copy of every attachment which was partially sanitized will be uploaded to MetaDefender Vault.
Requires MetaDefender Core setting
This requires the 'Distinguish partial archive sanitization result' option checked in the MetaDefender Core rule used to scan content with. See MetaDefender Core > 3.6.2. Workflow template configuration for more information.
Upload original of sanitized attachments
By selecting this option, the original copy of every attachment which was sanitized will be uploaded to MetaDefender Vault.
Upload only once
If both Upload original of sanitized attachments and Upload attachments that failed sanitization are enabled –and the sanitization fails– then the original file will be uploaded only once.
Upload attachments that failed sanitization
By selecting this option every attachment where the sanitization failed will be uploaded to MetaDefender Vault.
Upload only once
If both Upload original of sanitized attachments and Upload attachments that failed sanitization are enabled –and the sanitization fails– then the original file will be uploaded only once.
Upload bypassed attachments
By selecting this option every attachment that was bypassed (for details see 5.5. Bypassing) by Email Gateway Security will be uploaded to MetaDefender Vault.
Upload allowed attachments
By selecting this option every attachment which was allowed will be uploaded to MetaDefender Vault.
Allowed but sanitized won't upload
Please note that if an attachment is allowed but gets sanitized then it won't be uploaded if only the Upload allowed attachments option is set.
If you want to upload these kind of attachments you should have Upload original of sanitized attachments enabled.
Options
Remove uploaded attachments from email
By enabling this option every attachment which was successfully uploaded to MetaDefender Vault will be removed from the email. If uploading an attachment fails the removal will be skipped.
Blocked files
Blocked files will be removed regardless this setting if the action for blocked contents is to Delete blocked contents.
Include scan result
By enabling this option, Email Gateway Security will upload the scan results to Vault besides the attachment as metadata. As a result Vault will know the verdict of the scan and can make the file available immediately.
Upload to user's own vault account
Depending whether the email was matched by an inbound or an outbound rule, based on the email addresses, the files will be uploaded to the recipients' (inbound) or senders' (outbound) own Vault accounts (when the account exists on the Vault at all). This feature requires appropriate permissions (impersonation) on Vault.
No account on Vault
If no account exist with the recipient email address on the Vault, then the file will be uploaded to the account that is assigned to the API key specified in the MetaDefender Vault server profile (see 4.6. Server profiles) set for the matching rule.
Example
Advanced
The advanced scan settings policy define certain exceptions from the default behavior.
Retry
Email Gateway Security can be configured to retry to process emails. If an option is set to Retry or Bypass if all retry fail then the retry mechanism under Settings > General / Email is applied.
For details see 4.3. Settings.
Risk of potentially harmful content
If Bypass on first failure or Bypass if all retry fail is configured for certain settings, and the email gets bypassed finally, then the original, potentially harmful email is delivered.
The recipient may be notified about the fact of bypassing. To do so set the Bypass email disclaimer. For details see 4.4.1. Disclaimers.
