Server profiles

Overview

Email Gateway Security is surrounded by different services that together can provide the email processing capabilities.

Such services are:

• SMTP services to where Email Gateway Security can forward emails when processing is completed;
• Active Directory servers that can be used for licensing and policy rule enforcement;
• MetaDefender Core servers or MetaDefender Cloud service that can be used for additional security processing capabilities, for details see https://onlinehelp.opswat.com/corev4 or https://onlinehelp.opswat.com/mdcloud respectively;
• MetaDefender Vault instances to where Email Gateway Security can upload attachments, for details see Integrations/Integration with MetaDefender Vault.

Email Gateway Security uses the concept of server profiles to integrate to these services.

Default MetaDefender Core

Email Gateway Security contains a MetaDefender Core component. MetaDefender Core is responsible for the Proactive Phishing Prevention, Zero-Day Malware Prevention, Data Loss Prevention and Advanced Threat Prevention capabilities of the system.

The Default MetaDefender Core is special in that it provides configuration for the Advanced Threat Prevention (DEEP CDR) and Zero-Day Malware Prevention (PROACTIVE DLP) capabilities from within Email Gateway Security.

MetaDefender Cloud

Since version 5.4.0 Email Gateway Security supports scanning on MetaDefender Cloud instead of –or in addition to– on-premises MetaDefender Core servers.

To configure MetaDefender Cloud for scanning, follow these steps:

1. Create or modify a MetaDefender Core type server profile
2. Create a new server specification (click ADD NEW SERVER) or modify an existing one

3. Select the option MetaDefender Cloud and specify the MetaDefender Cloud API Key

4. From this point MetaDefender Cloud is treated as yet another server in the server preference, so either the processing fails over to it, or it is used as an additional server in the round-robin setup.

Sensitive data

Certain server profiles require sensitive information to be configured for the server profile to work correctly.

Server specifications

Servers must be specified using URI syntax. Multiple server specification may be added to an SMTP or MetaDefender Core type server profile. At least one server specification must exist in a server profile.

Only the following URI components are used:

Server profile examples

The following list contains examples for each server profile type with reasonable defaults (all use 127.0.0.1 as host).

Transport layer security schemes

To configure TLS between Email Gateway Security and the server providing the service of the server profile, the following schemes must be used:

Server preference

Actual server in MetaDefender Core and SMTP type server profiles can be set to a preference order in which servers are addressed for services.

Failover

High availability order; first successfully addressed server in the list will do the service.

Always start with the first server URL in list defined in the server profile.

Fail over to the next server in the list, if the actual server fails.

Round robin

Load balancing order; next successfully addressed server in the list will do the service.

Do a Round Robin selection of the Core URLs defined in the Core inventory:

1. For the first scan request use Core 1
2. If previous scan request used Core 1 then use Core 2 now,
3. ...,
4. If previous scan request used Core k then use Core k+1 now,
5. ...,
6. If previous scan request used Core n then use Core 1 now

SMTP server connection pooling

To improve performance, Email Gateway Security can cache and reuse connections towards SMTP relays.

The following options are available:

MetaDefender Core server webhook callbacks

Traditionally Email Gateway Security polls MetaDefender Core regularly for processing results.

Enabling webhooks, MetaDefender Core can actively notify Email Gateway Security when processing results are ready.

Property validation

Some of the server profile properties have cross-dependencies and as so must match.

Testing the configuration

Clicking the SAVE button the connection will be tested first. The test consists of two steps:

1. Syntactical validation of the values
2. Connection test

Syntactical validation

The correctness of the provided values is validated:

1. Server profile name must be unique
2. The URI address values must conform with the URI syntax with the restriction listed at section Server specifications
3. Cross dependencies must match (see the Property validation section)

Connection test

If the syntactical validation pass, then each server specification is tested for a successful connection.

Limitations