Policy

The policy how emails are handled in Email Gateway Security can be configured by the rules under the Security Rules page.

Enable/Disable Security Rules

If you temporarily want to disable one or more Security Rules in MetaDefender Email Gateway Security, select the rule(s) to disable in the list and click the icon. To enable the rule again, select the rule(s) to enable and click the icon.

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:

1. Where emails are coming from, and
2. Where emails should be sent next after processing.

To configure direction for a certain security rule:

1. 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.

2. 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 Configuration/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.

DKIM signing

These options enables signing of emails with DKIM (DomainKeys Identified Mail), both for inbound email (ARC) and outbound (DKIM)

Inbound direction: Authenticated Received Chain (ARC)

In most of the cases Email Gateway Security acts as an intermediate email processing server between the original sender and the intended recipient. As Email Gateway Security is not the original sender the SPF check will fail on the recipients side. Email Gateway Security usually modifies emails (adds custom headers, and with Deep CDR and Proactive DLP it often modifies the email bodies and attachments) and as a result the DKIM verification will fail at the recipient.

Authenticated Received Chain is an email authentication system designed to allow an intermediate mail server to sign an email's original SPF and DKIM authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.

With ARC, an intermediate processing server can digitally sign the SPF/DKIM results of the preceding server and its own modifications to the email with DKIM-like signatures.

1. Certificate: Certificate in Settings > Security > Certificates to be used to create the DKIM/ARC signatures.
2. Signer Domain: The domain for which to create the DKIM-like ARC signature. The next email processing server will look up the public keys in the DNS records of this domain to verify Email Gateway Security's ARC signature.
3. DNS Selector: Specifies the DNS location of the public key. Receiving servers use this selector to find the public key.

Outbound direction: DKIM signing

If your mail server does not attach a DKIM signature to your email, or if you make modifications to the email in MetaDefender Email Gateway Security you can opt to sign it here.

1. Certificate: Certificate in Settings > Security > Certificates to be used to create the DKIM/ARC signatures.
2. Signer Domain: The domain for which to create the DKIM signature. The next email processing server will look up the public keys in the DNS records of this domain to verify Email Gateway Security's DKIM signature.
3. DNS Selector: Specifies the DNS location of the public key. Receiving servers use this selector to find the public key.
4. Optionally, if your previous mail server did add a DKIM signature, then you can remove that, before adding the new one by checking Remove existing DKIM signature before signing.

Priority

Email Gateway Security supports the following three priority queues when processing emails:

1. High,
2. Normal and
3. Low.

The system will always give priority to emails with higher security rule priority.

Email History

The priority of the email is displayed in Operating/Email History. The following icons represent each priority:

1. High: ↑
2. Low: ↓

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.

Security rule configuration

Filtering

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 Configuration/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.

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.

Field details

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.

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).

Email header conditions

Email header conditions help to define email processing based on the email headers rather than SMTP properties (for example as email and SMTP properties are sometimes not in-line, e.g. email From and SMTP MAIL FROM may be different).

Field details

Header name

Header value

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 Configuration/Server profiles.

Rule actions

It is possible to add disclaimers and/or tags to all emails processed by a specific security rule.

Rule disclaimer

To add a disclaimer to all emails processed by this specific rule, enable the option Security rules >rule/ GENERAL / Rule disclaimer and configure the disclaimer content using the disclaimer editor.

Rule tags

To add one or more tags to all emails processed by this specific rule, click on the option Security rules >rule/ GENERAL / Rule tags and complete the configuration in the tag editor.

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 Configuration/Server profiles.

Scan email headers, body and attachments

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.

Scan email body will scan the body (both the HTML and the plain text body) including all the inline, embedded attachments (inline attachments are the non-text elements embedded into the HTML email body, e.g. inline images).

If Enable MetaDefender Cloud Safe URL redirect is turned on, all links in the email body will be redirected through MetaDefender.comSafe URL redirect service for URL reputation check.

Scan attachments can toggle scanning the regular (non-inline) attachments.

Attaching scan results

For certain use-cases it may be beneficial to attach the MetaDefender Core scan results to the email. This is supported by enabling the Attach scan results option.

Hash lookup

