Server profiles

The server profile is an abstract representation of one or more physical server bundled into a single unit.

Using this abstraction the same server may be reused at several points of the application, potentially with different actual settings. The abstraction can also provide failover or load balancing capabilities in certain cases.

Example

In the image below we show an SMTP type server profile. This profile contains two actual SMTP servers that are utilized in a Failover fashion (the first is the preferred one, but if that fails, then the second is attempted).

This server profile can be used in any of the security rules as the SMTP relay server profile (see Configuration/Policy).

As long as TLS is not configured for the web management console, sensitive information above is sent clear-text over the network.

For details see Configuration/Transport Layer Security.

As long as TLS is not configured between MetaDefender Cloud Email Security and the server providing the service of the server profile, sensitive information above is sent clear-text over the network.

For details about configuring TLS between MetaDefender Cloud Email Security and server profile servers see section Transport layer security schemes.

For TLS to work properly, it must be configured on the server profile server.

• SMTP server: seek for guidance at the vendor of your SMTP server
• MetaDefender Managed File Transfer: https://onlinehelp.opswat.com/vault/Enable_HTTPS.html

The order of the servers can be set by drag and drop using the ⋮ icon in front of the server specification.

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

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

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

At the end of the processing of an email, MetaDefender Cloud Email 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 Security Rules / rule / GENERAL / SMTP relay server profile (see Configuration/Policy). The value must be an SMTP type server profile configured under Settings > 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, MetaDefender Cloud Email 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.

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 MetaDefender Cloud Email Security.

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.

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

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