3.7 Server profiles

Server profiles under Inventory > Server profiles help to organize services of one or more servers based on the service type.

For example in case of security rules one or more SMTP servers are needed to forward the emails after processing. For this purpose a server inventory may be created collecting all relay SMTP servers. Then at the rule itself only this server profile needs to be selected.

Currently MetaDefender Email Gateway Security uses and allows SMTP and MetaDefender Core type server profiles only.

Properties

Property

Server profile type

Description

Server profile type

N/A

Service type

Supported service types are:

  1. SMTP

  2. MetaDefender Core

  3. MetaDefender Vault

Profile name

All

Unique identifier of the server profile

Server specifications (URI)

All

Service specifications in 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:

URI component

Supporting server profile type

Example

Defaults

scheme

All

http://10.0.0.10:25/vault_rest

SMTP

MetaDefender Core, MetaDefender Vault

smtp

http

host

All

http://10.0.0.10:25/vault_rest

N/A

port

All

http://10.0.0.10:25/vault_rest

SMTP

MetaDefender Core

MetaDefender Vault

25

8008

8010

Vault port changed

Please note, that MetaDefender Vault port changed from 8000 to 8010 starting with Version 1.3.7.

path

Metadefender Vault

http://10.0.0.10:25/vault_rest

SMTP, MetaDefender Core

MetaDefender Vault

N/A

/vault_rest

Server profile examples

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

Server profile type

URI

SMTP

smtp://127.0.0.1:25

MetaDefender Core

http://127.0.0.1:8008

MetaDefender Vault

http://127.0.0.1:8010/vault_rest

In case of MetaDefender Core server profile types the very same URI will be used for the URLs of View scan details links on the Email details page under Dashboard > Email history, Dashboard > Quarantine and Dashboard > Failed emails.

If the URI specified here is not reachable on the machine where the actual browsing of the Web Management Console happens (e.g. it is 127.0.0.1 and browsing happens on an other machine) then the View scan details link will be broken.

See also the Email details section in 4.1 Dashboard.

Server preference

  1. SMTP

  2. MetaDefender Core

Preference order in which servers are addressed for services

Possible values:

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

    images/download/attachments/2978941/HA.png

    Start

    Core 1

    Last

    Core n

    You can set the order of the servers by drag and drop using the images/download/thumbnails/2978941/ordering.png icon next to the URLs.

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

    images/download/attachments/2978941/rr.png

    Start

    Core k

     

    Core n, Core 1

    Last

    Core k-1

    Instead of a real Round Robin selection, the initial server is selected in a random fashion currently:

    Do a random selection of the Core URLs defined in the Core inventory.

    Fail over to the next Core in the list, if the actual Core fails. Start over the selection at the end of the list and continue until the starting entry is reached.

    Start

    Core k (random)

     

    Core n, Core 1

    Last

    Core k-1

Transport level encryption

  1. SMTP

Configure whether the destination server requires transport level security for connections

Possible values:

  1. None: no transport level security

  2. StartTLS: transport level encryption using SMTP protocol's StartTLS method

  3. TLS: transport level security using SMTPS protocol

Username and password

  1. SMTP

If the destination server requires (machine-to-machine) user based authentication, then the credentials can be specified here

As long as TLS is not configured for the Web Management Console, passwords are sent clear-text over the network. To set up TLS see 3.2 Configuring TLS.

Certificate based client authentication

  1. SMTP

  2. MetaDefender Core

If the destination server requires certificate based client host authentication then this checkbox must be marked

MetaDefender Email Gateway Security will use the actual deployment's digital ID, for details see 3.2 Configuring TLS

API key

  1. MetaDefender Vault

The destination Vault server will require the authorization token specified here for Email Gateway Security to be able to upload files. For details see API Authorization Tokens in MetaDefender Vault's user guides.

Connection pooling

  1. SMTP

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

How it works

At the end of the processing of an email, Email Gateway Security forwards the processed email to the next hop –that is usually the mail server for inbound emails– via SMTP. This next hop is configured in the rule matching the email, under Policy > Security Rules / Add new rule | Modify rule / RELAY / FORWARD PROCESSED EMAILS TO. The value must be an SMTP type server profile configured under Inventory > Server Profiles.

When an email is forwarded to the relay, an SMTP handshake must happen while a TCP connection must be established. This is a time-consuming, resource-intensive task that can slow the email processing down, especially under a heavy load.

To contain the time loss caused by establishing SMTP connections, Email Gateway Security can reuse already established connections, these are kept in the connection pool.

  1. If the pool is empty, and a new SMTP connection is needed, then the connection gets established.

  2. If the pool is not full yet, and the communication completes over an SMTP connection, then this connection is placed into the pool for later reuse.

  3. If an SMTP connection is needed, and there is an idle connection in the pool, then it is taken from the pool and reused for this connection.

  4. If the pool is full, and the communication completes over an SMTP connection, then this connection is disconnected.

  5. If a connection in the pool has not been reused for the configured time, then it gets disconnected.


The following options are available:

Option

Default

Min

Max

Descripiton

ENABLE CONNECTION POOLING

Off

N/A

N/A

Enable or disable SMTP connection pooling.

NUMBER OF CONNECTIONS

20

1

999

Maximum number of SMTP connections kept in the pool for reuse purposes.

CONNECTION EXPIRY [IN SECONDS]

180

1

60 000

If the pooled SMTP connection has not been used for the time window configured here, then it gets disconnected.

SMTP server limitations

Please note, that most SMTP servers limit the number of parallel inbound SMTP connections. This must be taken into consideration when configuring connection pooling in Email Gateway Security.

Microsoft Exchange Server

For details about limitations on number of connections in case of the Microsoft Exchange Server, see https://docs.microsoft.com/en-us/exchange/mail-flow/message-rate-limits.

images/download/attachments/2978941/image2019-11-6_12-28-25.png

Property validation

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

Server profile type

Server specifications (URI) allowed schemes

SMTP

smtp

smtps

MetaDefender Core

http

https

MetaDefender Vault

http

https

Server specifications (URI) scheme

Transport level encryption allowed values

smtp

None

StartTLS optional

StartTLS required

smtps

Irrelevant

If smtps scheme is specified then the SMTP connection is established over TLS irrelevant of the setting of TRANSPORT LEVEL ENCRYPTION.

http

N/A

https

N/A

If https scheme is specified then the HTTP connection is established over TLS.

Testing the configuration

Clicking the TEST button will test the configuration. The test consists of two steps:

  1. Syntactical validation of the values

  2. Connection test

If the test fails, then the server profile can not be added.

Syntactical validation

The correctness of the provided values is validated:

  1. PROFILE NAME must be unique

  2. The SERVER SPECIFICATIONS (URI) values must conform with the URI syntax with the restriction that only the scheme, host and port values are allowed

  3. Cross dependencies must match (see the 149718360 section)

Connection test

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

Limitations

Currently the connection is tested without using TLS (when configured at all).