To shorten email processing time Email Gateway Security can be configured to perform hash lookups to MetaDefender Core and MetaDefender Cloud (whatever is set as the MetaDefender Core type server profile for the rule).

If the email header, body or attachment is found by the hash, then it won't be sent to MetaDefender Core / Cloud for scanning or processing. This way the scanning and processing time can be saved.

MetaDefender Core / Cloud will return the cached scan results and the cached processed version of the header, body or attachment.

Email headers are always different, but bodies and attachments can be the same among separate emails (for example in case of a newsletter that is sent to hundreds of recipients within an organization). Email Gateway Security comes with reasonable defaults to do hash lookup on attachments (both inline and non-inline attachments).

Enabling Force scan on mismatch the hash lookup will be omitted when the actual file name and the cached file name do not match. In this case the header, body or attachment will be forcibly scanned, even if the result already exists in the cache based on the hash of the file. For further details see Configuration/Email History/Malware scan details.

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 Operating/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 Configuration/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.

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.

Blocked notifications

It is possible to send the recipient a blocked notification when an email is blocked and put in quarantine. The options available for the notifications are:

Subject

Allows customization of the notification subject.

Send notification for original sender

Send the notification to the original email sender (recommended for outbound emails).

Send notification for original recipient(s)

Send the notification to the original email recipients (recommended for inbound emails).

Additional recipients

Allows sending the notification to a set to fixed recipients, such as an administrator etc.

Action permissions

When sending a blocked notification it is possible to permit the recipient to perform actions on the quarantined email.

The following permissions are supported:

1. Rescan emails: Allows the recipient to initiate a rescan of the content. This is useful, for example, when an email contains password protected attachments. The use can specify the password(s) and allow MetaDefender Email Gateway Security to scan the decrypted content
2. Anti-malware rescan: Similar to Rescan emails except that anti-spam and anti-phishing checks are skipped. This way false positive spam or phishing emails can be delivered while anti-malware measures (Multiscanning, Deep CDR, Sandbox, etc.) still apply.
3. Delete emails: Allows the recipient to permanently delete the email from the Quarantine. This could be allowed for, for example, spam emails that the recipient does not wish to receive or keep.
4. Deliver original emails: Allows the recipient to deliver the quarantined (unscanned) email. This permission is not recommended since it could potentially deliver malicious content to the recipient.
5. Release request: Allows the recipient to request the release of an email. An email that has been requested for release will obtain the 'Release request' classification which informs the administrator that a recipient wants his email released.

Notification email headers

Add the custom headers (X-headers) defined here to the notification email.

Encrypted attachments

Email Gateway Security supports functionality to automatically attempt to decrypt attachments by analyzing the email body for possible password(s). To enable this functionality, select the option Decrypt password protected attachments.

In case password(s) cannot be located in the email body, a notification email can be sent (Handling of the email is set to Block email) or disclaimer can be added (Handling of the email is set to Delete blocked contents) to the email, allowing the recipient to provide the password and rescan the email.

Sometimes it is the email body that contains the instructions how the password needs to be formulated. For this use-case Email Gateway Security can display the email body in the rescan page. To use this feature, enable the Display email body on the rescan page option.

Use the Encrypted disclaimer to customize the message added to the email requesting a rescan (not applicable when Block Email is selected as Handling of the email action)

Password storage

From MetaDefender Core version 5.12.0, password storage is supported in Core workflows. When Email Gateway Security is integrated to Core using a workflow where password storage is configured, then Core will attempt to decrypt encrypted attachments using the passwords configured in the Core workflow. This way encrypted attachments may be processed automatically without the need to extract the password from the email body or to request the password from the recipient.

Password storage requires two steps to work with MetaDefender Core workflows:

1. Define one or more password storage(s) under Inventory > Password Storage in Core

2. Link the password storage(s) to the workflow under Workflow Management > Workflows / [Workflow] / Archive / Password storage

For details see the Password storage for handling encrypted file section in MetaDefender Core 5.12.0 Release notes.

Tombstone files

For the use-cases where Email Gateway Security might remove attachments:

1. Handling of the email is set to Delete blocked contents or
2. Remove attachments is enabled

it is supported to replace the removed attachment (both inline and regular attachments) with a tombstone file.

{

    "data_id":"<data id of original file scan result processed by MetaDefender Core>",

    "file_info": {

        "sha256": "<SHA256 hash of original file>"

    },

    "process_info": {

        "blocked_reason": "<blocked reason to indicate why original file was blocked>"

    }

}

Zero-Day Malware Prevention

Using content disarm and reconstruction, Email Gateway Security can prevent zero-day malware in over 100 common file types.

The content disarm and reconstruction capabilities can be configured for each MetaDefender Core server. For further details see Configuration/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 Operating/Quarantine.

Overriding sanitization behavior

Sanitization can fail for two reasons in Email Gateway Security:

1. The Deep CDR engine fails to sanitize the file (the file type version is not supported or the engine has other trouble)
2. The email body is converted by the Deep CDR engine to a file type that is not supported as email body (e.g. the plain text body is converted to pdf).

The default behavior can be customized enabling the Override sanitization behavior option and selecting the cases for which Email Gateway Security should deliver the original copy of the body or attachments in case of a sanitization failure.

Data loss prevention

When Proactive Data Loss Prevention is licensed (see Installation/Licensing), certain behavior 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.

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.

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 Operating/Email classifications) and what is known Spam or Phishing (for details see Operating/Email classifications).

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:

Blocked notifications

It is possible to send the recipient a blocked notification when a spam and/or phishing email is put in quarantine. The options available for the notifications are identical as for Advanced Threat prevention (see above).

Disclaimers

It is supported to amend an email detected as known spam or - phishing or potential spam or - phishing with a disclaimer if the processed version of the email finally gets delivered. Such an email may get finally delivered if the action is set to Deliver; or the action is set to Quarantine and the email gets delivered after a Full rescan or an Anti-malware rescan. The idea behind this behavior is that this way recipients can be alerted about the potential risks in spam and phishing emails even after being delivered by a rescan.

Disclaimers won't be appended to the email when the email is released, forwarded or downloaded from the Quarantine.

For details see the Full rescan email and Anti-malware rescan email sections in Supported functions; and Disclaimers.

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

SPF lookup

It is possible to enable/disable the Sender Policy Framework (SPF) verification as a part of the Anti-Phishing feature. For more information on SPF, see Sender Policy Framework.

DKIM signature validation

DKIM signature validation can be enabled/disabled depending on preference and infrastructure.

URL reputation lookup

With this option enabled Email Gateway Security checks the reputation of the URLs extracted from the email body. If any URL is found malicious then the email gets classified as Phishing and treated according to the settings for known phishing emails.

The MetaDefender Cloud subscription is connected to the URL reputation lookup capability through a MetaDefender Core type server profile.

This server profile has to have its type as MetaDefender Core. At least one of its servers must be MetaDefender Cloud.

At least one of the servers of this server profile must be MetaDefender Cloud.

Authenticated Received Chain (ARC)

In most of the cases Email Gateway Security acts as an intermediate email processing server between the original sender and the intended recipient. As Email Gateway Security is not the original sender the SPF check will fail on the recipients side. Email Gateway Security usually modifies emails (adds custom headers, and with Deep CDR and Proactive DLP it often modifies the email bodies and attachments) and as a result the DKIM verification will fail at the recipient.

Authenticated Received Chain is an email authentication system designed to allow an intermediate mail server to sign an email's original SPF and DKIM authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.

With ARC, an intermediate processing server can digitally sign the SPF/DKIM results of the preceding server and its own modifications to the email with DKIM-like signatures.

To enable ARC, go to Security Rules > rule / General and enable the Sign with DKIM (ARC) option.

1. Certificate: Certificate in Settings > Security > Certificates to be used to create the ARC signatures.
2. Signer Domain: The domain for which to create the DKIM-like ARC signatures. The next email processing server will look up the public keys in the DNS records of this domain to verify Email Gateway Security's ARC signatures.
3. DNS Selector: Specifies the DNS location of the public key. Receiving servers use this selector to find the public key.

Upload attachments

Prerequisites

Configuring the Upload attachments capability requires some technical understanding of MetaDefender Managed File Transfer.

For details about MetaDefender Managed File Transfer see https://onlinehelp.opswat.com/mdmft/.

For details about integrating Email Gateway Security and Managed File Transfer see Integrations/Integration with MetaDefender Managed File Transfer.

The Upload attachments capability requires a MetaDefender Managed File Transfer server profile to be configured and set for the MetaDefender Managed File Transfer server profile value. For details see Configuration/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 Managed File Transfer.

The Attachment notice works the same way as other disclaimers do. For details see Configuration/Disclaimers.

Upload blocked attachments

By selecting this option, the original copy of every attachment which was blocked will be uploaded to MetaDefender Managed File Transfer.

Upload sanitized attachments

By selecting this option, the sanitized copy of every attachment which was sanitized will be uploaded to MetaDefender Managed File Transfer.

To upload the original copy of the sanitized attachments see Configuration/Policy.

Upload partially sanitized attachments

By selecting this option, the original copy of every attachment which was partially sanitized will be uploaded to MetaDefender Managed File Transfer.

Upload original of sanitized attachments

By selecting this option, the original copy of every attachment which was sanitized will be uploaded to MetaDefender Managed File Transfer.

Upload attachments that failed sanitization

By selecting this option every attachment where the sanitization failed will be uploaded to MetaDefender Managed File Transfer.

Upload bypassed attachments

By selecting this option every attachment that was bypassed (for details see Operating/Bypassing) by Email Gateway Security will be uploaded to MetaDefender Managed File Transfer.

Upload allowed attachments

By selecting this option every attachment which was allowed will be uploaded to MetaDefender Managed File Transfer.

Options

Skip supervisor approval

Enable this option to skip supervisor approval of attachments that were uploaded to MetaDefender Managed File Transfer (MFT). Supervisor approval adds an extra layer of security by requiring a supervisor or designated authority to approve file availability file transfers or data sharing activities in MFT before they proceed.

For this functionality to work, Email Gateway Security must be integrated to MFT using a System Level API Key that has set Allow Skip Supervision enabled.

This is how such an API key is defined on the MFT side (for details see For details see https://www.opswat.com/docs/mdmft/end-user-guide/supervisor-approval and https://www.opswat.com/docs/mdmft/configuration/api-keys):

This is how such an API key is used with a MetaDefender Managed File Transfer type server profile (for details see Server profiles):

Remove uploaded attachments from email

By enabling this option every attachment which was successfully uploaded to MetaDefender Managed File Transfer will be removed from the email. If uploading an attachment fails the removal will be skipped.

Include scan result

By enabling this option, Email Gateway Security will upload the scan results to Managed File Transfer besides the attachment as metadata. As a result Managed File Transfer will know the verdict of the scan and can make the file available immediately.

Create subfolders in MetaDefender Managed File Transfer

When this option is enabled, a subdirectory is created for each attachment category (e.g. password protected attachments, sanitized attachments, original copy of sanitized attachments, etc.) in MetaDefender Managed File Transfer.

The attachment categories are the same as the upload options under the Upload attachments tab in the security rule.

Account impersonation options

Disclaimer variables

Advanced

Signed email settings

These settings allow you to override the default behavior when handling signed and/or encrypted emails (S/MIME, PGP). By default, Email Gateway Security will not modify (add disclaimers, sanitize etc.) signed email to ensure that the email signature remains intact. By disabling the option Do not modify S/MIME and PGP signed emails, any signed emails will be modified and potentially render the signature invalid.

Additional recipients

This feature allows you to add additional recipients to every email processed by this security rule. Any recipients added in the list will receive a BCC copy of all emails processed.

SMTP sender or recipient rewriting

With this configuration it is supported to replace the domain part of the email addresses in the MAIL FROM and/or the RCPT TO SMTP commands to the configured value(s) during the SMTP submission to the SMTP relay configured for the rule.

Group disclaimer settings

This options allows grouping of any disclaimers into a section (above or below email body content). This provides a less intrusive way of displaying information in multiple disclaimers for the recipient. An additional footer disclaimer can also be added to each email processed by the security rule.

Override settings

The override settings policy define certain exceptions from the default behavior for SMTP relays & MetaDefender Core scanning.

The decision tree for the retry mechanism under Override SMTP results:

The decision tree for the retry mechanism under Override error handling behavior:

Anti-Spam processing failed

Email Gateway Security has a special option in case when the Anti-Spam processing fails. Setting the option to Ignore the anti-spam result is ignored and the email is processed as if the anti-spam check would have found the email clean.